00:59:18	zzyzx:	zzyzx is now known as roidster
00:59:48	roidster:	roidster is now known as Guest24978
01:56:46	qwertyoruiop:	qwertyoruiop is now known as Guest73673
03:28:34	copumpkin:	copumpkin is now known as ubiquipumpkin
03:30:10	justanotheruser1:	justanotheruser1 is now known as justanotheruser
04:01:49	ubiquipumpkin:	ubiquipumpkin is now known as copumpkin
04:22:04	iddo:	amiller: we're working on the variant without trusted setup, pinocchio and current scip need CRS anyway
04:23:01	iddo:	proof size an verification time will be longer, proof time i'm not so sure, maybe even shorter
04:25:57	iddo:	and the assumptions are more conservative, just stuff like fiat-shamir and CRH, instead of revealing multiple powers of some DLP to make calculations faster etc.
04:27:06	iddo:	trusted setup doesn't make much sense in many real-world scenarios
04:27:10	amiller:	yeah trusted setup sucks
04:28:07	iddo:	unless you'd do large-scale MPC for the trusted setup or something...
04:32:40	iddo:	MPC people claim that their state of the art constructions are fast (with cut-and-choose to resist malicious parties), but not sure about actual working code
05:17:46	maaku:	how much larger and longer?
05:18:12	maaku:	trusted setup actually works in more scenarios I can think of
05:18:31	maaku:	but yes the really cool stuff requires trustless setup
05:19:12	petertodd:	in most cases you only need the trusted setup to be done honestly once
05:20:08	maaku:	or have two trusted setups by competing interests, and do multisig
05:23:53	iddo:	maaku: you mean bloat everything by requiring two separate proofs every time?
05:24:27	iddo:	makes more sense that the competing interests run MPC for a single trusted setup
05:24:44	iddo:	because if they collude then they can collude with your idea too
05:26:23	petertodd:	iddo: note that many of these systems can be reused for other purposes, e.g. zerocash can be reused for anonymous identities and vice-versa
05:26:41	iddo:	petertodd: done honestly == destroy the CRS
05:27:19	petertodd:	iddo: of course
05:27:29	iddo:	how is being reused for other purposes related to trusted setup ?
05:28:31	petertodd:	iddo: because the circumstances where the trusted setup fails are related to what its' being used for - more likely that a seemingly innocuous anon identity system is setup honestly than "death market reloaded"
05:29:47	iddo:	but it's not "verifiably" done honestly, you can keep the CRS of the anon identity system in encrypted form for you grandchildren or something
05:30:32	Eliel_:	petertodd: you don't happen to have a link to a text discussing pros and cons of block reward averaging (this channel feels more appropiate)
05:31:37	petertodd:	Eliel_: there are no pros, just the cons of it being more complex than a simple announce/commit, which in turn is a bad idea for centralization reasons
05:33:13	iddo:	petertodd: did you hear of two video cameras idea for zerocash?
05:33:54	petertodd:	iddo: no?
05:36:15	iddo:	having two cameras rolling nonstop recording a committee of well-known persons pick random computer from the phone book, go buy a new laptop there, insert cd and verify its hash and run the trusted setup, output the verifier/prover keys, and destroy the laptop :)
05:36:49	petertodd:	iddo: oh sure, that's obvious, what's not as obvious is they should be film cameras, not digital
05:37:11	iddo:	hmm why film cameras ?
05:37:46	petertodd:	iddo: so everything electronic other than the laptop can be removed to prevent anyone hacking into said laptop, e.g. actually turning on the laptop should be done far away in the desert
05:38:06	iddo:	ahh
05:39:10	iddo:	if they start the laptop with their cd, and you can examine their cd later, maybe you wouldn't see ways to hack it?
05:39:16	petertodd:	boot up the laptop with a pre-built cd, run the generation program, burn a new cd with the parameters, burn the laptop
05:40:02	petertodd:	the cd with the parameters travels back to an even bigger group, who then make copies of it and upload it to the net
05:40:06	iddo:	the cd should have hash of everything on it, and the cameras should record that hash ?
05:40:11	petertodd:	then burn that cd
05:40:23	petertodd:	well, the cd coming back is another possible way of getting the secrets out
05:41:01	petertodd:	ideally you'd just write it down by hand, but unfortunately most of these schemes need fairly big public parameters
05:42:04	iddo:	i'm not sure that i understand, the cd when run will fetch some randomness from devices i.e. /dev/random etc., and create the prover/verifier keys according to this randomness
05:42:34	iddo:	you just need to make sure that the hash of the code that you'd run (without the randomness) is the legit code?
05:43:01	petertodd:	iddo: my point is you don't want there to exist some backchannel you didn't think of that smuggles the secret seed out
05:44:02	iddo:	yes smuggles, but if you're running this cd on new laptop, how easy is it to hack into that, if you can examine the entire cd later?
05:45:54	petertodd:	when you say "new laptop", which new laptop are you referring too?
05:45:59	iddo:	not so sure if film cameras are helpful, unless you could record and make sure that nobody else on the committee carries any other digital devices in his pocket
05:46:26	petertodd:	the cameras are to make it harder to get away with fraud basically - give evidence that what the witnesses claimed happen did happen
05:46:30	iddo:	the new laptop that they picked randomly by picking a random computer store from the phone book
05:47:16	petertodd:	right, so the boot cd is to ensure the code run was what people thought was run, the second cd is to try to control what avenues exist to get a secret key out
05:48:42	maaku:	iddo: size of the scriptSig doesn't matter
05:48:42	gmaxwell:	problem is that the laptop's hardware was hacked off camera and the screen backlight is modulated by the seed scraped out of ram by the frmware.
05:49:00	gmaxwell:	maaku: careful. :) so a 1gb scriptsig is okay? :P
05:49:06	iddo:	maybe there isn't a second cd? just print or photocopy the verifier/prover keys ?
05:49:35	petertodd:	gmaxwell: indeed, which is why the cameras need to follow the process from buying the random computer in a store to the trip out to the desert, and reembmer that *where* in the desert has to be picked randomly
05:50:12	maaku:	gmaxwell: if N bytes is okay, I'll wager that 2N bytes is okay
05:50:18	petertodd:	iddo: again, I'm being practical, copying them down on pen and paper would be better, but multi-gb keys are needed in many of these systems
05:50:26	gmaxwell:	it's all pretty ugly though, conspiracy theories forever. For some applications this would be okay, for others...
05:51:08	petertodd:	I'll bet you in practice the conspiracy theories don't prevent people from using this stuff
05:51:30	gmaxwell:	yea, getting the proving keys out is kind of a pain. this is also why using mpc for this is hard... it's not just a tiny bit of computation.
05:51:40	maaku:	personally I would never, ever, under any circumstances use a currency that has trusted setup proving keys, no matter what fancy MPC was used
05:51:52	iddo:	petertodd: yes i forgot that the prover key is 1 gigabytes with zerocash, maybe computer connected to printer is better than burning the second cd, not sure
05:52:00	gmaxwell:	petertodd: nothing, including being pointeless or insecure completely stops people but each flaw is another paper cut that sucks value out of the system.
05:52:07	gmaxwell:	pointless*
05:52:42	petertodd:	gmaxwell: this is not unlike the dnssec signing party
05:52:57	gmaxwell:	maaku: bet you'd use it in cases where the alternative was to just hand your funds over to some sketchy trusted third party... but really, since better can be done, better ought to be done.
05:54:02	petertodd:	gmaxwell: it's all a matter of tradeoffs, a signing party can be done today, and realisticly, just generating it and publishing the fact that you did so later may in reality be the least risk way re: compromise...
05:54:39	petertodd:	gmaxwell: particularly if one group does that strategy, and another group does the all out public/auditted method, and yuou use a n-of-n system for actually using the proofs
05:56:23	gmaxwell:	N fold increase in proving time is really painful for some applications. (also keep in mind, generation is per circuit, and the tinyram approach of having a universal circuit has considerable overhead for the prover)
05:56:53	petertodd:	meh, it's an engineering tradeoff, MPC solutions don't yet exist for this stuff
05:59:39	maaku:	gmaxwell: I don't believe in false choices :)
06:03:57	petertodd:	maaku: well, what are the choices?
06:05:37	gmaxwell:	get the non-CRS tech from theory into practice.
06:06:03	gmaxwell:	and get the CRS tech stuff deployed where its only additive security, and thus less risky, first.
06:06:12	petertodd:	ok, so timeline for this? how close is that?
06:06:58	gmaxwell:	Would probably be a lot closer if some of us dropped whatever we were doing and went to work on it. :( I think it's partially ratelimited on programmers.
06:07:24	petertodd:	hm, the impression I get is even the trusted setup phase stuff is pretty experimental
06:08:08	maaku:	also free software, unencumbered implementations
06:08:34	petertodd:	indeed
06:08:53	gmaxwell:	software from theoreticians, as far as I can tell what happens is that they hang out at conferences until they spot a passing programmer who they can net, and feed them ramen until something compiles and they're forced to release them.
06:09:19	petertodd:	heh
06:10:21	gmaxwell:	(unfortunately, in academia— or at least in some parts of it— its arguably that being a competent software engineer is actually a career limiting move... as you get to become everyone's coding monkey. :( I think it's like typing skill, from some decades earlier.)
06:10:32	gmaxwell:	Or so I am told.
06:10:47	warren:	input ramen, output code, check.
06:10:48	petertodd:	so is the non-CRS tech harder or easier programming than CRS tech? because part of what may get you those programmers is to have lesser programmers practice implementing the easier stuff first...
06:11:45	gmaxwell:	My understanding is that quite a bit of it is simpler. But without staring at an implemententation that could be widly wrong, since 'simpler' can mean a lot of things. :)
06:12:22	petertodd:	all this is pointing to "ship v1.0 by relying on a desert camping trip" IMO...
06:12:49	petertodd:	perfect is the enemy of good, e.g. in the zerocash case, the money to be lost is realisticly constrained
06:13:06	maaku:	gmaxwell: I've heard that in space science as well (CS background hindering advancement)
06:13:27	petertodd:	maaku: it's true in physics too
06:13:28	gmaxwell:	maybe, then again, if 1.0 was insecure, an upgraded proof system can't undo any secret inflation that happened previously.
06:13:49	petertodd:	gmaxwell: so what? it wouldn't be the first time people have lost money - accept it and move on
06:14:13	maaku:	petertodd: there's a difference between people losing money and inflating the entire economy N-fold
06:14:43	petertodd:	maaku: you can't inflate the economy in a zerocash system - what goes in must be >= what goes out
06:15:05	gmaxwell:	not if the proofs are compromised, thats the point. :)
06:15:16	gmaxwell:	(or maybe you're defining in and out at some other level?)
06:15:27	petertodd:	gmaxwell: no, think about it, in and out being defined as conversion to and from actual bitcoins
06:16:05	gmaxwell:	okay, some other level. Yes, the impact can't be larger than all the people who use it.
06:16:19	gmaxwell:	(other than perhaps screwing up the confidence in the tech)
06:16:22	maaku:	if you're imagining a zerocash side chain then that is true -- someone is left holding the bag
06:16:24	petertodd:	indeed, which *is* acceptable I think
06:16:26	gmaxwell:	(but I think having good warnings helps with that)
06:16:32	maaku:	but if people decide to transact in zerocash only...
06:17:26	petertodd:	gmaxwell: not unlike the multiple "dark wallet is alpha" warnings... including my latest one specifically saying the stealth address standard can and almost certainly will be "hard-forked" prior to a beta
06:18:40	gmaxwell:	petertodd: you're keeping an eye on the stealth address stuff right, not letting people do anything too stupid— right? I am not follow it right now. I'm trusting that you'll prevent it from being too vomit worthy. :)
06:19:26	petertodd:	gmaxwell: I'm benevolent dictator on it, don't worry, if anything is moving relatively slowly actually
06:19:44	gmaxwell:	Okay good.
06:19:55	iddo:	petertodd: about whether non-CRS being easier/harder to implement versus CRS, it's different constructions it's uncomparable in a sense, but the thing is, in non-CRS the initial non-optimized version will be quite inefficient with large proofs and there's a lot of room for optimizations, so in this sense the non-CRS is a bigger project to do
06:20:00	gmaxwell:	(not good to the slow, mostly good to you having a role in it)
06:20:45	petertodd:	gmaxwell: I dunno, I'm quite happy for it to be a bit slower - heck I'm delibrately going to try out the backwards compatible upgrade scheme I came up with prior to a beta to make sure it actually works
06:21:37	petertodd:	iddo: yeah, sounds like trusted setup is the way to go for version 1.0 then :) I'm relatively confident that the trustworthy person part is the least of our worries
06:22:55	iddo:	petertodd: i think that CRS is a worry, the kind of people who are attracted to full anonymity also dislike backdoors
06:23:15	petertodd:	iddo: they also can and should distrust depending on any one system!
06:23:41	iddo:	petertodd: one of the other worries is that you cannot prune history with zerocash, unlike having miners maintain only UTXO set in bitcoin
06:23:44	petertodd:	iddo: I'll take the one opportunity for a backdoor over never ending dependence on trusted third parties...
06:23:54	petertodd:	iddo: there doesn't have to be only one zerocash you know
06:24:01	gmaxwell:	petertodd: I'd still feel a lot better to see some non-heart-of-a-currency uses using this thing yet. It's like going from engine tests straight to manned spaceflight. :P
06:24:45	petertodd:	gmaxwell: zerocash is not the heart of a currency if implemented sanely
06:25:10	gmaxwell:	(heck forget manned spaceflight, going from engine tests to launching a space colony :) )
06:25:27	iddo:	in zerocash the set of all the serial numbers of spent coins must be kept for future proofs, you cannot prune anything, it doesn't scale well if many people would actually use it
06:25:36	warren:	someone has been storing huge things in testnet
06:25:50	petertodd:	no, it's going from sputnik 1 to sputnik 2 - it's unfortunate if the dog dies, but you're not surprised
06:25:51	gmaxwell:	iddo: thats the kind of engineering I can expect PT to improve.
06:26:31	petertodd:	gmaxwell: indeed - that's a simple enough problem even an arts student could figure out a better way
06:27:02	gmaxwell:	I think sputnick is using the ZKP for something like a blinded passport/fidelity bond. :) consequences of failure are not only unsurprising but also not large, but it would still be interesting to attack.
06:27:39	gmaxwell:	iddo: there are some pretty obvious tradeoffs you can do right out of the gate, e.g. if you do not mind old long unspent coins expiring you can automatically have pruning.
06:28:11	gmaxwell:	(and also make your ZKP more efficient because you don't need quite as deep a hashtree if you're going to be rolling it over)
06:28:37	iddo:	gmaxwell: you might lose anonymity with such tradeoffs, and also network bloat where people do dummy txns that they otherwise didn't wish to do
06:29:35	gmaxwell:	Right but you lose anonymity when people don't ues the system at all— e.g. the fact that it's known that you're spending a txout from one of the most recently ... say. .. 16million ... isn't much leakage just compared to the list of people who've used the system at all.. :)
06:29:38	petertodd:	iddo: it's an engineering tradeoff, and frankly, serial numbers aren't all that big
06:30:14	iddo:	also the actual zerocash system cannot support this coin expiration stuff, you'll need to add support for it
06:30:42	gmaxwell:	iddo: adding support is just having multiple trees. and signaling external to the proof which root you're working against.
06:30:51	gmaxwell:	doesn't change the circuit, it's all node engineering.
06:31:10	petertodd:	iddo: zerocash hasn't been written yet :) basically the serial numbers are partially deanonymized to support a epoch level timestamp
06:31:14	gmaxwell:	(though, as I said, you might want to reduce the maximum depth of the zkp to gain performance in the prover)
06:31:19	iddo:	hmm that's not what i had in mind... maybe you're right
06:32:35	gmaxwell:	This was my like ... first ten seconds of thinking about it, coming from the perspective of having spent a lot of time on bitcoin scalablity thinking. It's possible even better can be done, and all external to the underlying ZKP cryptosystem. It's not magic, it's a set of tradeoffs... but reasonable things can be done.
06:34:54	iddo:	yes i guess loss of anonymity can be negligible, but the dummy txns that users have to do or otherwise they lose their money, that's ugly...
06:35:45	iddo:	both for network health, and for individual use peace of mind...
06:35:56	gmaxwell:	That arguably has some benefits... right now lost and refound private keys may create economic shocks in bitcoin. Also PT has some ideas where epochs don't result in unspendability.
06:36:01	petertodd:	iddo: easy to make the serial number list big enough that we're only talking about moving once every few years
06:36:33	petertodd:	iddo: and yeah, as gmaxwell says, epochs don't even have to mean stuff becomes permanently unspendable, just more annoying/expensive to spend
06:36:56	iddo:	nice
06:37:00	gmaxwell:	Basically when an epoch is done nodes could forget it, and it's up to the spender to provide a larger membership and update proof to show they're doing the right thing wrt these old pruned epochs.. though if the forgetting is slow enough its probably better to actually forget.
06:51:57	davidlatapie:	Hi, what Anonymint posted about Zerocash and Monero: https://bitcointalk.org/index.php?topic=583449.msg6662938#msg6662938
06:53:26	gmaxwell:	davidlatapie: you really should put anonymint on ignore.
06:54:35	davidlatapie:	gmaxwell: I don't have the necessary technical skills to judge the quality of his answers - of course he has some ego issues, that's for sure :)
06:55:37	gmaxwell:	He is not technically sophicated himself, he basically produces a lot of technobabble and counts on more skilled people arguing with him to refine it.
06:56:05	gmaxwell:	Though I think if you don't let the buzzwords snow you, even someone without a lot of technical background can usually see through his arguments.
06:58:17	gmaxwell:	(e.g. he commonly argues against random technical proposals by making basically irrelevant arguments like someone with an infinitely powerful computer could crack them. "um okay, sure. But that basically breaks everything else too, why are you commenting here??")
06:59:02	gmaxwell:	and then yea, he's super rude too— so the combination of ignorance and extreme ego is .. well, not worth anyone's time.
07:15:45	maaku:	iddo: it's relatively straightforward to prune serial numbers if you include certain proofs-of-uniquenes. we've worked this out on wizards before
07:42:06	iddo:	maaku: interesting... link? or else please elaborate?
09:27:11	[BNC]dansmith:	[BNC]dansmith is now known as dansmith_btc
09:50:19	Anduck:	Anduck is now known as NyanDuck
09:50:55	NyanDuck:	NyanDuck is now known as Anduck
11:01:01	michagogo|cloud:	08:52:42 gmaxwell: this is not unlike the dnssec signing party <-- If this is what I think it is, I read about it at one point, and saw some short clip about it, but I wasn't able to actually find the videos of the ceremony... Do you know if they're publicly available somewhere?
11:06:07	petertodd:	michagogo|cloud: tens of gigabytes worth are available... http://data.iana.org/ksk-ceremony/
11:06:32	michagogo|cloud:	petertodd: Ah, that would be exactly what I was wondering about
11:06:41	michagogo|cloud:	I tried to find that and was unsuccessful :-/
14:51:52	gavinandresen:	gavinandresen has left #bitcoin-wizards
16:15:44	amiller:	how else can i estimate the amount of money spent on mining hardware so far?
16:15:46	amiller:	i feel like we talked about this once recently but i grepped my logs and can't find anything
16:15:48	amiller:	i estimated that it's at least $80 million but that's a ridiculous lower bound based on multiplying the current hash rate by the most *hash/sec/dollar* efficient mining hardware, and clearly people have spent a lot of money on less efficient mining hardware too
16:15:52	amiller:	iirc someone said there was a single order to butterfly or avalon in excess of that
16:17:17	helo:	do you want to include money spent on hardware that never delivered, or significantly underdelivered?
17:00:02	maaku:	maaku is now known as Guest60548
17:12:29	amiller:	delivered i guess :p
17:14:29	Guest60548:	Guest60548 is now known as maaku
17:15:25	maaku:	iddo: no I don't have a link although you could find it in the logs with keywords like "double spend hash tree proof"
17:15:37	maaku:	but it is a very straightforward application of hash trees to double-spend dbs
17:16:42	maaku:	the holder of the serial number keeps a view of the tree which is necessary to reveal their serial number, and updates it as necessary (from watching spends)
17:21:13	maaku:	validators only need to keep the root hash, and spends -- once revealed -- can be serialized in any order because miners have sufficient information to rewrite them
17:22:33	gmaxwell:	The downside of all that is that spends take quite a bit more bandwidth, since they have to carry the proofs to update the tree. The proofs have log scale, but they still end up being pretty large compared to a transaction.
19:17:24	maaku:	maaku is now known as Guest8195
19:17:53	Guest8195:	Guest8195 is now known as maaku
19:20:25	maaku:	btw are many wizards making it to the amsterdam conference?
19:20:32	maaku:	should we arrange a wizards meetup?
19:53:57	jaekwon:	i have a fixed version of the PoS algorithm that requires no mining.
19:54:15	jaekwon:	if you're interested, come join #tendermint
20:08:53	maaku:	maaku is now known as Guest26582
20:36:07	marshall_:	marshall_ is now known as Guest13146
20:56:39	Emcy:	would PoS schemes actually be viable if done as a sidechain?
20:57:15	jaekwon:	as opposed to not being viable without a PoW mainchain?
20:58:01	Emcy:	i understand PoS is silly because you cant magic a pos coin into existence thats already worth a lot
21:00:26	jaekwon:	think about corporate stocks. intiially the stocks are cheap, and you can buy the whole lot for the company at $1000.
21:00:53	jaekwon:	but yet it's able to grow in value to valuations ten times larger than that of Bitcoin.
21:01:37	Emcy:	see that line of thinking just has scam all over it
21:01:49	Emcy:	its always killed altcoins in the crib
21:04:26	jaekwon:	even some companies are actually scams. penny stocks.
21:04:35	jaekwon:	depends on who's running it.
21:13:05	Emcy:	there are not many altcoins that are atright up
21:13:56	Emcy:	the perfectly innocent get in on the ground floor thing is probably something that can be tried exactly once, and it was bitcoin
21:15:33	maaku:	maaku is now known as Guest20317
21:18:18	azariah4_:	once for each major paradigm
21:19:50	Guest20317:	Guest20317 is now known as maaku
21:51:05	jaekwon:	Emcy: perhaps. or, perhaps Bitcoin will fail due to its shortcomings.
21:53:08	Emcy:	bitcoin failing has no bearing on whether a cryptocoin can be bootstrapped the right way ever again
21:55:45	maaku:	jaekwon: I'm not sure what you mean by "bitcoin will fail" -- even if an entirely different digital currency protocol is developed and used, the bitcoin scarcity distribution can be ported over
21:56:30	maaku:	there is no reason for an alt to use the same economic model (unperishable fixed monetary base) with a separate scarcity base.
21:56:43	maaku:	i'll go out on a safe, sturdy limb and say that will never, ever take off
22:01:52	jaekwon:	emcy: i see your point. do you see any other ways that haven't been tried yet?
22:02:48	Emcy:	if i could id be scammin rubes
22:03:13	jaekwon:	emcy: hah. yeah, it's like that out there.
22:03:39	Emcy:	i sort of hope sidechains might clean up the altcoin scene somewhat
22:03:50	jaekwon:	emcy: but if the protocol actually provides tangible value besides just being a coin, then it might work.
22:04:05	Emcy:	since there will be bitcoins in play essentailly, not monopoly coins
22:12:17	maaku:	maaku is now known as Guest51417
22:21:25	Guest51417:	Guest51417 is now known as maaku
22:21:54	maaku:	maaku is now known as Guest35328
22:22:56	Guest35328:	jaekwon: there are three separable roles for a currency: store of value, medium of exchange, and unit of account
22:23:05	Guest35328:	bitcoin is an excellent store of value, freicoin is one kind of ideal medium of exchange currency
22:26:28	Guest35328:	asset issuance with trustless exchanges gets us the third: basket currencies or synthetic index tracking assets for unit of account
23:45:25	nshlike:	anyone know some good resources for ECDSA, and the implications of point addition/multiplication in regards to security? Trying to get my head around some of the math in BIP32/Stealth addresses
23:45:40	nshlike:	( #bitcoin-dev )