--- Log opened Tue Oct 29 00:00:56 2013 00:18 < petertodd> warren, gavinandresen: whoever jdillon is there's a lot of publicly verifiable proof-of-work and proof-of-sacrifice that's been involved to establish that identity :P 00:18 < petertodd> gmaxwell: we can tell if it's DPR by watching to see if his ideas get more or less intelligent now that the FBI is the puppet master 00:19 < petertodd> gmaxwell: so what opcodes do we need enabled? 00:20 < petertodd> warren, gavinandresen: BTW if anyone wants to establish intelligent-sounding sock-puppets, I'm willing to sell original, unpublished, crypto-coin theory for 1BTC a page, 0.5BTC if half-baked... 00:21 < gmaxwell> petertodd: none, I came up with a formulation that should work on the existing network. See link. 00:24 < petertodd> huh, I think I get it... 00:24 < warren> There's apparently a new DPR now. 00:24 < warren> The old one should sue for trademark infringement. 00:24 < petertodd> warren: oh yeah? mind, that's the whole point of that name... 00:25 < petertodd> warren: I'm also not going to be as surprised as I should be if the government can't prove their case; digital evidence is deeply untrustworthy. :( 00:26 < petertodd> gmaxwell: can you add some actual scriptPubKeys to your description? 00:39 < gmaxwell> petertodd: sure, this sound sane to you? This is the pubkey in the first transaction (ignoring the alice+carol branch) 00:39 < gmaxwell> scriptPubKey: [ OP_DUP OP_ROT OP_RIPEMD160 OP_EQUAL OP_VERIFY OP_ADD OP_RIPEMD160 PUSH_H(HX+Q) OP_EQUAL OP_VERIFY PUSH_CAROLPUBKEY OP_CHECKSIG ] 00:39 < gmaxwell> and this is what the scriptsig looks like: 00:39 < gmaxwell> [SIGNATURE PUSH_Q PUSH_X PUSH_HX] 00:43 < gmaxwell> and Carol's scriptPubKey towards bob is: [OP_RIPEMD160 PUSH_HX OP_EQUAL OP_VERIFY PUSH_BOBPUBKEY OP_CHECKSIG ] and the redeeming signature is [SIGNATURE PUSH_X] 00:43 < gmaxwell> (again ignoring the alternative carol+bob refund branch) 00:44 < petertodd> working on it... 00:45 < gmaxwell> so basically, to get paid bob must publish X for ripemd160(X) = HX. Carol can either get paid by alice's consent, or carol can instead use the knoweldge of X to redeem alice's payment, but that makes the alice/bob relationship public.e 00:47 < gavinandresen> gmaxwell: That OP_ADD is adding HX and Q ? 00:48 < petertodd> I was just about to say... 00:48 < petertodd> ADD is numeric 00:48 < petertodd> I think you want CAT which is disabled 00:48 < gavinandresen> ADD (and all the rest of the arithmetic ops) are crippled to only work on 32-bit numbers right now, too. 00:49 < petertodd> yup 00:49 < gmaxwell> aw crap, I forgot about that. @#$@#$@#($8324 00:49 < gmaxwell> (for some reason I thought it did bignum adds on hash outputs.) 00:49 < petertodd> gavinandresen: we're going to curse you until the end of time for doing that. (or until script v2.0, which ever comes sooner) 00:50 < gmaxwell> gavinandresen: and yea, it just needs some way of modifying the value that gets hashes because you can't disclose HX directly in the scriptpubkey 00:50 < gmaxwell> (if you want to keep the transaction private) 00:50 < gmaxwell> e.g. add, xor, cat, any of that would do. 00:51 < gavinandresen> mmm. Wish satoshi hadn't disabled the xor, that seems like it would be safe (never creates results bigger than inputs) and would be darn handy. 00:52 < petertodd> though OP_XOR was affected by the sign extension bug 01:01 < petertodd> gmaxwell: interesting how OP_EVAL could have worked here too, or OP_MAST_EVAL 01:14 < gmaxwell> petertodd: so I have a way of making it work I think but it's kinda awful. 01:14 < petertodd> gmaxwell: hang on, why not have Alice pay into 2 2 OP_CHECKMULTISIG, and then require alice to sign a transaction spending that txout to RIPEMD160 H(X) EQUALVERIFY CHECKSIG prior to carol creating the txout for bob? it's almost as trust free 01:14 < petertodd> yeah? 01:15 < gmaxwell> because thats not private. 01:15 < gmaxwell> oh I see! 01:15 < petertodd> sure it is, carol only publishes the transaction if needed, the normal case is alice then signs her part of the checkmultisig with SIGHASH_NONE|ANYONECANPAY 01:15 < gmaxwell> Yea, you hide the alternative redemption by never announcing it instead of branching. 01:16 < petertodd> carol can spend at will 01:16 < petertodd> yup 01:16 < gmaxwell> Indeed. That works. Also makes the transaction look more indistinguishable! awesome. 01:16 < gmaxwell> So here is what I was going to point out. 01:16 < petertodd> ? 01:18 < gmaxwell> if you replaced the addition with Q with a cascasde of RIPEMD160 or HASH160 with IFs.. e.g. 64 x {RIPEMD160 or HASH160} then 'q' becomes a sequence of 64 trues or falses you send in to pick which mixture of hashfunctions to apply. 01:18 < petertodd> ha, yeah, I thought of that, and thought it too awful to contemplate 01:18 < gmaxwell> E.g. R(H(H(H(R(R(H(R(H(R(H(R(R(H...(HX))))) = constant in the transaction. 01:19 < gmaxwell> petertodd: in any case you solved it, go post. :P 01:19 < petertodd> heh 01:19 < gmaxwell> Yours is an improvement anyways, makes the transaction smaller, makes it indistinguishable from other kinds of escrow transactions on alice's side. 01:20 < gmaxwell> (in the case where alice doesn't cheat, of course) 01:20 < petertodd> yeah, I should write an app for this... 01:20 < petertodd> surely that's deserving of a coinjoin bounty reward, even if it's not coinjoin! 01:21 < gmaxwell> Yea, it's sort of interesting to compare this with coinjoin, it has different properties. I think both are complementary. 01:21 < petertodd> yup 01:23 < gmaxwell> petertodd: in CJ we can arrange so that _no one_ learns the input/output matching, which we can't in this. But in this we can make it so that the coins have fully disjoint history. .. of course, this isn't secure until malleability is fixed. 01:24 < gmaxwell> (since you could announce a mutant, break the precomputed refunds, and then perform a holdup attack) 01:24 < petertodd> yeah, but alice is trusting carol to pay bob anyway, so carol waiting until the first tx confirms isn't a problem 01:24 < gmaxwell> petertodd: alice isn't, in fact, if alice makes carol write a refund transaction before alice announces the escrow payment. 01:25 < petertodd> I mean, I guess you're right that carol could run with the money, but carol is the party that's easiest to fidelity bond here 01:25 < gmaxwell> no need to! 01:25 < gmaxwell> this is trust free if everyone has refund transactions. 01:25 < petertodd> yes, but since we can't have 100% secure refund, fidelity bond carol :) 01:25 < gmaxwell> oh because of malleability, yea but that'll get fixed. 01:26 < petertodd> maybe... I can write this app this weekend! 01:26 < gmaxwell> it has a lot of states. 01:26 < gmaxwell> alice writes the escrow payment demands an nlocked time refund before announcing it. Alice announces. Carol demands a bob-secret release transaction before paying bob. 01:26 < petertodd> sure, but something that can be run by hand shouldn't be too bad 01:27 < gmaxwell> Carol writes the bob paying transaction but demands a nlocktimed refund before paying him. 01:28 < gmaxwell> that in hand carol pays bob. Then it confims asks alice to pay up. If alice is unresponsive carol uses the stashed bob-secret release. or if bob doesn't redeem, she just gets her money back. 01:28 < gmaxwell> petertodd: got a better name for this than "airgapped payment"? 01:34 < petertodd> ooh, actually I think you could do a system where in the general case Carol's payment to Bob is a normal looking transaction too... 01:35 < petertodd> hmm... teleported payment? 01:37 < gmaxwell> petertodd: how? 01:38 < gmaxwell> I was trying to figure out if there was some way to abuse ECDSA but haven't come up with one yet. 01:39 < petertodd> have carol create txout 2 2 CHECKMULTISIG, and then sign her part of the txout with a transaction paying to HASH160 EQUALVERIFY CHECKSIG, Carol gives that partially signed tx to Alice, who then knows Bob can redeem the output via that tx at worst, while normally Carol would, once her payment is confirmed, just sign her part of the txout with a SIGHASH_NONE|ANYONECANPAY 01:40 < petertodd> now both input and output transactions are, in the general case, totally standard. (modulo the SIGHASH_NONE business... bit annoying that) 01:40 < gmaxwell> oh interesting, you applied the same transformation on both sides. now if everyone is honest its just a pair of 2 of 2 escrows. 01:40 < petertodd> yup 01:40 < gmaxwell> But if anyone is dishonest it becomes a set of interlinked hashlocked transactions. 01:41 * gmaxwell thinks for a minute 01:41 < petertodd> and if anyone is a shitty programmer we're in for a world of hurt :P 01:41 < gmaxwell> it'll be like namecoin 01:41 < gmaxwell> :( 01:41 < petertodd> how so? 01:41 < gmaxwell> get used for years by thousands of people and it won't matter if the transactions are really anyonecanspend. 01:42 < petertodd> until it breaks and we realize it doesn't actually work? yeah... 01:42 < gmaxwell> I note that the ABS() challenge transaction has free dinner sitting waiting for someone to take it. :P 01:42 < petertodd> needing eligius's help has problems here 01:42 < petertodd> ha, I know 01:42 < petertodd> shhh 01:43 < gmaxwell> petertodd: hm. I'm not actually sure your thing works. I don't see how you release the escrows. 01:43 < petertodd> what do you mean? 01:45 < gmaxwell> okay, nevermind I see it. 01:45 < gmaxwell> there are three layers of transactions going on here. 01:45 < gmaxwell> The default path, the refunds, and the anti-cheating. 01:46 < gmaxwell> transaction teleportation indeed. 01:46 < petertodd> yeah... I'll have to actually implement it to be sure I understand it myself :/ 01:46 < gmaxwell> Someone a while back was trying to propose a telportation protocol like this using 2of2 escrows, but he has nothing to prevent people from playing chicken (no hashlock idea) 01:47 < petertodd> figures, it's a nice idea, just tricky to come up with all three layers 01:47 < petertodd> like you need to be a wizard or something 01:48 < gmaxwell> heh. Yea, it needs all three layers to gain all it's magical properties. 01:48 < gmaxwell> its great that it looks like a pair of unrelated 2 of 2 escrows. 01:48 < petertodd> yup 01:48 < petertodd> also, note that Alice and Bob can be the same person :) 01:48 < gmaxwell> that'll give it a pretty good anonymity set. 01:49 < gmaxwell> yea, amiller pointed that right away.[6~[6~ 01:49 < petertodd> heh, it's not totally obvious... and it's probably best if it's possible that they aren't! 01:50 < gmaxwell> I think it's actually more useful as something where they aren't. Bitcoin is already private when you get paid. This makes you private when you pay (well, except towards carol) 01:50 < petertodd> yeah, and Alice can handle Bob's side of the transaction on Bob's behalf 01:51 < petertodd> turning this into a secure version of blockchain.info's send-shared 01:51 < petertodd> s/secure/trust-free/ 01:52 < gmaxwell> Yep. 01:52 < petertodd> I think the main thing that sucks about it, is that it can't be arranged to all happen in one step - the rounds-trips are a nuisance. 01:52 < petertodd> Also, waiting for confirms sucks. 01:53 < gmaxwell> yea well thats a reason to note that alice can logically run it for bob. runnning it alice/alice allows alice to unlink funds before selecting bob. 01:54 < gmaxwell> the next obvious thing to do is to partner with a mining pool, so that carol is issuing freshly mined coins. 01:54 < petertodd> ah, yeah that's good 01:54 < petertodd> right, so essentially make a wallet where you setup txouts in advance using this method 01:54 < gmaxwell> Otherwise you always have to worry about crappy carols going and mixing up the funds in the future. 01:55 < petertodd> could be interesting to do this with a pool that had a bit of hashing power, and just wait until they make a block with the desired output right in the coinbase! 01:55 < petertodd> not practically more useful, but nice PR 01:56 < petertodd> heh, and then shuffle the incoming coins through the coinbase via fees... 01:56 < gmaxwell> meh, sullys the airgap. 01:56 < petertodd> not if more than one pool is doing this and they're mining anonymously 01:57 < petertodd> but yeah, better to pay out to miners with the coins coming in instead 01:57 < petertodd> s/miners/hashers/ 01:59 < petertodd> anyway, at bare minimum the temporal ordering of the money going in and the money going out is disturbed, which is something coinjoin can't do 02:01 < petertodd> it'd be good to think if the efficiency can be improved - for instance can we construct the coins coming in such that they are actually being paid to someone who is getting coins out from a teleported payment happening simultaneously? 02:02 < gmaxwell> well, that hardly matters much if the transactions are conspicious unless it is very widely used. With them less conspicious its more interesting. 02:02 < petertodd> yeah, we need more multisig-using wallets to have any hope of this not looking interesting 02:03 < gmaxwell> petertodd: I think its hard to do that, because while the alice->carol payment could really go to sue, the cheating escapes are specific to alice->bob. 02:03 < petertodd> might be good to use new pubkeys for all this stuff, so that bob can get the privkeys so he doesn't need NONE|ANYONECANPAY 02:03 < gmaxwell> oh that always has to be a requirement for any protocol where you sign stuff you can't see. 02:04 < gmaxwell> otherwise you risk getting tricked into signing a transaction you didn't intend to sign. 02:04 < petertodd> oh, but see, here I'm not sure you are actually singing sutff you haven't seen 02:04 < gmaxwell> you are for refunds. 02:04 < petertodd> true 02:05 < petertodd> w/ your p2sh anti-mutability trick 02:05 < gmaxwell> In general I think this kind of thing can go forward assuming mutability is just fixed. We're on our way to fixing it, and having applications it breaks is the motivation to finish the job. 02:06 < petertodd> yeah 02:06 < gmaxwell> today people use totally insecure trusted protocols... so something like this where refunds are fragile is probably fine in the short term. 02:06 < petertodd> yup 02:07 < petertodd> of course, this is an example where an alterative implementation is fidelity bonding it all, and it'd be a good deal more efficient given that alice pay a simultaneous bob 02:07 < gmaxwell> sort of a bummer that there is no great way to coinjoin into and out of the thing. 02:07 < gmaxwell> Because the fact that carol learns the matching is lame. 02:08 < gmaxwell> you could sandwitch the thing inside coinjoins with extra transactions though. 02:08 < petertodd> yup 02:08 < gmaxwell> well I don't like anything that creates carol-inertia too much. 02:09 < petertodd> otoh, in a scheme where carol does learn, carol can always be paid off to get the logs 02:09 < gmaxwell> Because carol is a privacy point of failure and an attractive target. It's good that bonding carol doesn't make carol non-anonymous, but better if we can have lots of carols so that there is no obvious target to compromise... and all the really interesting traffic can traverse multiple carols. 02:10 < petertodd> so, here's the neat thing: there's an incentive to be carol too! you get new coins just as much as bob does 02:10 < gmaxwell> right thats why carol learning sucks, and its one way CJ is strictly superior, in that its not hard to totally blind CJ. 02:10 < gmaxwell> But I think in a world with both CJ and teleportation and lots of carols, logs are not so useful.. you get carols logs and the interesting traffic came in/out via another carol or via CJ. 02:11 < petertodd> sure, my point being though if you put this in a protocol, do it on a p2p layer and make the application play the role of both alice and carol when you want to get coins to pay bob 02:11 < gmaxwell> and while you could try to pay all carols chaum blinded CJ can't be bought, only flooded. 02:11 < gmaxwell> oh interesting. you make bob recieve your carol role coins perhaps. 02:12 < petertodd> It should all be wrapped up in a "Pay bob!" and depending on who wants to do what, you'd either pay Bob by being Alice, or pay Bob by being Carol and using Alice2's funds to pay Bob 02:12 < gmaxwell> so you could be alice or carol, whichever is in more demand, and bob either gets bob coins or carol coins. 02:12 < petertodd> yup 02:12 < petertodd> Or even, depending on amounts available you'll wind up using both types to pay Bob 02:13 < gmaxwell> Every time I see you falling 02:13 < gmaxwell> I get down on my knees and pray 02:13 < gmaxwell> I'm waiting for that final moment 02:13 < gmaxwell> You say the words that I can't say 02:13 < petertodd> lol 02:15 < petertodd> though, with non-trivial tx fee costs the pure fidelity bonded version will probably be popular too... 02:15 < warren> I made a Bitcoin 0.8.5 branch with all backports that we have in Litecoin plus a few features that aren't committed to 0.9 yet. 02:15 < petertodd> it's interesting though, because there will always be a lot of transactions whose value is such that fees don't matter much 02:15 < warren> I found a bug in watchonly in the process. 02:16 < petertodd> oh good 02:16 < gmaxwell> warren: \0/ 02:16 < warren> waiting for sipa to wake up 02:16 < warren> what should I call this branch ... 02:16 < warren> "plus" 02:16 < warren> "omg" 02:17 < warren> oh heck, I'm including NODE_BLOOM 02:18 < petertodd> heh 02:19 < petertodd> include Discourage fee sniping with nLockTime and you can really be living dangerously :/ 02:19 < petertodd> (and determine if anyone uses it...) 02:19 < warren> petertodd: how dangerous is that? 02:19 < warren> petertodd: I'd like people to actually use this branch 02:20 < petertodd> warren: lol, Luke's been testing it for ages actually with no problems, but some badly written wallet software still handles final nLockTime wrong :( 02:20 < warren> I'd like to include https://github.com/bitcoin/bitcoin/pull/2839 but testing in Litecoin OMG2 suggests it doesn't work. 02:21 < petertodd> ah, too bad, also the blacklisting RPC needs a way to unblacklist. (unless I missed something when I looked at it) 02:21 < warren> it does 02:21 < warren> it adds tothe blacklist and you can remove 02:21 < warren> he even added the missing lock that I found 02:21 < warren> just it fails to disconnect anything you ban 02:23 < petertodd> huh, how do you remove the blacklist? I never figured that out 02:24 < warren> petertodd: expiration to zero 02:24 < warren> petertodd: the PR says how 02:27 < petertodd> expiration? where is that mentioned? I totally missed that 02:27 < warren> I haven't looked at it in a while 02:27 < warren> the patch just doesn't work at all 02:27 < petertodd> too bad, we should have something like it anyway 02:28 < warren> yeah, if only we had software engineers capable of fixing things 02:29 < warren> volunteers usually only fix the fun things 02:29 < petertodd> gmaxwell: lol, my girlfriend just pointed out that the song is "Bizzare Love Triangle", and there's two girls and one boy in the protocol :P 02:29 < petertodd> gmaxwell: she's more impressed with your quote than my protocol! 02:30 < petertodd> warren: ha, so very true... (see log) 02:31 < warren> i'm calling this Bitcoin OMG 02:31 < petertodd> better name than next-test 02:31 < warren> meant to be stable, fun, and including things that should be in Bitcoin proper but isn't fully proven yet 02:31 < gmaxwell> petertodd: hahah yes, thats why I chose to emit the lyrics when I did. Because all this alice and carol and bob and ones cheating the other but they have this non-public arrangement and soooo. 02:35 < petertodd> heh, ah, it's just too perfect 02:35 < warren> https://github.com/wtogami/bitcoin/commits/btc-0.8.5-omg 02:35 < warren> it seems to work! 02:36 < warren> Disable Wallet, Coin Control, Watch Only, processgetdata and a million other things tested in Litecoin for months 02:42 < warren> hmm, should I include secp256k1 in this? 02:42 < warren> hmm.... 02:43 < petertodd> warren: tsk tsk, I don't see any git signatures proving that branch is really yours :P 02:45 < warren> petertodd: fine ... how do I verify them? 02:45 < petertodd> warren: git log --show-signature 02:45 * petertodd needs to figure out how to make that the default 02:45 < warren> petertodd: you have a working gitian setup? 02:46 < warren> petertodd: I want to do gitian.sigs for OMG 02:46 < petertodd> warren: nope :( there's been progress on non-VM-based gitian lately? 02:46 < warren> I'm testing watchonly with DPR's coins now 02:46 < warren> petertodd: some, michagogo was working on it 02:46 < petertodd> my bios is buggy apparently 02:46 < petertodd> ha, nice 02:46 < warren> not sure if it is in 0.9 yet 02:46 < petertodd> yeah, I gotta get that working properly 02:47 < warren> I committed something to 0.9 that gets rid of wine during the win32 build 02:47 < petertodd> personally I always compile from source though, so it's git's integrity that I'm interested in 02:49 < warren> if I disable mining is secp256k1 safe enough? 02:50 < petertodd> sure given this is an OMG 02:50 < petertodd> heck, I mine on git master myself, so I shouldn't talk 02:50 < warren> I'll wait for sipa's feedback on that 02:51 < warren> hm, better not risk it 02:51 < warren> this is meant to be usable for Coinpunk 02:51 < petertodd> yeah, don't need to go too far... 02:53 < warren> petertodd: https://togami.com/~warren/archive/2013/my-bitcoin-wallet.png 02:53 < petertodd> lol 02:54 < petertodd> if it can do correct horse I'll be more impressed though 03:59 < warren> ooh 03:59 < warren> forgot to add leveldb-1.13 08:39 < warren> jgarzik: https://bitcointalk.org/index.php?topic=320695 08:40 < warren> jgarzik: yet another bitcoin mac build with leveldb related improvements, would be interesting to see if it fixes the mac corruption, you had people at your office affected? 08:47 < sipa> warren: for a secp256k1 build, i'd like to disable both wallet and mining 08:47 < sipa> in that case the worst that can happen is you yourself being forked off 08:52 < TD> sipa: does libsecp256k1 work on ARM? 08:52 < sipa> i've been told it does, but i haven't tried 08:52 < sipa> it may be slow 08:53 < sipa> i believe cfields tried it on Debian/ARM 08:53 < TD> slow in what sense? 08:53 < TD> slow as in not any faster than openssl, or ... ? 08:53 < sipa> yes 08:54 < sipa> of course i don't expect it to be as fast on a mobile as on an i7 :) 08:54 < TD> naturally. i don't think it's possible to be slower than interpreted Bouncy Castle on ARM though 08:54 < sipa> :D 08:54 < TD> you'd have to insert sleep statements into the inner loop to be slower than that 09:53 < petertodd> paper analyzing mixing services and similar things: https://www.wi.uni-muenster.de/sites/default/files/public/department/itsecurity/mbc13/mbc13-moeser-paper.pdf 13:50 < gmaxwell> man, I wish the script OP code values had bits in them to signal how many objects they push and pop from the stack.. would have made softforking forwards compatibility a lot easier. 13:51 < petertodd> good point 13:58 < gmaxwell> (though you end up with the arm instruction set (32 bit instructions) pretty quickly if you're not careful. :P ) 13:58 < petertodd> no worries, just run blocks through bzip2... 14:00 < gmaxwell> petertodd: you did see that I responded to TD pointing out that p2sh is larger and that has an impact on long term storage with a "sufficiently good blockchain compression"? 14:02 < petertodd> gmaxwell: maybe? 14:03 < petertodd> https://bitcointalk.org/index.php?topic=320331.msg3429302#msg3429302 14:03 < petertodd> that's a good point 14:04 < petertodd> OTOH it is bigger in terms of blockchain data, and we all know how much TD cares about maximizing the transaction rate and a fixed block size :P 14:06 < petertodd> (biger vs. pay-to-pubkey) 14:08 < TD> i think with compression of the storage (and maybe in a future protocol version, transmission) it's down to a few bytes difference either way, right? 14:08 < TD> so not worth worrying about in either direction 14:09 < petertodd> good to hear 14:09 < petertodd> p2sh certainely could be a good thing for the payment protocol re: standardization if we're going to keep IsStandard() 14:09 < gmaxwell> TD: You can't compress a never spent txout. I dunno if it's worth worrying about, but I'm still much more comfortable with larger scriptsigs than scriptpubkeys. 14:10 < TD> it'd be nice to get rid of the IsStandard checks one day, especially if script became more powerful 14:11 < petertodd> TD: I think jdillon's opcode whitelisting suggestion for P2SH scriptPubKeys has merit for a short-term solution 14:12 < petertodd> TD: though it's interesting how IsStandard() is currently important for mutability too... 15:00 < gmaxwell> petertodd: http://pastebin.com/EsmJarxU < diagramed out the teleportation protocol. 15:32 < warren> sipa: secp256k1 works on litecoin ARM 15:34 < sipa> warren: nice to know 21:05 < amiller> this mixing transaction thing is nuts 21:06 < amiller> i'm helping write this paper about the rationale for third party bitcoin mixing services 21:06 < amiller> it's simpler than zerocoin, which i still kind of like the best 21:07 < amiller> we keep nearly getting undermined by simpler better tech though, like coinjoin would be better if not for the DoS and apparent infeasibility of an honest server 21:08 < amiller> but now this hashlock mix is just as good in every way, and better specifically in that it prevents the server from running away with the funds 21:09 < amiller> we've sort of gone through great lengths so far by just whitewashing the problem and saying "well servers will want to maintain their great reputations and future income therefore they'll never actually steal any funds if users can prove it happened" 21:09 < amiller> which IMO sucks and is not even justified 21:09 < amiller> anyway this simplifies it 21:14 * amiller tries to think of some third cool trick to achieve with hashlocked tx 21:14 < amiller> abstractly, hashlocking lets you bind two transactions into an atomic pair 21:14 < amiller> either both get through or neither 21:14 < amiller> with tiernolan's crosschain exchange, the two txes aren't even on the same chain 21:15 < amiller> with gmaxwell's hashlocked mix, only the mixer knows the correspondence between the two in the ordinary case 21:16 < amiller> what other reason could you have to want to join two separate transactions? 21:17 < maaku> amiller: why do you need an honest server for coinjoin? 21:17 < amiller> maaku, because there's no public publishing system (like freenet or w/e) that gives you much defense against one person trivially jamming the whole tx by not singing 21:17 < amiller> signing* 21:18 < amiller> it's a DoS disaster 21:18 < amiller> a dosaster 21:18 < amiller> (trademark pending) 21:18 * amiller registers dosaster.com 21:18 < maaku> ok by "DoS and apparent infeasibility of an honest server" you made it sound like something else 21:18 < amiller> oh 21:19 < amiller> i mean that even an honest server can't do much to prevent it other than check bonds or something 21:19 < amiller> it's a hopeless game for the honest server, sort of like the standard "escrow" on bitmit or silkraod 21:19 < amiller> good for comforting users but not actually capable of resolving an actual dilemma 21:20 < maaku> it's not hopeless; DoS can be mitigated 21:20 < maaku> but granted it's not easy either 21:22 < amiller> it's not so much that dos can be mitigated, but that in most practical scenarios no one is trying that hard so you can get away with not mitigating it 21:22 < amiller> which is why, for example, bitmessage is currently functioning 22:01 < amiller> ugh, so i need a way to make a coin flip automatically go to the winner 22:11 < amiller> i wish the stupid splice operations weren't all disabled :/ 22:47 < warren> petertodd: crap. the combination of coin control and watch only snuck in some really strange coin selection bugs 23:28 < amiller> okay so i think i figured out the implication of all my prospect theory crap. 23:28 < amiller> it relates to allowing people to choose their own difficulty 23:29 < amiller> ah this is going to be too complicated to finish 23:31 < amiller> nevermind 23:37 * Luke-Jr wonders if sharing a private key between secp256k1 and Ed25519 would expose it --- Log closed Wed Oct 30 00:00:21 2013