--- Log opened Sat Jan 11 00:00:25 2014
01:00 < shesek> gmaxwell, oh, that's very interesting! hashlocked transactions always seemed like a great solution if we could get rid of the link it creates on the blockchain
01:01 < shesek> 40mb isn't ideal, but isn't too awful either given that its exchanged privately between two users and shouldn't be done too often
01:17 < shesek> the transactions would look somewhat unique if its used as the primary transaction method and not just as a fallback in case of cheating, though I don't know how much of a problem that is if its commonly used
01:56 < Guest85612> ethereum discussion on the front page of HN : https://news.ycombinator.com/item?id=7041628
02:06 < justanotheruser> maaku: do they have some prevention from people making infinite loops?
02:06 < justanotheruser> If I wanted to attack the currency I would just mine an infinite loop into the blockchain
02:13 < gmaxwell> shesek: oh well there is another way to eliminate the link, but the protocol has a number of steps, which in practice results in a lot of engineering trouble.
02:13 < gmaxwell> shesek: https://bitcointalk.org/index.php?topic=321228.0
02:14 < shesek> with coinswap and 4 transactions?
02:14 < gmaxwell> okay so you'd seen it then, yea. It would work but the state machine required to actually do it— while easy to chart is a real pita.
02:14 < shesek> yeah, I know, but this is a much more elegant solution
02:15 < shesek> though, as I mentioned above, being somewhat identifiable as transactions meant for that purpose is somewhat problematic until this is commonly used
02:16 < shesek> if there are only two transactions in a whole day that uses hashlocked transactions its quite easy to link them together
02:17 < shesek> maaku, too bad its down though
02:18 < shesek> someone from HN posted it to pastebin: http://pastebin.com/NCGRv74u
02:21 < shesek> oh, seems like it was published for some time now... I didn't hear of it until now
02:25 < gmaxwell> shesek: you need to review the coinswap page.
02:25 < gmaxwell> shesek: the innovation there is that if the transaction goes through successfully the public never sees the hashlock (!), it looks like a set of multisignature transactions.
02:26 < shesek> are you talking about coinswap or the new idea you had?
02:26 < gmaxwell> (2 of 2 at a minimum, but no reason that you couldn't throw in a garbage pubkey and make them 2 of 3s to be less irregular)
02:26 < gmaxwell> shesek: coinswap.
02:26 < gmaxwell> but that cost is that the protocol has a bunch of stages.
02:26 < shesek> that "they look unique which can link them" was referring to your idea posted here, not to coinswap
02:26 < gmaxwell> oh! okay yea.
02:27 < gmaxwell> Well you could perform the same transform to this, but then you lose the fact that its simpler. :P
02:27 < gmaxwell> in any case, lots of uses for hashlocked transactions. so perhaps they'll be common at some point.
02:30 < shesek> yeah, lots of interesting uses for them. I even have something for atomic exchange between altcoins (I think that was your idea originally?) laying around somewhere on my harddrive, though in a very very early stage
02:31 < shesek> its possible to spread out the transactions over a random period of a few days to weeks, which should help until they're more commonplace
02:31 < gmaxwell> yea, I'd proposed the non-private version of that pattern for exactly that purpose.
02:32 < shesek> (^ is regarding the transactions being unique)
02:34 < justanotheruser> gmaxwell: regarding our proof of stake discussion yesterday, how do I prevent a miner from paying tx fees to themself and using the new UTXO as their proof? Should I require them to use a time lock on their bitcoin payment with a tx fee?
02:51 < shesek> gmaxwell, btw, I'm not really familiar with the current solutions for keeping other participants from linking your input/output in coinjoin, but I was thinking about a tor-like onion encryption to pass messages around, where you would onion-encrypt it with N participants, exposing the input and output at different "peel levels"
02:51 < shesek> does something like that makes sense?
02:52 < shesek> I assume it was probably already solved in some more elegant way, I should probably read some more about how coinjoin should work
13:50 < gmaxwell> andytoshi: mostly I think a reduction in failed signings is worth it, and if the tool itself were misbehaving you're likely screwed.
13:52 < andytoshi> gmaxwell: agreed
13:52 < andytoshi> i wish i didn't need to demand a wallet passphrase in a program that is openly communicating with my server
13:52 < andytoshi> the optics are terrible
14:22 < jgarzik> Bitcoin blockchain torrent updated, 70% of previous bootstrap.dat is re-used.  https://bitcointalk.org/index.php?topic=145386.0
14:46 < _ingsoc> Does anyone know if Vitalik Buterin hangs out on Freenode?
15:37 < wyager> So who's read the ethereum whitepaper?
15:38 < wyager> It's very interesting, but I think it might prove very difficult to manage
15:57 < maaku> wyager: incentives for computation is wrong
15:57 < wyager> How so? I'm not particularly enamored with the incentive model, but I thought it seemed OK
15:57 < maaku> there's no point in paying miners fees for computation, when the miners are not doing the compuation
15:58 < wyager> Aren't they?
15:58 < maaku> no
15:58 < maaku> validating nodes are
15:58 < maaku> most miners are not validating nodes
15:58 < justanotheruser1> everyones doing the computation, only the miners are getting paid right
15:58 < maaku> and worse, they are getting paid proportional to hash power
15:58 < maaku> which has nothing to do with the computation
15:58 < wyager> So when a program broadcasts a transaction, every single validating node broadcasts the transaction?
15:59 < justanotheruser1> maaku: why wouldn't the miners be validating nodes? If they had something invalid in their block it would get rejected right?
15:59 < maaku> *every single validating node computes the transaction
15:59 < maaku> justanotheruser: no, nearly all miners use pools
15:59 < wyager> What about when, during the course of a contract/program executing, it sends a transaction? Does that happen like a real person/bot sending a transaction?
15:59 < maaku> and a pool only needs to run a single validating node
16:00 < justanotheruser> maaku: oh, I see what you're sayinh
16:00 < maaku> e.g. GHash.io and BTC Guild each only need to run one validating node
16:00 < maaku> and yet they together get more that 50% of the reward
16:01 < maaku> and the thousands of people running validating nodes for non-mining purposes get nothing
16:01 < maaku> (but still have to run the computation)
16:01 < wyager> OK, but I guess that still makes some sense if the point is simply to prevent logic bombs rather than to compensate the people running the contracts
16:02 < justanotheruser> I wish there was a way to reward validating nodes. But I don't think there is without risky sybil
16:03 < maaku> the best approach is to make it truly cheap to run validating nodes
16:03 < maaku> and/or make it so they are not required
16:03 < justanotheruser> maaku: what do you mean "make it so they are not required"? Wouldn't them not validating make them not validating nodes?
16:05 < maaku> make it so that whatever application you needed a validating node for, you don't anymore
16:05 < maaku> e.g. because you have a succinct proof of validation (so you don't need to validate it yourself)
16:07 < justanotheruser> ok
17:15 < gmaxwell> so, actually implemented my ZKP,  a proof of sha256 is 47mbytes.
17:16 < gmaxwell> (for ~123 bit security)
17:18 < gmaxwell> and validation requires about 1 million EC multiplies with the generator and about 4 million hash operations.
17:20 < sipa> that's a proof for "i have some input you don't know, which hashes to X" ?
17:24 < gmaxwell> Yes— basically its just the cost of running SHA256 under my NIZK proof system.  So not just "I have" but any trivial operation along with it. Like "X is the hash of something that begins with 'sipa'" would have the same cost.
17:24 < gmaxwell> or for 2x that cost I can do my   "Z is the xor of the preimage for hashes X and Y"
17:25 < gmaxwell> now I should go see if ripemd160 can be done with fewer gates.
17:33 < andytoshi> this is really exciting, thanks for doing this work gmaxwell
17:35 < petertodd> gmaxwell: +1
17:36 < sipa> indeed, very nice to see some things actually being done
17:36 < sipa> instead of the mostly talk here :p
17:40 < justanotheruser> gmaxwell: Is this related to SNARK?
17:44 < andytoshi> more of a NARK :P
--- Log closed Sun Jan 12 00:00:35 2014