00:07:10gnrldsray:Thanks shesek
00:50:42tacotime:hey iddo.
01:13:36Emcy:jgarzik is there anything particularly different about the latest boostrap.dat?
01:14:17Emcy:byte offset or anything
01:55:16gnrldsray:gnrldsray is now known as Ursium
03:20:14jgarzik:Emcy, shouldn't be
03:20:34jgarzik:Emcy, the file format receives appended data, leaving the leading 70% untouched
03:21:21jgarzik:shesek, I think Vitalik is getting some funding, though he does seem the chief designer
03:22:56Ursium:jgarzik: he's defo working with Charles Hoskinson
03:23:08Ursium:he mentioned 5 team members on reddit
03:23:31Ursium:and fundraiser is 26th Jan, ann at the bitcoin miami conference
03:23:46jgarzik:CH not my favorite person in the world
03:23:58jgarzik:* jgarzik will be in Miami
03:24:29Ursium:well that's just my view, based on the white paper and some references charles made on the forums.
03:25:06Ursium:what do you think of the idea though - turing complete , GHOST , etc?
03:27:10Emcy:jgarzik strange, my client seemed to have a problem seeing the previous torrent once the new one had finished
03:28:02Emcy:rechecking it have 56% or something, and then rechecking the 13gb one gave incomplete even though the filesize was 13gb.
03:28:35Emcy:perhaps ill just seed the most recent and be done with it
03:28:54jgarzik:Emcy, yes, that's what you should do. Seeding an old torrent is entirely pointless.
03:29:16Emcy:well, there were still a lot of peers on it
03:29:36Emcy:still uploading well. Good 200 on the new torrent already though so
03:30:23Emcy:I tend to drop a note in the comments about a new torrent for whom it may concern, since thats something people with linux clients cant do
03:31:38Luke-Jr:fwiw, Vitalik recently told me there are 10-20 people now
03:32:37Luke-Jr:Emcy: more like something BitTorrent doesn't support <.<
03:33:43Emcy:youre right the comments and rating system is utorrent specific
03:33:56Emcy:btdigg picks up on it though, which is nice
03:34:02Emcy:they should standardise it
04:01:32gmaxwell:Yea, I didn't respond to their inquiries because it was CH.
04:25:42tacotime_:There are at least 3-4 people hacking the github repository for ethereum right now
04:26:33tacotime_:Doing turing complete (basically turning the transactions into executable code) is both neat and kind of scary at the same time
04:31:07tacotime_:I'm debating whether or not I should go to miami or wait for the texas conference
05:35:36Luke-Jr:my wife and I will probably both be in Miami
06:08:00wyager:wyager has left #bitcoin-wizards
06:23:16amiller:turing complete sucks as a catchphrase/soundbyte/feature
06:23:19amiller:it's a total red herring
06:23:38amiller:all sorts of interesting/expressive languages are not turing complete
06:24:01amiller:and even a turing complete language would be useless if it's not hooked up correctly to txouts and etc
06:24:20amiller:it's neither sufficient nor necessary for what anyone actually wants with a modified transaction script
06:24:48amiller:try to build a sponsored chess game, as a thought experiment
06:24:52amiller:or a poker game
06:24:55Luke-Jr:amiller: dunno, turing complete *might* make it possible to get at anything
06:24:56gmaxwell:well besides any computer with finite memory is not technically turing complete. :P
06:25:14amiller:you don't need turing complete for any of that, and also turing complete doesn't automatically make those work
06:25:24gmaxwell:Luke-Jr: but if the chess game program is so huge that you can't realistically use it... no real point.
06:25:33amiller:you could trivially make bitcoin-script turing complete by adding opeval or whatever, and it still wouldnt' solve that problem
06:25:42Luke-Jr:but I mean, to get at txout info, you *could* just confirm the transaction is part of a block etc
06:26:21amiller:that's pretty complicated, but i guess
06:26:22gmaxwell:sure and you could do that in script if substr and cat hadn't been disabled.. and without being turing complete.
06:27:59gmaxwell:and if you replaced script with, say, 8 bit AVR instructions you could do it as well, but the transaction would be so big as to be unusable.
06:29:49gmaxwell:though I looked at their codebase, and uh.. it's implementing basically bitcoin script— with a bignum as the basic type— with and added instruction pointer and jmp instruction. Seems like someone has never worked with forth, the result is kinda unholy looking.
10:01:52TD[gone]:TD[gone] is now known as TD
10:05:52gmaxwell:petertodd: you did realize why you can't encrypt your stealth addresses, right?
10:06:59gmaxwell:petertodd: (because if you do, then someone with the candidate stealth address can test if any stealth payment on the chain is connected to that one by decrypting the nonce and testing if its a valid point)
10:10:05gmaxwell:TD: alas for this it needs to be bitcoin compatible public key, and the elegator mapping cannot work for our curve.
10:10:15gmaxwell:(can't work for curves where the x term is 0)
10:11:11TD:you can do elligator for curve25519 however, so if we switch to supporting ed25519 signatures in future, it might become workable
10:34:40nsh:gmaxwell, is it not possible in principle to have an elligator-like mapping to uniform strings from the bitcoin curve points?
10:35:29gmaxwell:nsh: the points are enumerable so it's possible to map... an efficient one? I don't know of one for our curve.
10:35:42gmaxwell:There are other ways to make bitcoin points statistically uniform.
10:36:34gmaxwell:E.g. take your point and randomly choose a x value between it and the prior valid point... then have the reciver do the reverse process... its just a little computationally expensive.
10:36:39nsh:do curve25519/ed25519 have extra structure that facilitates efficient mapping?
10:37:44TD:every value is a valid point, or something like that
10:39:16nsh:* nsh rereads petertodd's proposal thread
10:39:19gmaxwell:well the elegator mapping achieves that. Raw curve25519 x values are only about half valid like ours. The elegator mapping isn't totally trivial either, but its not as slow as "test points until you get a valid one"
10:40:16gmaxwell:(also the elegator mapping doesn't work for all points, just a really large number of them, so you have to generate ed25519 points with that in mind if you're going to use it, which is a little annoying)
10:40:47TD:i think it's spelled "elligator"
10:40:56TD:i remember this, because i know a cryptographer called elli
10:41:01nsh:50% of ed25519 points don't have elligator mappings iirc
10:57:10gmaxwell:7. The use of Bitcoin will evolve beyond ‘store of value’ or ‘transactions’
10:57:13gmaxwell:The underlying Bitcoin protocol makes itself applicable beyond the use cases of ‘store of value’ and ‘payments’. The Bitcoin foundation took a huge step in allowing meta data to be included in the blockchain.
10:57:48sipa:note that they at least say "meta data" and not "data"
10:58:34gmaxwell:Fair. hah. they link to https://www.secondmarket.com/education/landing/bitcoin-ecosystem ... someone should make a version of that without survivorship bias that includes all the companies that vanished with everyone's money. :P
10:59:51Ursium:Morning! (if you're in the UK and went to be late like me :)) - What do you guys think of Ethereum?
11:14:03Ursium:Ursium is now known as Ursium_
12:24:01Ursium_:Ursium_ is now known as Ursium
13:23:37justanotheruser:What do you guys think of ethereum?
13:40:21tacotime_:This question again haha
13:41:07tacotime_:Usually it boils down to "is including executable code in txs a good idea", but there are interesting things about it, it's moving quickly, and it looks to be very well funded.
15:20:35Ursium:tacotime_: but the fundraiser hasn't taken place yet
15:20:48Ursium:oh do you mean 'it will be well funded' ok .
15:21:33tacotime_:Ursium: There are 3+ devs hacking it right now, they have to be getting money to eat from somewhere I'd guess. Plus the folks behind mastercoin seem to be involved.
15:22:51Ursium:tacotime_: source on the master coin link? (not questionning it's true, just curious as i'm following this very closely). As for money to eat vitalik is part of kryptokit and I don't believe he works for free :)
15:42:27petertodd:gmaxwell: ?
15:42:41petertodd:gmaxwell: what do you mean by "decrypting the nonce"?
16:34:45gmaxwell:petertodd: you suggested in your message that the nonce could be encrypted with H(stealth address)
17:11:37petertodd:gmaxwell: oh that, yeah, of course they can do that. The encryption only helps against someone who doesn't know the stealth address - that's why I said it's a minor protection
17:12:13petertodd:gmaxwell: The point of doing so is only as a incremental improvement so that all OP_RETURN uses looks semi-similar.
17:13:22petertodd:gmaxwell: oh, wait, I get your point... yeah, that's a problem
17:13:58petertodd:gmaxwell: right, and your thinking re: other ECC styles is just so that the decryption with an incorrect key should always lead to a valid - if not correct - pubkey
17:25:28adam3us:gmaxwell, petertodd: but wait u are saying c=H(eP)=H(dQ) and what encrypt r=R.x? so r'=E_c(r) so that there is no key recovery on the signure. hmm i am confused what are you encrypting and why?
17:28:01adam3us:gmaxwell, petertodd: or are u talking about this two point version with two inputs, Q=dG and Q2=d2G where Q2 is used only for screenin by an untrusted party and presumably the thing is a scripthash sig so the screener cant spend?
17:29:01adam3us:gmaxwell: i mean in principle if u dont know the key, you learn nothing other than you dont have the key whether the resulting point is on the curve or not?
17:29:33gmaxwell:adam3us: go see petertodd's stealth address post in bitcoin-dev
17:29:50adam3us:gmaxwell: yes i read that at the time.
17:30:42gmaxwell:He proposed, in passing, to encrypt the nonce used in the transaction with e.g. H(stealth address). This is bad because if you have a large list of stealth addresses you can test transactions to see if they might be related to one stealth address or another.
17:33:59adam3us:gmaxwell: ok so nonce is the wrong term i guess; he said "payor generates nonce keypair P=eG" less confusing to call that an emphemeral keypair. the only nonce in DSA could arguably be k.
17:39:01petertodd:adam3us: basically something like 1 in 256 arbitrary 33 byte strings are valid ECC pubkeys, so decrypting and checking gives you a lot of statistical info that it shouldn't
17:39:57adam3us:petertodd: i did not find the encrypt with H(addr) so I dont know what you are encrypting yet, but if you are encrypting with something unknown to the attacker i do not see the attack
17:40:20petertodd:adam3us: well the stealth address is known to our attacker in my attack model
17:41:12adam3us:petertodd: doesnot the stealth address S=dP=eQ ie unknowable if u do not know d or e
17:42:19petertodd:adam3us: we're talking about the sender emphemerial pubkey, the one that goes into a OP_RETURN txout, I suggested encrypting that data so that it wasn't obvious if the transaction was or was not a stealth tx
17:42:54petertodd:adam3us: gmaxwell's point is that the encryption leaks info because you can trial decrypt, and if the result is a valid pubkey, you know you have a high probability of having guessed the right stealth addr
17:42:57adam3us:petertodd: ok as far as that goes i why dont you use one of the input addresses as the emphemeral pub key
17:43:35petertodd:adam3us: because that leaks info to the receiver about which txin did the money come from, and also makes assumptions about how you fund the tx
17:43:58adam3us:petertodd: still if its proper encryption with a key unknown to the attacker you can trial decrypt until the heat death of the universe ;) and only explore which are on the curve and not, which has a known probability distribution... and so what?
17:44:31petertodd:adam3us: the thing is in this case the attacker *does* know the key, only the weaker attacker doesn't
17:44:46petertodd:adam3us: the weak attacker is worse off, but the not so weak attacker is much better off - bad tradeoff
17:45:19adam3us:petertodd: how did u arrive at a threat model where the attacker knows your decryption key?
17:45:38petertodd:adam3us: because it's in the stealth address itself
17:52:48adam3us:petertodd: so you are talking about encrypting P the ephemeral pub key, using the hash of the stealth pub key S (presumably a diff hash than the one used to compute the stealth address as that is also public). now S=dQ and Q is the recipients static receive addess. and S=eP, and P=dG d is nly known to the sender. But e is known to the recipient Q=eG. so the recipient has a catch 22 he doesnt known d so he cant compute S=dQ, and he knows
17:52:58adam3us:petertodd: seems stuck in circular dependency
17:54:47petertodd:adam3us: the point is to hide the transaction from weaker attackers who *don't* know the stealth address, which is a valuable thing. but it's not worth it if it makes it easier for attackers who do know; there's no circular dependency there
17:55:09petertodd:adam3us: read my post again and you'll see what I mean
17:55:37adam3us:petertodd: the original post or one of the 5 followup posts? (i didnt find it yet)
17:55:52petertodd:adam3us: my original
18:01:13adam3us:petertodd: ah ok so u want to encrypt it with H(Q) not H(S). gmaxwell had said "you suggested in your message that the nonce could be encrypted with H(stealth address)" ok so the stealth address is Q, not S, and actually I see you changed to Q' in the write up over previous IRC here. fine. yes gmaxwell is right.
18:02:08adam3us:petertodd: but why do you want to encrypt ephemeral pub key P at all? to obfuscate that ths is a stealth payment? who else makes 0 value payments to invalid addresses?
18:05:43adam3us:petertodd: "the [ephemeral] keypair [P...] is included in the transaction in an additional zero-valued output: RETURN

" what is that an ignored, UTXO compactible, 32 byte message?

18:29:59gmaxwell:adam3us: he wanted to obscure that it was a stealth payment maybe share anonymity set with a timestamping thing.
18:30:06gmaxwell:But no joy.
18:30:53adam3us:gmaxwell: ok hence the elligator thread.
18:32:43adam3us:gmaxwell: it a classic steganography requirement. all decryptions must be equally plausible. alternatively he could send P+Q and hash2curve his timestamp hashes :)
19:01:10nsh:* nsh looks at this twister.net.co thing
19:13:17TD:TD is now known as TD[gone]
19:33:36nsh:libboost-dev is 60Mb....
19:33:58nsh:(with all the attendant repocruft)
19:36:44nsh:wait, another 139Mb for libboost-all-dev
19:46:55CodeShark:CodeShark is now known as CodeShark_
20:56:17CodeShark_:CodeShark_ is now known as CodeShark
22:40:56gmaxwell:https://soundcloud.com/rdlmitedu/140113_0001-wav Matt Green presents Zerocoin/Zerocash at Real World Crypto 2014
22:45:55Luke-Jr:gmaxwell: is it practical now?
22:46:13petertodd:gmaxwell: they released a paper yet?
22:46:30jron:petertodd, no paper yet afaik.
22:47:14nsh:has anyone looked at how twister is using the blockchain/PoW and to what degree it's sane/scalable?
22:47:45petertodd:nsh: it's aweful, for instance there is a per-tx PoW, yet the difficulty for that PoW is hard-coded
22:48:22nsh:it is viable in principle though?
22:48:38maaku:gmaxwell: anything new presented at that talk?
22:48:39nsh:seems to be very early alpha, so maybe all kinds of silly parametric decisions/hacks
22:48:43petertodd:nsh: no, there's no incentive built into the system other than the ability to spam other users with messages... and no way to guarantee the messages will be shown in the UI
22:49:03gmaxwell:maaku: I haven't listened to it yet, I peppered jron with some questions.
22:49:14petertodd:jron: pity
22:49:33jron:Luke-Jr, it sounds like the only thing they add to the blockchain is 288 bytes
22:49:35petertodd:nsh: it should have used an existing name thing like namecoin
22:49:48nsh:* nsh nods
22:50:16petertodd:jron: small enough it doesn't need to be a separate chain, although my understanding is they're making it one
22:50:31jron:petertodd, correct. they are calling it "zerocash"
22:50:34gmaxwell:jron: Oh, I'm pretty sure its a bit more complex than that. At a minimum it should be their proofs plus one or two additional hash trees.
22:50:50petertodd:jron: and totally separate PoW right?
22:50:56gmaxwell:jron: Did they say anything about recovering space from old completed transactions? (e.g. analogous to pruning in bitcoin)
22:51:10jron:petertodd, there was no mention of their PoW function.
22:51:35gmaxwell:I had a couple ideas for how to achieve pruning in a zerocash like system but they all were kinda ugly and had tradeoffs I didn't like.
22:52:04petertodd:jron: heh, hopefully they'll take my advice from last summer and do a proof-of-sacrifice or bitcoin timestamped+pos for proof-of-publication
22:52:07jron:gmaxwell, there was no talk of pruning that I heard.
22:52:14gmaxwell:jron: :(
22:52:47jron:petertodd, I assume proof of sacrifice is destroying btc?
22:52:53petertodd:jron: yup
22:53:01jron:I was thinking about that on the drive home.
22:54:17petertodd:jron: basically you need to be able to securely order the transactions to solve double-spending, which is easy, and also come to consensus about what chain has the most "users" in a sense. pow is a really simple way to do both, but is vulnerable to attack.
22:54:17nsh:that soundcloud recording is 600% reverberation by weight
22:54:30petertodd:nsh: I hear it was held in a big church :/
22:54:44gmaxwell:jron: can you go compare zerocash with zerocoin for the channel? (I know some things from private conversations that I haven't told people here which were probably disclosed in the talk, but it'll take a couple hours before I can listen)
22:58:06Luke-Jr:anyone have any legal contacts with Google?
22:58:23maaku:Luke-Jr: as in with Google's lawyers?
22:58:37Luke-Jr:maaku: yes, or anyone who can help me get Nest thermostats GPL compliant :p
22:59:14jron:I need to relisten but it sounds like they ripped out a lot of the code from libzerocoin. They also cut the proof size down from about 4KB to 288 bytes and the verification time down milliseconds.
22:59:27maaku:holy cow, $3.2 billion for a thermostat?
22:59:42Luke-Jr:maaku: it's a smartphone inside
23:00:00Luke-Jr:and right now it gives the company complete control over your home temperatrue :/
23:00:44jron:the trade of for the verification time is it takes about 2 minutes to perform a transaction in addition to the confirmation time.
23:01:03petertodd:jron: 2 min on what kind of machine?
23:01:28jron:petertodd, single core current gen
23:01:41petertodd:jron: not bad, is the computation parallelizable?
23:02:02jron:petertodd, he didn't say. I assumed it was but that is a great question.
23:02:06maaku:Luke-Jr: most effective, but asshole method for compliance is to get a blog post calling them out on the front page of HN
23:02:25maaku:it'll be fixed within hours
23:03:00petertodd:jron: if the computation can be outsourced in any way would be really interesting too
23:03:02jron:he also mentioned a large blog that is required to spend coins. the size is about 1.2 GB.
23:03:10maaku:jron: 2 minutes to *verify* a transaction, not sign?
23:03:16jron:large blob*
23:03:32petertodd:jron: is the 1.2GB akin to a private key, or some shared data structure everyone just needs?
23:03:40maaku:ok n/m reading fail
23:03:44jron:maaku, verification is sub second.
23:03:45gmaxwell:jron: sounds like he actually didn't give a lot of technical details.
23:04:04jron:gmaxwell, it was a basic overview.
23:04:06Luke-Jr:maaku: HN?
23:04:06gmaxwell:This is annoying, because I actually can answer all of these questions.
23:04:59michagogo|cloud:Luke-Jr: Hacker News
23:05:53michagogo|cloud:Luke-Jr: So I'm guessing you already saw https://nest.com/legal/compliance/ and it's incomplete?
23:05:58gmaxwell:well, in any case, I don't think I'm giving anything away that I hadn't guessed at before I'd talked to them. They're using a ZK-SNARK based on the GGPR 2012 paper, this is the CRS-assumption pairing crypto knoweldge of exponent assumption for quadratic arithemetic programs stuff that is used in pinocchio and the tinyram papers.
23:06:32jron:petertodd, he descibes the 1.2 GB dataset as a large set of public params required to spend coins.
23:06:57gmaxwell:The proving side of this system is pretty highly paralizable. I don't know the size of the proving key, since it's polylogarithmic in the size of the circuit being proved.
23:07:00Luke-Jr:michagogo|cloud: it's missing build/install stuff
23:07:35gmaxwell:The verification key and proof sizes are just dependant on security, and you can see figures on them in the vntinyram paper: http://eprint.iacr.org/2013/507
23:08:34gmaxwell:But presumably they wouldn't use tinyram for this, they don't need turing complete to prove some anonymous transactions. Instead I expect them to prove hashfunctions and equality, and so a custom circut could be a lot smaller.
23:09:40gmaxwell:(a straighforward implementation of SHA256 has 30k AND gates— but most (90%?) of these are in 32 bit adders, and a 32 bit adder in a QAP takes just a couple gates instead of 65 in a boolean circuit)
23:10:42jron:they did mention the use of SHA256 and SNARK to achieve the proof size
23:12:37maaku:jron: did they go into any detail about how the public params were derived?
23:13:21jron: he did mention two possible options. the first was finding as many willing and "trusted" participants to create it in a semi-distributed fashion.
23:13:21jron: the second was writing software to do it p2p but he didn't go into specifics on how that could be pulled off.
23:14:11gmaxwell:^ that was from when I asked in #zerocoin
23:15:02gmaxwell:So yea, the problem with the GGPR ZK-SNARK is that there is a set of asymetric encryption keys and if _anyone_ knows them or finds them, then that party can trivially make false proofs.
23:16:11Alanius:I think I know what I'm reading tomorrow :-)
23:16:19Luke-Jr:gmaxwell: does someone *need* to know the private key?
23:16:31maaku:Luke-Jr: you need the private key to create the public params
23:16:38Luke-Jr:else, have lots of N people pick entropy to produce a public key for which there is no known private <.<
23:16:41maaku:so you need to trust that someone diddn't keep a record
23:16:45gmaxwell:it has to be known temporarily to generate the public keys. At least unless you invoke some multiparty computation unicorn.
23:16:49maaku:or MPC
23:16:58Luke-Jr:so the public key can't be generated without the private key? :<
23:17:01nsh:someone needs to be trusted to forget something...
23:17:15Luke-Jr:Bernanke can do it!
23:17:18gmaxwell:At which point we're starting to recursively nest unicorns, since most efficient MPC stuff being written about works by using ZK-SNARKS to prove the players aren't cheating.
23:17:34gmaxwell:Basically the whole GGPR scheme works by reducing proving the correctness of program execution to proving you know the roots of some polynomials meeting some constraints.
23:18:37gmaxwell:What happens is that you find these polynomials and then encrypt them with the public keys produced in a prior initilization phase, and then also encrypt your roots.. And the cryptosystem has the right kind of homorphism that the encrypted roots are still roots of the encrypted polynomial.
23:18:39petertodd:gmaxwell: pity, although I'll bet you the average person won't blink an eye at the "founders could fuck it all up" problem
23:18:54maaku:gmaxwell: wait, it's a valid question - is there some way you can just use random junk for the public portion, like say the first sequence of PI bits which satisfies whatever constraint is necessary?
23:19:00gmaxwell:maaku: no.
23:19:18maaku:k, fair enough :)
23:19:39gmaxwell:Since you have no freeking clue what points the polynomial is being evaluated at, you can't generate a fake polynomial that will pass the test. but if you have the secret data you know the points and its trivial to generate a fake proof.
23:19:39maaku:* maaku demonstrates is ignorance of pairing crypto
23:20:22gmaxwell:maaku: basically you can pick random keys, but they won't agree with each other, since you need to both encrypt your roots and the polynomial in such a way as the result can still be tested.
23:22:23petertodd:jtimon: pragmatic, but computational crypto-coins are admittedly a lot more interesting solution to that problem
23:22:46gmaxwell:in any case, I'd really suggest sitting down and reading the vntinyram paper, — skipping over the mathy parts as you see fit.
23:23:04gmaxwell:Because the scipr-lab.org people have a public maining list, and I have an existance proof now that they respond on it. :)
23:23:11gmaxwell:(linked here: http://www.scipr-lab.org/ )
23:23:30jtimon:petertodd: I don't think I understand you
23:23:48gmaxwell:while they probably don't know anything about zerocash, they do know the backend cryptosystem.
23:24:53jtimon:petertodd: what problem you mean exactly?
23:25:37jtimon:petertodd: and what do you mean by "computatuional crypto-coins"?
23:26:50gmaxwell:Oh I linked the wrong paper earler, the vnTinyRam paper is http://eprint.iacr.org/2013/879 and it has all the benchmark figured (and I strongly believe that the verfier numbers will apply to any zerocash proposal)
23:27:43petertodd:jtimon: basically, people have proposed much more sophisticated scripting languages, to the extent that the txin scriptPubKey could constrain txout scriptPubKey's, meaning that a txout with a scriptPubKey of a specific form would be proof that the txin scriptPubKey also had the correct form all the way back to some genesis txout, thus, colored coins
23:28:34jron:someone posted some of the key points from the zerocash presentation here: http://pastebin.com/Dd60ZaT7
23:28:54gmaxwell:petertodd: Zero knoweldge computational crypto coins are even better for that.
23:29:32petertodd:gmaxwell: of course, after all, you write about coin covenents on trolltalk
23:29:44petertodd:gmaxwell: s/write/wrote/
23:30:08gmaxwell:jron: thanks!
23:30:09petertodd:gmaxwell: directly interpreted consensus systems can be upgraded to ZK systems after the fact
23:31:47gmaxwell:Yea, okay, so they point out there that the ZK based construction allows them to encrypt values to.
23:32:19gmaxwell:This is really important because it means that the anonymity set size is all transactions, not just all transactions with plausable values for you.
23:32:26gmaxwell:But it has some crazy consequences.
23:32:38gmaxwell:Like there becomes no way to even roughly gauge the size of the economy anymore.
23:33:20gmaxwell:It also interacts very poorly with the security assumptions... In zerocoin someone who compromised the magical RSA number could drain out an accumulator and steal all the coins in it. Which is bad but:
23:33:48jtimon:petertodd: I'm not sure I understand your claim yet thought, you're just saying that you prefer other colored coins schemes over this one https://bitcointalk.org/index.php?topic=253385.0?
23:34:01gmaxwell:In a system with hidden values under ZK proof a CRS compromise gives unbounded undetectable(*) inflation.
23:34:17Alanius:you could estimate roughly the size of the economy by monitoring the transaction fees
23:34:23petertodd:jtimon: no, I'm saying I prefer schemes that allow for totally generic colored coins, or anything else you might want to do
23:34:24gmaxwell:(*) well, I suppose once you personally end up with more coins in your wallet than should exist you will then believe there has been a cryptosystem compromise.
23:34:44jron:gmaxwell, hah!
23:34:53maaku:Alanius: txn fees have nothing to do with txn values..
23:34:57gmaxwell:Alanius: perhaps! but you couldn't tell if a transaction was for 1 coin or 100000 coins.
23:35:15maaku:petertodd: what does "totally generic" mean?
23:35:28Alanius:sure, but it would be pretty stupid to fee 10 coins for 1 coin's worth of actual transfer
23:35:47Alanius:hence, "roughly" :)
23:35:53maaku:it'd be a lower bound ... but probably a very low lower bound
23:35:56gmaxwell:Alanius: normally in bitcoin like systems the fees are just proportional to the data size of a transaction, since that reflects the networks actual processing cost.
23:36:04maaku:but i think you understand that :)
23:36:17gmaxwell:maaku: you could force fees to be related to value.. I suppose, though that would be an information leak, plus it would be u. You can't have it both ways, I think. :P
23:36:44sipa:Alanius: when fees are free-floating and there's an actual market around, i suppose to some extent
23:36:47petertodd:maaku: if a scriptPubKey can restrict redemption to transactions with txouts with scriptPubKeys of forms that propagate those convenants, then you can create generic limitations on how the coins can be spent
23:37:39gmaxwell:heck you could even force a kind of value information leak from transactions. E.g. force under the zk proof for you to generate a randomly fuzzed version of your txn value which you make public. And then people could gauge the average economy size without any specific transaction giving away its size... but its not clear to me if being able to size up the economy from the blockchain is actually an important enough property, kinda ...
23:37:45gmaxwell:... weird that you couldn't though!
23:38:04petertodd:maaku: for instance a really extreme example is to create a consensus system with no concept of coins at all, that does nothing more than map H(program)->Eval(program), if the program can access blockchain data as part of it's execution, the program itself can implement a bitcoin-like currency!
23:38:33petertodd:maaku: (sorry, that's commit to (H(program), input arguments)->Eval() to be exact)
23:38:49gmaxwell:"best part of this is that you already need 16GB to store the blockchain," ... ::sigh:: this isn't true, and it's also why I was asking about pruning in zero cash. Seems that they don't realize you can prune simply because the reference software doesnt'.
23:39:09petertodd:gmaxwell: or worse, have their marketing hats on...
23:39:09gmaxwell:I don't see any easy and catch free way to get pruning into an anonymous coin though.
23:39:20gmaxwell:petertodd: nah I just don't think they know a lot of people don't.
23:39:44petertodd:gmaxwell: ugh, pruning is in the satoshi whitepaper...
23:40:04gmaxwell:you think they really read it?
23:40:07petertodd:gmaxwell: the interesting part isn't that you can do pruning, but the extent to which the fact that you can is a bad thing
23:41:03gmaxwell:in any case, for these anonymous coin ideas what you end up having to have is a database of encrypted coins which have been created, and another database of non-encrypted coins that have been spent.
23:42:21maaku:petertodd: ok, i understand the feature request now. do you know a way in which this might be implemented?
23:42:22gmaxwell:The ZK proof when you spend is of a statement like "This decrypted coin exists in encrypted form in the encrypted coin database". And then the newly decrypted coin is added to the database of spent coins.
23:42:55petertodd:gmaxwell: though the database can be split up; you can think of both databases as cryptographic accumulators supporting VerExists() and conversely VerNoExist(), and thus get succinct proofs of either for SPV.
23:43:02gmaxwell:so you can't prune the encrypted coin database because you can't tell which entries have been spent. And you can't prune the spent coins database because then the coins could just be respent.
23:43:52gmaxwell:The coins database can be append only, but the spent coins database needs an efficient VerNoExist() so it must be key ordered.
23:44:14gmaxwell:key ordered makes it hard to outsource efficiently. (requires tracking the network)
23:44:15maaku:petertodd: if script was homoiconic it would be easier to attach a script which takes the transaction as input and outputs scripts to be attached to the outputs
23:44:28maaku:and those could be carried forward
23:44:33petertodd:maaku: well, in Bitcoin you need a very invasive soft-fork. vitalik's ethereum is in those directions, but the implementation is yuck
23:44:34Alanius:couldn't one store the spent coins in a merkle mountain range? Or am I mixing things up here?
23:45:03petertodd:gmaxwell: right, with spent that's the same problem as UTXO proofs. although you can design it so that the spent database need not be held in entirely for any one miner
23:45:04maaku:Alanius: "the spent coins database needs an efficient VerNoExist() so it must be key ordered"
23:45:24Alanius:ah, mmr'
23:45:31Alanius:s do not allow proof of non-existence?
23:45:33petertodd:Alanius: MMR can be used for unspent only, and I'm going to be very interested to find out if that's what they did
23:46:02petertodd:Alanius: they do, but the proof-of-non-existance is O(m log n) in size for a span of m blocks
23:46:25petertodd:Alanius: which you can do in zk-snark fashion, but that's costly
23:46:40maaku:petertodd: i think that's misleading from the context of his question
23:46:51maaku:Alanius: you can only prove non-existence based on what is being indexed
23:47:04maaku:MMR is indexed based on insertion order
23:47:24maaku:so you can prove, for example, that no coin was spent in between two adjacently spent coins
23:47:27jtimon:petertodd: I like a generic scheme too, I'm just not contrained to softforks, seriously I don't know what your claim is yet what solution and what problem are you referring to from my link?
23:47:29maaku:which is pretty useless
23:48:07Alanius:maaku: thanks! very intuitive explanation :)
23:48:22maaku:jtimon: he wants to attach arbitrary validation rules to outputs, and have those propogate in arbitrary ways in future transactions
23:48:28petertodd:maaku: but that's the thing, it's *not* useless, if you can prove when the coin was created, you naturally have a reasonable limit on the non-existance proof, which is a way that you could get something akin to pruning in zerocoin
23:48:58petertodd:maaku: basically the cost to make the zk-proof would increase as the coin gets older, but my understanding is that cost blows up very fast with current zk-snark technology
23:49:04gmaxwell:yea, so my thought for pruning is that when you create a coin you could created it with a generation number (which is made public by the ZK proof)
23:49:33gmaxwell:where 'generation number' means like "what month was it created in"
23:49:59petertodd:gmaxwell: yup
23:50:03gmaxwell:and then you can say that coins become unspendable after so many months, allowing you to prune both data sets.
23:50:08gmaxwell:But its kinda ugly.
23:50:16Alanius:that would partition the anonymity set
23:50:24gmaxwell:as it reduces your anonymity set and makes your coins expire.. and we can't even tell how many coins have expired!
23:50:39petertodd:gmaxwell: but why make them unspendable? just force you to prove correct manipulation of the spent set in your tx
23:51:23gmaxwell:petertodd: hm. and store the new spent set root? so you never close off an old spent set, it just becomes more espensive to spend from it?
23:51:31gmaxwell:I suppose thats true.
23:51:47petertodd:gmaxwell: well, doesn't even have to be more expensive, just more annoying
23:52:06gmaxwell:You still have the anonymity set reduction though, alas.
23:52:15petertodd:gmaxwell: basically if you're spent token set is a single radix tree, then you have a bunch of data that needs accessibility, to do better, shard that
23:52:47petertodd:gmaxwell: sure, but it's still easily inline with what coinjoin can do (anonymity set of tx's happening at roughly the same time)
23:53:12gmaxwell:oh it's much better since same time could be defined to be a month or more.
23:53:36gmaxwell:it's still not free however.
23:53:40petertodd:and you want some amount of time anyway, as mining needs to imply at least having the data, so you want mining to be tied to, say, the last month of data
23:53:46gmaxwell:also there are some other tradeoffs which come into play.
23:54:16gmaxwell:The ZK proofs are going to be most efficient if they have no branching, just a constant number of hash evaluations and some muxes to get data on the right side of the hash input.
23:54:57gmaxwell:One of the plus sides of pruning is that it should make the ZK proofs faster.
23:54:57petertodd:gmaxwell: so make a tree of every month from now until eternity
23:55:14petertodd:ok, sure
23:55:24gmaxwell:"once we have these coins we put in the hash tree; 64-depth key (2^64); when want to redeem; reveal the serial number, and can reveal 64-hashes before in the tree; "
23:55:31gmaxwell:(quoting from the talk)
23:55:47gmaxwell:sounds like they fixed the tree size at 64 deep so that they'd 'never' run out of room.
23:55:54petertodd:(note how they must have some mechanism to make collisions hard...)
23:56:27gmaxwell:With pruning we can do better and say, have a 2^33 deep tree. Which is fine for a months of transactions.
23:56:29petertodd:(oh, actually, no that's not true, you don't need that)
23:56:50petertodd:true, although the risk of accidentally picking someone elses serial number goes up
23:57:25gmaxwell:petertodd: no need to have a risk of that, you just use a >128 bit random serial number.
23:57:32gmaxwell:one turn of the compression function takes 512 bits.
23:58:02gmaxwell:In there you have to fit the value of the coin, a P2SH hash for the pubkey needed to spend it, and a serial number.
23:58:17petertodd:gmaxwell: wait, so how does that help? the tree is indexed right, so if the first 33 bits match I have a problem
23:58:20jtimon:for scalable "anonymous" transactions, more than zerocoin-like stuff I like petertodd's inputs only approach with an expiry on the UTXI entries
23:58:50gmaxwell:petertodd: no no, it's insertion ordered.
23:59:06petertodd:gmaxwell: oh right, doh
23:59:10petertodd:gmaxwell: quite correct