06:46:54	phantomcircuit:	wumpus, gmaxwell afaict darkcoin almost never has a useful coinjoin, effectively 100% of transactions involve you and the coordinating server
06:46:59	phantomcircuit:	(which is why they're required to have capital)
06:47:42	DEREK|:	DEREK| is now known as [Derek]
09:16:51	justanotheruser:	phantomcircuit: Yes, they will advertise it as being decentralized, but it is really distributed. They also use blind signatures in a way that doesn't really help them. The masternode still knows which inputs are associated each output.
09:17:30	justanotheruser:	Ideally, there would be one big decentralized coinjoin network, but I have no idea whether that it is vulnerable to DoS.
10:00:06	samson2:	samson2 is now known as samson
10:42:04	jctb_:	jctb_ is now known as jctb
10:53:09	petertodd:	justanotheruser: I wrote up ways to make the decentralized coinjoin network DoS resistant months ago; darkwallet will eventually implement that stuff to extend the existing semi-centralized/federated model.
10:54:20	petertodd:	justanotheruser: fwiw right now dark wallet *doesn't* trust the central "meetup" servers very much - comunications arranging the coinjoins *are* encrypted. I need to get a chance to look at the details, but I believe right now we probably have better privacy than darkcoin because of that.
13:02:12	c0rw|bbq:	c0rw|bbq is now known as c0rw1n
14:29:23	maaku:	that's a pretty low bar
14:32:08	samson:	samson is now known as samson_
16:17:59	roidster:	roidster is now known as zzyzx
16:18:59	zzyzx:	zzyzx is now known as ZZyZX
16:26:00	ZZyZX:	ZZyZX is now known as roidster
16:27:52	roidster:	roidster is now known as ZZyZX
17:34:39	nickler_:	nickler_ is now known as nickler
18:09:29	justanotheruser:	petertodd: link to DoS resistant coinjoin.
18:10:56	justanotheruser:	Also, this big coinjoin network would use some blind signature scheme to hide IO association, right?
18:18:34	mr_burde_:	mr_burde_ is now known as mr_burdell_
18:29:05	mr_burdell_:	mr_burdell_ is now known as mr_burdell
18:29:20	[\\\]:	[\\\] is now known as imsaguy
18:56:30	petertodd:	justanotheruser: it's on bitcointalk, and I think bitcoin-devel - basically resist DoS by making communication have some cost
18:57:13	petertodd:	justanotheruser: re: blind sig schemes, there's no clear advantage of them vs. two-party coinjoins used on every transaction, and the two-party schemes are much nicer for user acceptance because txs happen quickly
18:58:33	justanotheruser:	petertodd: so do n coinjoins to have O(n^2) and omega(2) sized anonymity sets?
18:58:39	justanotheruser:	If I
18:59:02	justanotheruser:	'm allowed to use big O for anonymity set sizes :P
18:59:41	justanotheruser:	It costs quite a bit more to have multiple 2 person tx doesn't it?
19:03:49	Luke-Jr:	petertodd: I don't see how adding cost makes DoS harder.
19:04:19	Luke-Jr:	well, I guess it makes CoinJoin poisoning specifically harder
19:11:25	gmaxwell:	petertodd: huh? multiparty can be just as fast as two party if the parties are all present. If there is a failure you can always degrade two party, and do so in a few hundred milliseconds (just a rtt)
19:14:14	justanotheruser:	gmaxwell: how long do you wait for every user to sign the tx?
19:16:19	gmaxwell:	one RTT plus two rtt std dev, or some approximation there. Basically you can do multiple parties with ~no delay cost, since you can always degrade to the two party if you cross whatever delay threshold you choose.
19:17:50	justanotheruser:	gmaxwell: What is RTT?
19:18:03	justanotheruser:	Nevermind
19:18:57	justanotheruser:	So how does it prevent someone with 1000 outputs they can redeem from spamming every coinjoin with joins they don't fufill?
19:19:57	gmaxwell:	justanotheruser: by blacklisting the 1000 outputs. basically their non-fufillment only has a cost of however many ms delay they add before you punt them. then they're punted and that output is forever banned and you retry.
19:20:30	gmaxwell:	if the cost of the attack is low your protection against it doesn't have to be especially strong.
19:21:06	gmaxwell:	(and realisitcally, if the effect is just that it slows things down a bit— well there are already MUCH worse ways that you can attack the bitcoin network)
19:21:13	justanotheruser:	gmaxwell: so I won't join any coinjoins that involve them?
19:21:41	justanotheruser:	What if I have a coinjoin with 99 other people and they join with a blacklisted account and I'm the only one that has them blacklisted?
19:22:06	gmaxwell:	justanotheruser: no, they just won't be included in a join. Well that depends on how you're handling the blacklisting.
19:22:18	gmaxwell:	(also, doing a join with 99 inputs is not very reasonable)
19:22:51	justanotheruser:	Who determines whether they're included in a join? If 90% of people don't have blacklisted, what's the behavior?
19:36:23	gmaxwell:	justanotheruser: depends on the particular implementation.
19:36:39	gmaxwell:	The most straight forward ones are where a participant or some kind of server is master of the join.
19:36:53	gmaxwell:	in which case you can just let it decide who it includes.
21:27:33	amiller:	i'm concerned about a problem with Zerocoin/Zerocash, petertodd and gmaxwell
21:27:46	amiller:	isn't it possible that you could still do "opt-in" white listing?
21:28:38	gmaxwell:	Can you elaborate further?
21:28:57	gmaxwell:	you mean couldn't miners censor the network unless transactions included (perhaps encrypted) proof of ID?
21:29:02	gmaxwell:	Absolutely.
21:35:34	amiller:	not even miners necessarily, whatever is the Zerocash version of "Coinbase" could give privileges to coins that have participated in a process that ties them to ID something like that
21:37:33	phantomcircuit:	https://imgur.com/gallery/E3PedCc
21:37:35	phantomcircuit:	LOL
21:41:06	gmaxwell:	amiller: yes, some of those people are interested in proposals that do that in Bitcoin. Though in practice it might harder to deploy in something that was private by default.
22:36:59	amiller:	well, if we're already using SNARKs, I wonder if there's some way to improve security by making it dangerous to participate in a whitelist scheme
22:37:14	amiller:	analogous to the snarky nonoutsourceable puzzle, but for volutnar ydeanonymization
22:37:50	petertodd:	amiller: if you can come up with a way of banning whitelisting I'll be impressed, but in the meanwhile, first things first
22:38:48	petertodd:	Luke-Jr: transactions are an example where adding cost makes DoS harder
22:40:29	petertodd:	incidentally, re: zerocash, something I somehow totally didn't consider earlier was that zerocash can be used for colored coins by adding a color id to the proofs
22:41:02	petertodd:	(one of the zc team mentioned it to me today - I'm in israel meeting with a few of the scip team)
22:41:19	petertodd:	s/zc/zc\/scip/
22:41:50	gmaxwell:	I should probably forward you the emails I sent to Ian previously, I think I'd pointed that out before. :)
22:42:12	petertodd:	gmaxwell: good to make stuf like that public...
22:42:29	gmaxwell:	I didn't have a good way to do the apply token covenant though.
22:42:45	gmaxwell:	e.g. tracking is easy but I didn't solve the getting the marker on in the first place problem.
22:43:05	gmaxwell:	(except by making the marker really big (e.g. a scripthash).
22:43:09	gmaxwell:	)
22:43:25	petertodd:	hmm, yeah, I should ask him for more details
22:43:39	gmaxwell:	e.g. "this script was satisfied at some point in the coin's history to allow the addition of this marker"
22:44:11	petertodd:	yup
22:44:43	gmaxwell:	it's important that it always be possible to remove a marker, otherwise you get some pretty ugly results wrt fungiblity.
22:44:54	petertodd:	I'm meeting with eli ben sasson on wednesday, and eran trommer monday
22:45:36	gmaxwell:	Wish I was there. :) Please don't unconvince Eli that non-CRS ZKP is important to us in the long term. :)
22:45:49	gmaxwell:	(I want people still working on that!)
22:47:17	petertodd:	I'm sure he'll be sufficiently bored by my concerns tht he keeps working on it...
22:47:26	gmaxwell:	Also, rumor has it that they were going to release some tools. .. man that would be nice. I'd really like to get some proof of coin ownership stuff going fast.
22:47:34	petertodd:	I hear rumors that there was a major breakthrough in recursive proof eval too
22:47:46	gmaxwell:	That could be good or bad.
22:47:47	gmaxwell:	:P
22:47:48	petertodd:	yes, tools will be released soon
22:48:14	petertodd:	well, recursive proof eval is just an optimization...
22:48:21	gmaxwell:	(I mean the proof around q-KoE that allows the snark recursive composion seems very handwavy to a lot of people)
22:48:41	gmaxwell:	not so, recurisive proof evil is is necessary part of the constant size proofs.
22:48:46	gmaxwell:	er eval*
22:48:50	petertodd:	heh, yeah, the breakthrough could be proof it's impossible, lol
22:49:03	gmaxwell:	yea, haha thats what I meant by could be bad. :P
22:49:19	amiller:	petertodd, is ale chiesa also there for your meeting
22:49:26	petertodd:	amiller: dunno
22:49:58	gmaxwell:	maybe someone figured out how to get recursive proof eval in the random-oracle model. That would be amazing. :P
22:50:06	amiller:	i got to talk with him at oakland for a while, he seems to be the only one really working on non-CRS zk stuff
22:50:47	petertodd:	amiller: cool - remind me again what CRS was again? the trusted setup?
22:50:58	gmaxwell:	yea, the trusted setup.
22:51:00	amiller:	yes CRS is the trusted setup
22:51:03	petertodd:	right
22:51:19	amiller:	not just trusted, but also inherently requires knowledge of a "trapdoor"
22:51:55	amiller:	and it doesn't seem logically possible to get the "of Knowledge" i.e. the K in snarK, without that, so it's pretty tricky
22:52:15	petertodd:	well, like I've said before, engineering-wise I don't see it as a dealbreaker, but nice to get rid of if possible
22:52:37	gmaxwell:	well it's not just the pratical implication of a trapdoor, it also complicates the cryptographic argument in general.
22:52:50	gmaxwell:	It means there is a very complex hardness assumption.
22:53:03	petertodd:	we *will* get broken CRS systems as the next alt-coin scam - an argument for actually going ahead and making the tools to make it easy to do that scam
22:54:05	amiller:	i'm happy for now assuming snarks exist and doing applied snarkistry for everything i want, i'd also be happy to switch to libsnark instead of pinocchio when that comes out
22:54:15	gmaxwell:	e.g. maybe it's possible in general to totally bypass the knoweldge requirement, even for someone who doesn't know the CRS trapdoor. No one knows how to, but a fair number of people are less than convinced that you can't.
22:54:41	gmaxwell:	petertodd: amiller has pinocchio working.
22:54:51	gmaxwell:	(at least well enough to benchmark it)
22:54:55	petertodd:	gmaxwell: that's the one with shit licensing terms right?
22:55:43	gmaxwell:	it's the msft implementation, yes, though I don't know that the licensing terms matter so much. The verifier for it is trivial, you can go implemnt the verifier yourself in about a half hour with libpbc or whatever. And its the verifier whos licensing terms are the most important usually.
22:56:54	petertodd:	hmm, well, I guess in this space for many of the applications people can break licenses anyway...
22:56:57	gmaxwell:	Obviously better licensing is important too... but I think not a deal breaker at least for some applications.
22:58:00	petertodd:	also, after israel I fly to istanbul, barcelona, and glasgow - the latter two to meet with amir taaki and the guys behind maidsafe, the former I have 20 hours to kill :P
22:58:26	gmaxwell:	e.g. the only licensed code in pinocchio that probably matters at all is the prover code. The verifier is trivial, the circuit generator probably has no legal basis (e.g. your copyright interest in a compiler cannot generally encumber the output)...
22:59:10	petertodd:	how complex is the prover?
22:59:21	gmaxwell:	but if in your discussion with folks licensing comes up you can mention that concerns about licensing do block some usage, so that should be avoided.
22:59:31	petertodd:	gmaxwell: will do
23:00:13	petertodd:	gmaxwell: gpl would probably be best for this stuff; still lets them monetize and encourages inspectable security software
23:00:27	gmaxwell:	I have nfi on the prover, I assume it's complex. certantly there are a lot of fairly complex performance things you can do to speed it up.
23:02:06	gmaxwell:	petertodd: GPLv3 prover, LGPLv3 (or, if more liberal, an apachev2 license) verifier would be great for most of the infrastructure applications. (I say apache not MIT and GPLv3 because an explict patent grant is helpful for improving confidence)
23:03:01	petertodd:	gmaxwell: agreed - libbitcoin recently had some discusion w/ the debian team, and in the end they approved a AGPL3 license with some exception terms
23:03:01	gmaxwell:	(both apache v2 and gplv3 have terms that basically say that you're not being an indian giver, allowing copyright but denying access to any patent interest you may have— still doesn't block third party patent claims)
23:03:18	petertodd:	pretty sane IMO
23:04:07	petertodd:	the arguments for LGPL - let the user fix/change things by relinking - are very applicable w/ security critical software
23:04:14	gmaxwell:	A lot of really great crypto has been removed from public use due to patents. PAKE, most ecash stuff (e.g. chaum)...
23:05:46	gmaxwell:	Yea, a fun example of that: when the heartbleed stuff came out Mozilla found that its propritary video conferencing tool (Vidyo) used by everyone everywhere in the company, was leaking username/passwords. It took the vendor days to fix the software, so in the meantime it had to be turned off, and everyone had to change their passwords. Hundreds of meetings had to be postponed (since just about every meeting includes remote ...
23:05:51	gmaxwell:	... participants).
23:06:09	gmaxwell:	vs if it could have been relinked it would have been fixed within an hour or two.
23:06:42	petertodd:	ha, nice
23:06:59	gmaxwell:	(there was talk of just patching the binary, I'm not sure if thats ultimately what was done, but the space of orgs that could patch a binary to fix something like that is much smaller than ones which could relink)
23:07:18	petertodd:	I'm thinking of changing python-bitcoinlib to LGPL3 myself (which of course actually means licensing any new contributions as that)