| 00:07:10 | gnrldsray: | Thanks shesek |
| 00:50:42 | tacotime: | hey iddo. |
| 01:13:36 | Emcy: | jgarzik is there anything particularly different about the latest boostrap.dat? |
| 01:14:17 | Emcy: | byte offset or anything |
| 01:55:16 | gnrldsray: | gnrldsray is now known as Ursium |
| 03:20:14 | jgarzik: | Emcy, shouldn't be |
| 03:20:34 | jgarzik: | Emcy, the file format receives appended data, leaving the leading 70% untouched |
| 03:21:21 | jgarzik: | shesek, I think Vitalik is getting some funding, though he does seem the chief designer |
| 03:22:56 | Ursium: | jgarzik: he's defo working with Charles Hoskinson |
| 03:23:08 | Ursium: | he mentioned 5 team members on reddit |
| 03:23:31 | Ursium: | and fundraiser is 26th Jan, ann at the bitcoin miami conference |
| 03:23:36 | jgarzik: | ugh |
| 03:23:46 | jgarzik: | CH not my favorite person in the world |
| 03:23:58 | jgarzik: | * jgarzik will be in Miami |
| 03:24:29 | Ursium: | well that's just my view, based on the white paper and some references charles made on the forums. |
| 03:25:06 | Ursium: | what do you think of the idea though - turing complete , GHOST , etc? |
| 03:27:10 | Emcy: | jgarzik strange, my client seemed to have a problem seeing the previous torrent once the new one had finished |
| 03:28:02 | Emcy: | rechecking it have 56% or something, and then rechecking the 13gb one gave incomplete even though the filesize was 13gb. |
| 03:28:35 | Emcy: | perhaps ill just seed the most recent and be done with it |
| 03:28:54 | jgarzik: | Emcy, yes, that's what you should do. Seeding an old torrent is entirely pointless. |
| 03:29:16 | Emcy: | well, there were still a lot of peers on it |
| 03:29:36 | Emcy: | still uploading well. Good 200 on the new torrent already though so |
| 03:30:23 | Emcy: | 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:38 | Luke-Jr: | fwiw, Vitalik recently told me there are 10-20 people now |
| 03:32:37 | Luke-Jr: | Emcy: more like something BitTorrent doesn't support <.< |
| 03:33:43 | Emcy: | youre right the comments and rating system is utorrent specific |
| 03:33:56 | Emcy: | btdigg picks up on it though, which is nice |
| 03:34:02 | Emcy: | they should standardise it |
| 04:01:32 | gmaxwell: | Yea, I didn't respond to their inquiries because it was CH. |
| 04:25:42 | tacotime_: | There are at least 3-4 people hacking the github repository for ethereum right now |
| 04:26:33 | tacotime_: | Doing turing complete (basically turning the transactions into executable code) is both neat and kind of scary at the same time |
| 04:31:07 | tacotime_: | I'm debating whether or not I should go to miami or wait for the texas conference |
| 05:35:36 | Luke-Jr: | my wife and I will probably both be in Miami |
| 06:08:00 | wyager: | wyager has left #bitcoin-wizards |
| 06:23:16 | amiller: | turing complete sucks as a catchphrase/soundbyte/feature |
| 06:23:19 | amiller: | it's a total red herring |
| 06:23:38 | amiller: | all sorts of interesting/expressive languages are not turing complete |
| 06:24:01 | amiller: | and even a turing complete language would be useless if it's not hooked up correctly to txouts and etc |
| 06:24:20 | amiller: | it's neither sufficient nor necessary for what anyone actually wants with a modified transaction script |
| 06:24:48 | amiller: | try to build a sponsored chess game, as a thought experiment |
| 06:24:52 | amiller: | or a poker game |
| 06:24:55 | Luke-Jr: | amiller: dunno, turing complete *might* make it possible to get at anything |
| 06:24:56 | gmaxwell: | well besides any computer with finite memory is not technically turing complete. :P |
| 06:25:14 | amiller: | you don't need turing complete for any of that, and also turing complete doesn't automatically make those work |
| 06:25:24 | gmaxwell: | Luke-Jr: but if the chess game program is so huge that you can't realistically use it... no real point. |
| 06:25:30 | Luke-Jr: | sure |
| 06:25:33 | amiller: | you could trivially make bitcoin-script turing complete by adding opeval or whatever, and it still wouldnt' solve that problem |
| 06:25:42 | Luke-Jr: | but I mean, to get at txout info, you *could* just confirm the transaction is part of a block etc |
| 06:26:21 | amiller: | that's pretty complicated, but i guess |
| 06:26:22 | gmaxwell: | sure and you could do that in script if substr and cat hadn't been disabled.. and without being turing complete. |
| 06:27:59 | gmaxwell: | 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:49 | gmaxwell: | 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:52 | TD[gone]: | TD[gone] is now known as TD |
| 10:05:52 | gmaxwell: | petertodd: you did realize why you can't encrypt your stealth addresses, right? |
| 10:06:59 | gmaxwell: | 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:09:22 | TD: | elligator? |
| 10:10:05 | gmaxwell: | TD: alas for this it needs to be bitcoin compatible public key, and the elegator mapping cannot work for our curve. |
| 10:10:15 | gmaxwell: | (can't work for curves where the x term is 0) |
| 10:11:11 | TD: | you can do elligator for curve25519 however, so if we switch to supporting ed25519 signatures in future, it might become workable |
| 10:34:40 | nsh: | gmaxwell, is it not possible in principle to have an elligator-like mapping to uniform strings from the bitcoin curve points? |
| 10:35:29 | gmaxwell: | 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:42 | gmaxwell: | There are other ways to make bitcoin points statistically uniform. |
| 10:35:53 | nsh: | hmm |
| 10:36:34 | gmaxwell: | 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:39 | nsh: | do curve25519/ed25519 have extra structure that facilitates efficient mapping? |
| 10:36:43 | gmaxwell: | Yes. |
| 10:36:45 | nsh: | ok |
| 10:37:44 | TD: | every value is a valid point, or something like that |
| 10:39:16 | nsh: | * nsh rereads petertodd's proposal thread |
| 10:39:19 | gmaxwell: | 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:16 | gmaxwell: | (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:47 | TD: | i think it's spelled "elligator" |
| 10:40:56 | TD: | i remember this, because i know a cryptographer called elli |
| 10:41:01 | nsh: | 50% of ed25519 points don't have elligator mappings iirc |
| 10:56:51 | gmaxwell: | http://lightspeedindia.wordpress.com/2014/01/13/bitcoin-2014-top-10-predictions/ |
| 10:57:10 | gmaxwell: | 7. The use of Bitcoin will evolve beyond ‘store of value’ or ‘transactions’ |
| 10:57:13 | gmaxwell: | 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:48 | sipa: | note that they at least say "meta data" and not "data" |
| 10:58:34 | gmaxwell: | 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:51 | Ursium: | Morning! (if you're in the UK and went to be late like me :)) - What do you guys think of Ethereum? |
| 11:14:03 | Ursium: | Ursium is now known as Ursium_ |
| 12:24:01 | Ursium_: | Ursium_ is now known as Ursium |
| 13:23:37 | justanotheruser: | What do you guys think of ethereum? |
| 13:40:21 | tacotime_: | This question again haha |
| 13:41:07 | tacotime_: | 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:35 | Ursium: | tacotime_: but the fundraiser hasn't taken place yet |
| 15:20:48 | Ursium: | oh do you mean 'it will be well funded' ok . |
| 15:21:33 | tacotime_: | 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:51 | Ursium: | 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:27 | petertodd: | gmaxwell: ? |
| 15:42:41 | petertodd: | gmaxwell: what do you mean by "decrypting the nonce"? |
| 16:34:45 | gmaxwell: | petertodd: you suggested in your message that the nonce could be encrypted with H(stealth address) |
| 17:11:37 | petertodd: | 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:13 | petertodd: | gmaxwell: The point of doing so is only as a incremental improvement so that all OP_RETURN uses looks semi-similar. |
| 17:13:22 | petertodd: | gmaxwell: oh, wait, I get your point... yeah, that's a problem |
| 17:13:58 | petertodd: | 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:28 | adam3us: | 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:01 | adam3us: | 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:01 | adam3us: | 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:33 | gmaxwell: | adam3us: go see petertodd's stealth address post in bitcoin-dev |
| 17:29:50 | adam3us: | gmaxwell: yes i read that at the time. |
| 17:30:42 | gmaxwell: | 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:59 | adam3us: | 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:01 | petertodd: | 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:57 | adam3us: | 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:20 | petertodd: | adam3us: well the stealth address is known to our attacker in my attack model |
| 17:41:12 | adam3us: | petertodd: doesnot the stealth address S=dP=eQ ie unknowable if u do not know d or e |
| 17:42:19 | petertodd: | 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:54 | petertodd: | 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:57 | adam3us: | petertodd: ok as far as that goes i why dont you use one of the input addresses as the emphemeral pub key |
| 17:43:35 | petertodd: | 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:58 | adam3us: | 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:31 | petertodd: | adam3us: the thing is in this case the attacker *does* know the key, only the weaker attacker doesn't |
| 17:44:46 | petertodd: | adam3us: the weak attacker is worse off, but the not so weak attacker is much better off - bad tradeoff |
| 17:45:19 | adam3us: | petertodd: how did u arrive at a threat model where the attacker knows your decryption key? |
| 17:45:38 | petertodd: | adam3us: because it's in the stealth address itself |
| 17:52:48 | adam3us: | 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:58 | adam3us: | petertodd: seems stuck in circular dependency |
| 17:54:47 | petertodd: | 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:09 | petertodd: | adam3us: read my post again and you'll see what I mean |
| 17:55:37 | adam3us: | petertodd: the original post or one of the 5 followup posts? (i didnt find it yet) |
| 17:55:52 | petertodd: | adam3us: my original |
| 18:01:13 | adam3us: | 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:08 | adam3us: | 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:43 | adam3us: | 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:59 | gmaxwell: | adam3us: he wanted to obscure that it was a stealth payment maybe share anonymity set with a timestamping thing. |
| 18:30:06 | gmaxwell: | But no joy. |
| 18:30:53 | adam3us: | gmaxwell: ok hence the elligator thread. |
| 18:32:43 | adam3us: | 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:10 | nsh: | * nsh looks at this twister.net.co thing |
| 19:13:17 | TD: | TD is now known as TD[gone] |
| 19:33:36 | nsh: | libboost-dev is 60Mb.... |
| 19:33:58 | nsh: | (with all the attendant repocruft) |
| 19:36:44 | nsh: | wait, another 139Mb for libboost-all-dev |
| 19:46:55 | CodeShark: | CodeShark is now known as CodeShark_ |
| 20:56:17 | CodeShark_: | CodeShark_ is now known as CodeShark |
| 22:40:56 | gmaxwell: | https://soundcloud.com/rdlmitedu/140113_0001-wav Matt Green presents Zerocoin/Zerocash at Real World Crypto 2014 |
| 22:45:55 | Luke-Jr: | gmaxwell: is it practical now? |
| 22:46:13 | petertodd: | gmaxwell: they released a paper yet? |
| 22:46:30 | jron: | petertodd, no paper yet afaik. |
| 22:47:14 | nsh: | has anyone looked at how twister is using the blockchain/PoW and to what degree it's sane/scalable? |
| 22:47:45 | petertodd: | nsh: it's aweful, for instance there is a per-tx PoW, yet the difficulty for that PoW is hard-coded |
| 22:47:58 | nsh: | mm |
| 22:48:22 | nsh: | it is viable in principle though? |
| 22:48:38 | maaku: | gmaxwell: anything new presented at that talk? |
| 22:48:39 | nsh: | seems to be very early alpha, so maybe all kinds of silly parametric decisions/hacks |
| 22:48:43 | petertodd: | 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:48:54 | nsh: | :/ |
| 22:49:03 | gmaxwell: | maaku: I haven't listened to it yet, I peppered jron with some questions. |
| 22:49:07 | maaku: | k |
| 22:49:14 | petertodd: | jron: pity |
| 22:49:33 | jron: | Luke-Jr, it sounds like the only thing they add to the blockchain is 288 bytes |
| 22:49:35 | petertodd: | nsh: it should have used an existing name thing like namecoin |
| 22:49:48 | nsh: | * nsh nods |
| 22:50:16 | petertodd: | jron: small enough it doesn't need to be a separate chain, although my understanding is they're making it one |
| 22:50:31 | jron: | petertodd, correct. they are calling it "zerocash" |
| 22:50:34 | gmaxwell: | 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:50 | petertodd: | jron: and totally separate PoW right? |
| 22:50:56 | gmaxwell: | jron: Did they say anything about recovering space from old completed transactions? (e.g. analogous to pruning in bitcoin) |
| 22:51:10 | jron: | petertodd, there was no mention of their PoW function. |
| 22:51:35 | gmaxwell: | 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:04 | petertodd: | 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:07 | jron: | gmaxwell, there was no talk of pruning that I heard. |
| 22:52:14 | gmaxwell: | jron: :( |
| 22:52:47 | jron: | petertodd, I assume proof of sacrifice is destroying btc? |
| 22:52:53 | petertodd: | jron: yup |
| 22:53:01 | jron: | I was thinking about that on the drive home. |
| 22:54:17 | petertodd: | 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:17 | nsh: | that soundcloud recording is 600% reverberation by weight |
| 22:54:18 | nsh: | :/ |
| 22:54:30 | petertodd: | nsh: I hear it was held in a big church :/ |
| 22:54:40 | nsh: | shame |
| 22:54:44 | gmaxwell: | 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:06 | Luke-Jr: | anyone have any legal contacts with Google? |
| 22:58:23 | maaku: | Luke-Jr: as in with Google's lawyers? |
| 22:58:37 | Luke-Jr: | maaku: yes, or anyone who can help me get Nest thermostats GPL compliant :p |
| 22:59:14 | jron: | 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:27 | maaku: | holy cow, $3.2 billion for a thermostat? |
| 22:59:42 | Luke-Jr: | maaku: it's a smartphone inside |
| 23:00:00 | Luke-Jr: | and right now it gives the company complete control over your home temperatrue :/ |
| 23:00:44 | jron: | 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:03 | petertodd: | jron: 2 min on what kind of machine? |
| 23:01:28 | jron: | petertodd, single core current gen |
| 23:01:41 | petertodd: | jron: not bad, is the computation parallelizable? |
| 23:02:02 | jron: | petertodd, he didn't say. I assumed it was but that is a great question. |
| 23:02:06 | maaku: | 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:25 | maaku: | it'll be fixed within hours |
| 23:03:00 | petertodd: | jron: if the computation can be outsourced in any way would be really interesting too |
| 23:03:02 | jron: | he also mentioned a large blog that is required to spend coins. the size is about 1.2 GB. |
| 23:03:10 | maaku: | jron: 2 minutes to *verify* a transaction, not sign? |
| 23:03:16 | jron: | large blob* |
| 23:03:32 | petertodd: | jron: is the 1.2GB akin to a private key, or some shared data structure everyone just needs? |
| 23:03:40 | maaku: | ok n/m reading fail |
| 23:03:44 | jron: | maaku, verification is sub second. |
| 23:03:45 | gmaxwell: | jron: sounds like he actually didn't give a lot of technical details. |
| 23:04:04 | jron: | gmaxwell, it was a basic overview. |
| 23:04:06 | Luke-Jr: | maaku: HN? |
| 23:04:06 | gmaxwell: | This is annoying, because I actually can answer all of these questions. |
| 23:04:59 | michagogo|cloud: | Luke-Jr: Hacker News |
| 23:05:53 | michagogo|cloud: | Luke-Jr: So I'm guessing you already saw https://nest.com/legal/compliance/ and it's incomplete? |
| 23:05:58 | gmaxwell: | 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:32 | jron: | petertodd, he descibes the 1.2 GB dataset as a large set of public params required to spend coins. |
| 23:06:57 | gmaxwell: | 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:00 | Luke-Jr: | michagogo|cloud: it's missing build/install stuff |
| 23:07:35 | gmaxwell: | 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:07:35 | michagogo|cloud: | ah |
| 23:08:34 | gmaxwell: | 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:40 | gmaxwell: | (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:42 | jron: | they did mention the use of SHA256 and SNARK to achieve the proof size |
| 23:12:37 | maaku: | jron: did they go into any detail about how the public params were derived? |
| 23:13:21 | jron: | |
| 23:13:21 | jron: | |
| 23:14:11 | gmaxwell: | ^ that was from when I asked in #zerocoin |
| 23:15:02 | gmaxwell: | 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:11 | Alanius: | I think I know what I'm reading tomorrow :-) |
| 23:16:19 | Luke-Jr: | gmaxwell: does someone *need* to know the private key? |
| 23:16:31 | maaku: | Luke-Jr: you need the private key to create the public params |
| 23:16:38 | Luke-Jr: | else, have lots of N people pick entropy to produce a public key for which there is no known private <.< |
| 23:16:41 | maaku: | so you need to trust that someone diddn't keep a record |
| 23:16:45 | gmaxwell: | it has to be known temporarily to generate the public keys. At least unless you invoke some multiparty computation unicorn. |
| 23:16:49 | maaku: | or MPC |
| 23:16:58 | Luke-Jr: | so the public key can't be generated without the private key? :< |
| 23:17:01 | nsh: | someone needs to be trusted to forget something... |
| 23:17:15 | Luke-Jr: | Bernanke can do it! |
| 23:17:18 | gmaxwell: | 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:18 | nsh: | lol |
| 23:17:34 | gmaxwell: | 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:37 | gmaxwell: | 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:39 | petertodd: | 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:54 | maaku: | 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:00 | gmaxwell: | maaku: no. |
| 23:19:18 | maaku: | k, fair enough :) |
| 23:19:39 | gmaxwell: | 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:39 | maaku: | * maaku demonstrates is ignorance of pairing crypto |
| 23:20:22 | gmaxwell: | 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:20:36 | jtimon: | https://groups.google.com/d/msg/bitcoinx/EntSAsMLFck/X-7h5sgnMNoJ |
| 23:22:23 | petertodd: | jtimon: pragmatic, but computational crypto-coins are admittedly a lot more interesting solution to that problem |
| 23:22:46 | gmaxwell: | 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:04 | gmaxwell: | 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:11 | gmaxwell: | (linked here: http://www.scipr-lab.org/ ) |
| 23:23:30 | jtimon: | petertodd: I don't think I understand you |
| 23:23:48 | gmaxwell: | while they probably don't know anything about zerocash, they do know the backend cryptosystem. |
| 23:24:53 | jtimon: | petertodd: what problem you mean exactly? |
| 23:25:37 | jtimon: | petertodd: and what do you mean by "computatuional crypto-coins"? |
| 23:26:50 | gmaxwell: | 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:43 | petertodd: | 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:34 | jron: | someone posted some of the key points from the zerocash presentation here: http://pastebin.com/Dd60ZaT7 |
| 23:28:54 | gmaxwell: | petertodd: Zero knoweldge computational crypto coins are even better for that. |
| 23:29:32 | petertodd: | gmaxwell: of course, after all, you write about coin covenents on trolltalk |
| 23:29:44 | petertodd: | gmaxwell: s/write/wrote/ |
| 23:30:08 | gmaxwell: | jron: thanks! |
| 23:30:09 | petertodd: | gmaxwell: directly interpreted consensus systems can be upgraded to ZK systems after the fact |
| 23:31:47 | gmaxwell: | Yea, okay, so they point out there that the ZK based construction allows them to encrypt values to. |
| 23:31:58 | gmaxwell: | s/to/too/. |
| 23:32:19 | gmaxwell: | 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:26 | gmaxwell: | But it has some crazy consequences. |
| 23:32:38 | gmaxwell: | Like there becomes no way to even roughly gauge the size of the economy anymore. |
| 23:33:20 | gmaxwell: | 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:48 | jtimon: | 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:01 | gmaxwell: | In a system with hidden values under ZK proof a CRS compromise gives unbounded undetectable(*) inflation. |
| 23:34:17 | Alanius: | you could estimate roughly the size of the economy by monitoring the transaction fees |
| 23:34:23 | petertodd: | 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:24 | gmaxwell: | (*) 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:44 | jron: | gmaxwell, hah! |
| 23:34:53 | maaku: | Alanius: txn fees have nothing to do with txn values.. |
| 23:34:57 | gmaxwell: | Alanius: perhaps! but you couldn't tell if a transaction was for 1 coin or 100000 coins. |
| 23:35:15 | maaku: | petertodd: what does "totally generic" mean? |
| 23:35:28 | Alanius: | sure, but it would be pretty stupid to fee 10 coins for 1 coin's worth of actual transfer |
| 23:35:47 | Alanius: | hence, "roughly" :) |
| 23:35:53 | maaku: | it'd be a lower bound ... but probably a very low lower bound |
| 23:35:56 | gmaxwell: | 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:04 | maaku: | but i think you understand that :) |
| 23:36:17 | gmaxwell: | 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:44 | sipa: | Alanius: when fees are free-floating and there's an actual market around, i suppose to some extent |
| 23:36:47 | petertodd: | 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:39 | gmaxwell: | 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:45 | gmaxwell: | ... weird that you couldn't though! |
| 23:38:04 | petertodd: | 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:33 | petertodd: | maaku: (sorry, that's commit to (H(program), input arguments)->Eval() to be exact) |
| 23:38:49 | gmaxwell: | "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:09 | petertodd: | gmaxwell: or worse, have their marketing hats on... |
| 23:39:09 | gmaxwell: | I don't see any easy and catch free way to get pruning into an anonymous coin though. |
| 23:39:20 | gmaxwell: | petertodd: nah I just don't think they know a lot of people don't. |
| 23:39:44 | petertodd: | gmaxwell: ugh, pruning is in the satoshi whitepaper... |
| 23:40:04 | gmaxwell: | you think they really read it? |
| 23:40:07 | petertodd: | 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:03 | gmaxwell: | 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:21 | maaku: | petertodd: ok, i understand the feature request now. do you know a way in which this might be implemented? |
| 23:42:22 | gmaxwell: | 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:55 | petertodd: | 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:02 | gmaxwell: | 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:52 | gmaxwell: | The coins database can be append only, but the spent coins database needs an efficient VerNoExist() so it must be key ordered. |
| 23:44:14 | gmaxwell: | key ordered makes it hard to outsource efficiently. (requires tracking the network) |
| 23:44:15 | maaku: | 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:28 | maaku: | and those could be carried forward |
| 23:44:33 | petertodd: | 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:34 | Alanius: | couldn't one store the spent coins in a merkle mountain range? Or am I mixing things up here? |
| 23:45:03 | petertodd: | 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:04 | maaku: | Alanius: "the spent coins database needs an efficient VerNoExist() so it must be key ordered" |
| 23:45:24 | Alanius: | ah, mmr' |
| 23:45:31 | Alanius: | s do not allow proof of non-existence? |
| 23:45:33 | petertodd: | 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:02 | petertodd: | Alanius: they do, but the proof-of-non-existance is O(m log n) in size for a span of m blocks |
| 23:46:25 | petertodd: | Alanius: which you can do in zk-snark fashion, but that's costly |
| 23:46:40 | maaku: | petertodd: i think that's misleading from the context of his question |
| 23:46:51 | maaku: | Alanius: you can only prove non-existence based on what is being indexed |
| 23:47:04 | maaku: | MMR is indexed based on insertion order |
| 23:47:24 | maaku: | so you can prove, for example, that no coin was spent in between two adjacently spent coins |
| 23:47:27 | jtimon: | 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:29 | maaku: | which is pretty useless |
| 23:48:07 | Alanius: | maaku: thanks! very intuitive explanation :) |
| 23:48:22 | maaku: | jtimon: he wants to attach arbitrary validation rules to outputs, and have those propogate in arbitrary ways in future transactions |
| 23:48:28 | petertodd: | 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:58 | petertodd: | 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:04 | gmaxwell: | 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:33 | gmaxwell: | where 'generation number' means like "what month was it created in" |
| 23:49:59 | petertodd: | gmaxwell: yup |
| 23:50:03 | gmaxwell: | and then you can say that coins become unspendable after so many months, allowing you to prune both data sets. |
| 23:50:08 | gmaxwell: | But its kinda ugly. |
| 23:50:16 | Alanius: | that would partition the anonymity set |
| 23:50:24 | gmaxwell: | as it reduces your anonymity set and makes your coins expire.. and we can't even tell how many coins have expired! |
| 23:50:39 | petertodd: | gmaxwell: but why make them unspendable? just force you to prove correct manipulation of the spent set in your tx |
| 23:51:23 | gmaxwell: | 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:31 | gmaxwell: | I suppose thats true. |
| 23:51:47 | petertodd: | gmaxwell: well, doesn't even have to be more expensive, just more annoying |
| 23:52:06 | gmaxwell: | You still have the anonymity set reduction though, alas. |
| 23:52:15 | petertodd: | 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:47 | petertodd: | 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:12 | gmaxwell: | oh it's much better since same time could be defined to be a month or more. |
| 23:53:18 | petertodd: | exactly! |
| 23:53:36 | gmaxwell: | it's still not free however. |
| 23:53:40 | petertodd: | 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:46 | gmaxwell: | also there are some other tradeoffs which come into play. |
| 23:54:00 | petertodd: | ? |
| 23:54:16 | gmaxwell: | 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:57 | gmaxwell: | One of the plus sides of pruning is that it should make the ZK proofs faster. |
| 23:54:57 | petertodd: | gmaxwell: so make a tree of every month from now until eternity |
| 23:55:14 | petertodd: | ok, sure |
| 23:55:24 | gmaxwell: | "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:31 | gmaxwell: | (quoting from the talk) |
| 23:55:47 | gmaxwell: | sounds like they fixed the tree size at 64 deep so that they'd 'never' run out of room. |
| 23:55:54 | petertodd: | (note how they must have some mechanism to make collisions hard...) |
| 23:56:27 | gmaxwell: | With pruning we can do better and say, have a 2^33 deep tree. Which is fine for a months of transactions. |
| 23:56:29 | petertodd: | (oh, actually, no that's not true, you don't need that) |
| 23:56:50 | petertodd: | true, although the risk of accidentally picking someone elses serial number goes up |
| 23:57:25 | gmaxwell: | petertodd: no need to have a risk of that, you just use a >128 bit random serial number. |
| 23:57:32 | gmaxwell: | one turn of the compression function takes 512 bits. |
| 23:58:02 | gmaxwell: | 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:17 | petertodd: | 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:20 | jtimon: | 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:50 | gmaxwell: | petertodd: no no, it's insertion ordered. |
| 23:59:06 | petertodd: | gmaxwell: oh right, doh |
| 23:59:10 | petertodd: | gmaxwell: quite correct |