00:21:16	jgarzik:	New torrent, http://gtf.org/garzik/bitcoin/bootstrap.dat.torrent
00:21:34	gmaxwell:	maaku: fwiw, you can do a very easy implementation of socalist millionaire using only blind signing.
00:23:28	gmaxwell:	maaku: you hava a database you'd like me to check for matches it. You sign each entry and give me the signatures. I learn nothing useful from this. Then when I want to see if X is in the database, I blind X and ask you to sign it. You learn nothing about X. Then I unblind and can see if it was in your list.
00:34:13	Emcy:	jgarzik do you have the previous 2 or 3 bootstrap torrents you made anywhere?
00:34:20	gmaxwell:	maaku: though I think until someone works out what an 'optimal' CJ decision looks like, it's hard to reason about what it would take for some magical private process to generate them.
00:34:44	Emcy:	it occurs to me i can seed them all from the same file
00:39:21	Emcy:	well actually ive got 3, 4.5gb, 9gb and this new 13gb
00:39:31	Emcy:	i think thats all of them right
00:41:52	maaku:	gmaxwell: what do you mean by 'optimal coinjoin decision'?
00:56:46	jgarzik:	Emcy, sf.net/projects/bitcoin has current; above is current+1
00:58:07	Emcy:	huh?
00:58:31	Emcy:	thats the bitcoin client
00:58:40	gmaxwell:	maaku: I mean, say given a set of transactions, which partipants will not gain any privacy under an assumption that the attacker understands coinjoins and are unravling them based on the assumption that users_inputs==users_outputs?
01:14:55	maaku:	maaku is now known as Guest56197
03:18:02	gmaxwell:	oh. I think I just reduced the complexity of my trivial NIZK proof to O(N) without substantially increasing the complexity of it, though by adding a discrete log hardness assumption.
03:19:53	gmaxwell:	The point I'd made at the end is that you could remove the N^2 by using an xor-homorphic commitment as that would allow you to just combine the gate key commitments directly.
03:23:53	gmaxwell:	But really the xor-homorphic commitment only needs to be xor-homorphic for a single bit, which means straight up additive homorphism over any field should work. E.g. the commitment can be X*g in some EC group.
04:38:44	gmaxwell:	Oh, interesting. I can get a simpler CoinSwap protocol if prior to any transactions, one party proves to the other H(X),H(Y),X xor Y for some undisclosed X,Y in other words, having this proof in hand you know that if you know the preimage of H(X) the you also know the preimage of H(Y).
04:39:20	gmaxwell:	I think I can do a proof for H(X),H(Y),X^Y with sha256 under 40 megabytes now.
04:40:47	gmaxwell:	(the coinswap is simpler from a protocol perspective because you just prove this relation externally to me, then we can just make parallel hashlocked payments knowing that one will reveal the other without a public linkage.
04:43:18	maaku:	maaku is now known as Guest85612
05:02:13	vector7:	vector7 has left #bitcoin-wizards
06:00:54	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
06:01:21	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
06:17:18	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
06:56:33	Guest85612:	ethereum discussion on the front page of HN : https://news.ycombinator.com/item?id=7041628
06:56:53	Guest85612:	Guest85612 is now known as maaku
07:06:22	justanotheruser:	maaku: do they have some prevention from people making infinite loops?
07:06:40	justanotheruser:	If I wanted to attack the currency I would just mine an infinite loop into the blockchain
07:13:34	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.
07:13:49	gmaxwell:	shesek: https://bitcointalk.org/index.php?topic=321228.0
07:14:00	shesek:	with coinswap and 4 transactions?
07:14:36	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.
07:14:50	shesek:	yeah, I know, but this is a much more elegant solution
07:15:37	shesek:	though, as I mentioned above, being somewhat identifiable as transactions meant for that purpose is somewhat problematic until this is commonly used
07:16:29	shesek:	if there are only two transactions in a whole day that uses hashlocked transactions its quite easy to link them together
07:17:37	shesek:	maaku, too bad its down though
07:18:11	shesek:	someone from HN posted it to pastebin: http://pastebin.com/NCGRv74u
07:21:43	shesek:	oh, seems like it was published for some time now... I didn't hear of it until now
07:25:17	gmaxwell:	shesek: you need to review the coinswap page.
07:25:43	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.
07:26:12	shesek:	are you talking about coinswap or the new idea you had?
07:26:17	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)
07:26:22	gmaxwell:	shesek: coinswap.
07:26:37	gmaxwell:	but that cost is that the protocol has a bunch of stages.
07:26:38	shesek:	that "they look unique which can link them" was referring to your idea posted here, not to coinswap
07:26:44	gmaxwell:	oh! okay yea.
07:27:02	gmaxwell:	Well you could perform the same transform to this, but then you lose the fact that its simpler. :P
07:27:20	gmaxwell:	in any case, lots of uses for hashlocked transactions. so perhaps they'll be common at some point.
07:30:05	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
07:31:10	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
07:31:36	gmaxwell:	yea, I'd proposed the non-private version of that pattern for exactly that purpose.
07:32:17	shesek:	(^ is regarding the transactions being unique)
07:34:16	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?
07:51:02	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"
07:51:10	shesek:	does something like that makes sense?
07:52:42	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:21:31	roidster:	roidster is now known as Guest5397
14:13:30	roidster:	roidster is now known as Guest25778
14:20:26	_ingsoc:	_ingsoc has left #bitcoin-wizards
16:30:42	_ingsoc:	_ingsoc has left #bitcoin-wizards
18:50:23	gmaxwell:	andytoshi: mostly I think a reduction in failed signings is worth it, and if the tool itself were misbehaving you're likely screwed.
18:50:32	_ingsoc:	_ingsoc has left #bitcoin-wizards
18:52:28	andytoshi:	gmaxwell: agreed
18:52:50	andytoshi:	i wish i didn't need to demand a wallet passphrase in a program that is openly communicating with my server
18:52:53	andytoshi:	the optics are terrible
19:22:14	jgarzik:	Bitcoin blockchain torrent updated, 70% of previous bootstrap.dat is re-used. https://bitcointalk.org/index.php?topic=145386.0
19:46:08	_ingsoc:	Does anyone know if Vitalik Buterin hangs out on Freenode?
20:10:47	maaku:	maaku has left #bitcoin-wizards
20:37:07	wyager:	So who's read the ethereum whitepaper?
20:38:26	wyager:	It's very interesting, but I think it might prove very difficult to manage
20:57:02	maaku:	wyager: incentives for computation is wrong
20:57:27	wyager:	How so? I'm not particularly enamored with the incentive model, but I thought it seemed OK
20:57:44	maaku:	there's no point in paying miners fees for computation, when the miners are not doing the compuation
20:58:11	wyager:	Aren't they?
20:58:15	maaku:	no
20:58:19	maaku:	validating nodes are
20:58:31	maaku:	most miners are not validating nodes
20:58:37	justanotheruser1:	everyones doing the computation, only the miners are getting paid right
20:58:48	maaku:	and worse, they are getting paid proportional to hash power
20:58:53	maaku:	which has nothing to do with the computation
20:58:55	wyager:	So when a program broadcasts a transaction, every single validating node broadcasts the transaction?
20:59:02	justanotheruser1:	maaku: why wouldn't the miners be validating nodes? If they had something invalid in their block it would get rejected right?
20:59:12	maaku:	*every single validating node computes the transaction
20:59:26	justanotheruser1:	justanotheruser1 is now known as justanotheruser
20:59:45	maaku:	justanotheruser: no, nearly all miners use pools
20:59:47	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?
20:59:54	maaku:	and a pool only needs to run a single validating node
21:00:25	justanotheruser:	maaku: oh, I see what you're sayinh
21:00:49	maaku:	e.g. GHash.io and BTC Guild each only need to run one validating node
21:00:57	maaku:	and yet they together get more that 50% of the reward
21:01:08	maaku:	and the thousands of people running validating nodes for non-mining purposes get nothing
21:01:15	maaku:	(but still have to run the computation)
21:01:54	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
21:02:27	justanotheruser:	I wish there was a way to reward validating nodes. But I don't think there is without risky sybil
21:03:05	maaku:	the best approach is to make it truly cheap to run validating nodes
21:03:09	maaku:	and/or make it so they are not required
21:03:52	justanotheruser:	maaku: what do you mean "make it so they are not required"? Wouldn't them not validating make them not validating nodes?
21:05:13	maaku:	make it so that whatever application you needed a validating node for, you don't anymore
21:05:32	maaku:	e.g. because you have a succinct proof of validation (so you don't need to validate it yourself)
21:07:15	justanotheruser:	ok
22:15:37	gmaxwell:	so, actually implemented my ZKP, a proof of sha256 is 47mbytes.
22:16:45	gmaxwell:	(for ~123 bit security)
22:18:04	gmaxwell:	and validation requires about 1 million EC multiplies with the generator and about 4 million hash operations.
22:20:41	sipa:	that's a proof for "i have some input you don't know, which hashes to X" ?
22:24:15	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.
22:24:55	gmaxwell:	or for 2x that cost I can do my "Z is the xor of the preimage for hashes X and Y"
22:25:14	gmaxwell:	now I should go see if ripemd160 can be done with fewer gates.
22:33:51	andytoshi:	this is really exciting, thanks for doing this work gmaxwell
22:35:39	petertodd:	gmaxwell: +1
22:36:00	sipa:	indeed, very nice to see some things actually being done
22:36:06	sipa:	instead of the mostly talk here :p
22:40:19	justanotheruser:	gmaxwell: Is this related to SNARK?
22:44:07	andytoshi:	more of a NARK :P