00:00:20 gmaxwell: well basically, the depth of that tree is purely your anonymity set 00:00:25 yes 00:00:39 say a coin looks like this [128 bit serial number, 64 bit future extensibility, 64 bit value, 256 bit P2SH hash] you add it to an insertion ordered tree. 00:01:02 jtimon: it's only scalable if you can figure out the right mining incentives and solve the data-hiding attack sufficiently 00:01:15 fractastical has quit 00:01:24 And then to emerge COIN you just produce a ZK proof that H(COIN) is in the tree.. which takes Log2(size) hashes under the ZK proof. 00:01:49 so if you require multiple trees for pruing purposes, then you can make them reasonably small at the cost of reducing the anonymity set. 00:03:30 petertodd, I don't know the data-hiding attack, but from what I hear from maaku what you're talking about is new, can I read a summary somewhere? 00:03:57 jtimon: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html 00:05:07 jtimon: basically, your utxo/txo/txin set in a cryptographic accumulator, and you can only update the state of that set if you have the transactions that have happened, thus somehow you have to ensure you don't end up with that data getting lost 00:05:12 petertodd: that doesn't have generic-coloring stuff you were just talking about right? 00:05:31 jtimon: easy to do in a single consensus-realm system, but quickly becomes an existential risk if you try to scale more than that 00:05:49 maaku: not explicitly, but the basic ideas in that paper can be applied to such schemes 00:06:06 petertodd: is this accurate to what you are talking about: 00:06:23 So one can imagine a coloring script that acts kinda like a virus: it loads the transaction, does some checks to make sure it doesn't invalidate any coloring constraints, and then attaches itself (referencing it's own source code) to the colored outputs 00:06:29 petertodd: in that thread you only had commited utxi, not utxo 00:06:31 maaku: yup 00:06:42 jtimon: right, but the logic applies equally to utxo too 00:06:58 you'd need a much more powerful script language to do interesting things with that 00:07:06 but you certainly could do interesting things 00:07:20 maaku: heh, I'll say... such scriptPubKey's are quine's after all! 00:07:35 I'm sorry guys, I'm not sure I follow 00:07:49 petertodd: the coloring constraint can even validate a issuing authority signature, to make sure the the initial attachment was permitted. 00:07:52 jtimon: http://en.wikipedia.org/wiki/Quine_%28computing%29 00:07:58 but what I meant by making the utxi scalable through expriries 00:07:59 So you can't just go affixing it ot new random coins. 00:08:04 jtimon: so in bitcoin, when a miner finds a block, what forces them to release the actual block contents rather than just the block header? 00:08:40 gmaxwell: yup, or make it part of the program operating "if prev txout == magic return true" 00:09:00 petertodd: and to avoid the awful outcomes in my covenant thread... you make sure the color virus has a kill switch. 00:09:03 petertodd, other miners won't mine on top of your block if they can't see it in full, it could be invalid 00:09:12 e.g. a way to spend it to tell it to not attach to the output. 00:09:36 petertodd: we originally had introspective scripts in the freimarkets spec but gutted it because we didn't see a compelling use case, but this changes things 00:09:57 it's a bit of complexity, but probably worth it 00:10:11 jtimon: Exactly. But other than that, what actually forces them to do that? For instance, what if you could prove a transaction was valid without the UTXO data itself? 00:10:45 shesek has quit 00:11:04 maaku: I gotta read the freimarkets spec... 00:11:24 nobody forces them, is just the best they can do, not sure I understand the second question... 00:12:19 http://www.itbusiness.ca/news/royal-canadian-mint-readies-its-version-of-bitcoin-mintchip/46113 mintchip is moving forward? heck yea. 00:12:23 petertodd: well its not in any public version of the spec, but I wouldn't be opposed to adding it back in 00:12:24 jtimon: well, we can make systems where transactions can be accompanied by short proofs that their txins are valid, and those proofs can be used to update things like committed UTXO set trees. Those two things let miners mine while fully validating, but without any blockchain data. 00:12:58 petertodd: it may be sufficient reason to revamp script entirely 00:13:14 gmaxwell: I'll be interested to see if that alleged privacy leak is still in the spec... 00:13:28 (we mostly dropped it because doing introspection was a kludge without LISP-like semantics) 00:13:37 maaku: it's a pretty useful feature IMO - I first thought of it for fidelity-bonded bank stuff 00:13:50 maaku: I suspect you can do it reasonably nicely with real forth semantics 00:14:22 petertodd: man, I wish I'd thought to ask them to be able to do something to do trustfree binding with bitcoin. 00:14:27 Ursium has joined #bitcoin-wizards 00:14:48 gmaxwell: if it was possible by accident they probably would have changed it to prevent it... 00:15:31 petertodd: e.g. just a "I've been paid!" message signed by your chip is enough. 00:16:19 gmaxwell: sure, although good luck on it being crypto-compat with bitcoin 00:16:27 has anyone looked at hard-fork scripting improvements? other than Merklized scripts 00:16:43 maaku: I'm not sure there are any scripting improvements that actually need a hard fork you know... 00:16:44 Merklized scripts don't have to be a hardfork improvement. 00:16:53 You just P2SH deploy the update. 00:17:05 petertodd: does this require any snark-like tech? maaku: what are the differences from "regular stateless validation" 00:17:07 ? 00:17:26 jtimon: not at all 00:17:28 jtimon: i think petertodd is explaining stateless validation 00:17:34 maaku: yup 00:18:15 maaku: things I want merklized scripts, restore missing opcodes, extra checksig flexibility, true scalable threshold signatures (e.g. schnorr). 00:19:11 "Money instantly moves from one cloud-based, MintChip account to another" <- it's cloud-based now? hmm... 00:19:15 ok, I guess then I don't undesrtand stateless validation well enough because I don't see how would you do coloring or what the power of the scripting language has to do with it 00:19:49 oh also, I eventually invented a much better scheme for hash based signatures, only to realize I invented something that has long been known. E.g. one time use hash based signature with 128 bit security (using 256 bit hashes) = 2.1kbytes. 00:19:50 jtimon: it's got nothing to do with either 00:19:57 petertodd: oh dear, did they make it suck? 00:20:15 gmaxwell: wouldn't surprise me... they probably noticed phones don't have card-readers 00:20:44 gmaxwell: and if they made it suck, they probably also made it possible to reverse tx's due to hacks... 00:20:53 damnit 00:20:59 can't you put an NFC card near a phone? 00:21:16 jtimon: that's harder than making it suck 00:21:33 I hope they didn't make it suck. 00:21:35 jtimon: and seriously, even that is susceptable to hacks - you really need a NFC card with a LCD display 00:21:42 Even without trustless binding it was going to be awesome for bitcoin. 00:22:06 gmaxwell: i've been compiling a list of things that might make it in an updated freimarkets spec, and those are on it 00:22:15 yeah, I guess you need a lcd and a couple of buttons in the card 00:22:31 i'd love both lamport signatures and ed25519-derived schnorr signatures (if that is possible) 00:22:37 jtimon: yup, and then you really want the cards to be registered to people's names, so the lcd displays who it's really going too... 00:22:50 using the sighash byte to keep compatability 00:22:55 I am less enamored with ed25519 than I was. I like our curve better now. :P 00:23:01 fractastical has joined #bitcoin-wizards 00:23:06 why? 00:23:10 maaku: just have a second checksig operator. 00:23:17 shesek has joined #bitcoin-wizards 00:24:38 maaku: because ed25519 has a cofactor of 8, and because the "standard" software for it is incompatible with things like BIP32. (also, because one of the things I thought was weak about our curve turned out not to be.) 00:25:15 I believe our curve also has higher security against all known attacks, outside of implementation mistakes, not that it matters much. 00:25:38 but it is faster & resistant to timing attacks, isn't that pretty significant? 00:26:11 no, in fact it's not resistant to timing attacks unless you drop the compatiblity with BIP32. (or make it much slower) 00:26:26 To make it constant time (and faster) they require the most siginficant bit of the private key be 1. 00:26:45 i mean I'm in aggreement with our curve not being weak, but I thought ed25519 was strictly better in most cases 00:26:49 which means that you can't have a 'randomly' generated private key, e.g. from a public derrivation. 00:27:20 and without that you make it slower and you take away the constant timeness (though you could get back the constant timeness with a major slowdown, just like for our curve) 00:27:27 sorry confusing pronoun dereferencing : ed25519 is resistant to timing attacks and secp256k1 is not, right? 00:27:33 and the speed difference isn't so huge. 00:27:45 hrm. ok 00:29:03 i see, so it'd be quite a bit of work for little payoff 00:29:05 maaku: _curves_ aren't resistant or not, their implementations are, though curve choice can limit what implementations are available. ed25519's canonical implementation is both fast and timing resistant, but requires that the most significant bit of the private key be 1. 00:29:31 which kills bip32, i understand now 00:29:43 so why does that kill bip32? 00:29:54 which is neat, but if you take away that bit, then its not timing resistant, and making it timing resistant makes it not fast. (though it may still be better off than secp256k1) 00:30:08 petertodd: it kills type-2 derrivation since you can't tell if the private key will have the MSB set. 00:30:31 now— it may not be much work in reality, because the tor project has this whole big proposal for a redo of hidden services. 00:30:44 roidster has quit 00:31:07 And it does something very similar to type-2 derrivation to prevent HS directories from enumerating which hidden services are in use. 00:31:09 gmaxwell: right, although you could do a checksig that did bip32 with some kind of crazy 1-of-m multisig essentially, although at the cost of privacy 00:31:18 And they're planning on doing this with the ed25519 curve. 00:31:32 And I don't think they've yet realized that they won't be able to use the standard implementation… 00:31:48 separate issue, does what I said here make any sense? Is Flavien right? https://groups.google.com/d/msg/bitcoinx/Nq_8dkC3zqU/h_aqRA5A7TkJ 00:31:52 (I only realized this because I went and tried to implement ed25519 for bitcoin) 00:32:20 petertodd: BIP32 perhaps, but not the privacy purposes of it. 00:32:24 Or stealth addresses. 00:32:29 Which is basically the same usecase tor has. 00:32:53 gmaxwell: yup, although OTOH a merkle tree would do it, at the cost of size 00:32:53 (and incidentally, tor is working on a rigorous security proof for their derrivation scheme, though last I checked they hadn't made much progress) 00:33:21 petertodd: not for privacy, I could see your hashroot was the same. :P 00:33:23 jtimon: it makes sense 00:33:49 fractastical has quit 00:34:25 gmaxwell: no, the hash root would be of n pubkeys, and if you could spend any one of them you can spend the txout. each pubkey is still bip32-style secure, although there is a 1 in 2^256 chance of not being able to spend the txout (or whatever the math is) 00:34:53 petertodd: thanks, so Flavien is wrong saying you can reuse an address to sign securely 100 times a day even if you don't care about privacy 00:35:44 jtimon: well, the bigger thing is that you should just have the definition of a valid ccoin txout be "whatever the issuer signs", with a separate merkle sum tree for auditing purposes 00:36:19 jtimon: your proof that your ccoin is valid just needs to be that the signature on the genesis txout was valid 00:36:26 jtimon: the chance of choosing the same K value is exceedingly low ... unless you have a bad RNG, in which case it is exceedingly high 00:36:57 petertodd: oh god, you mean using lots of bip32 keys just to make sure you get one where the MSB is 1? 00:37:07 gmaxwell: yes! not that I ever said it was a good idea :P 00:37:17 petertodd: dear god, that idea ... so bad. ... must stab 00:37:19 petertodd, flavien is talking about "inflatable colored coins" in which the same address can be used to just issue more 00:37:21 If you assume your RNG is good or use deterministic signatures, key reuse is not a problem (from that perspective only) 00:37:29 gmaxwell: pity you can't stab someone over the internet 00:37:46 Guest41992 has joined #bitcoin-wizards 00:37:56 so maaku says flavien is right... 00:37:57 I'm pretty sure there is an onion site for that. 00:37:58 jtimon: yes, which is a dumb idea, just use the signature to sign a message saying some arbitrary txout is colored 00:38:06 but you still wouldn't want to tie it to an unchanging address anyway, for a multitude of other reasons 00:38:45 jtimon: he is not factually incorrect when he says "Signing a billion transactions per second, it would still take you hundreds billion times the age of the universe before you have 1% chance of collision." 00:38:58 (assuming perfect RNG or deterministic signatures) 00:39:06 petertodd: you ever hear about how the signature systems which are based on one-time-hash based signatures but allow ~infinite signatures work? 00:39:33 but those are invalid assumptions for real-world cryptography 00:39:36 gmaxwell: of course, which is why I expected the idea to raise your blood pressure :P 00:40:08 * petertodd has been paid off by the NSA to kill gmaxwell via heart disease 00:40:30 where with a bad RNG (or a reused seed value on a VM) it only take two signatures to give up the key 00:44:29 maaku I was going to answer something like "thank you for the clarification, then addresses is still the right approach for inflatable basic CC, but since we have tokens in freimarkets for other reasons, they're still more convenient for re-issuance as well" 00:46:08 Guest41992 has quit 00:46:28 jtimon: it's not just a matter of convience. it lets you have more control over operational security, for example by having one key per signing server and local protections against K reuse 00:47:10 which would protect you against spinning up two separate servers, who each sign separate messages with the same K value 00:47:39 petertodd: I knew it! 00:47:44 (due to saved random state in the VM image and a lack of entropy) 00:47:51 Is bitmessage off topic here? 00:48:06 justanotheruser: so long as it involves arcane spell 00:48:08 s 00:48:21 ? 00:48:25 well the "one address" in colored coins could be a p2sh multisig or whatever, by convenience I also mean that more control 00:49:56 jtimon: yes, but in the example I gave you need tokens because you need a new key every time you spin up a server, and eventually you run out 00:50:03 tokens allow you to change the p2sh one addres doesnt 00:50:10 although if you had bip-32 in script... 00:50:19 yes 00:50:45 if you could do bip-32 derivation in script though, you could get by with a single address 00:51:07 Anyways, how well does bitmessage scale? Would it work with 10 million users? 00:51:21 not if you want to radically change the config 00:51:45 yeah 00:52:13 justanotheruser: scaling is largely in terms of the anonymity set size. 00:53:01 justanotheruser: they kinda waved their hands at the streams stuff in their initial writeup though so the mechnisms needed to get people onto different streams is unde(rde)fined. 00:53:55 Nice use of parenthesis there. How is scaling in terms of the anonymity set size? Will the network break into sections or something? 00:53:56 <_ingsoc> _ingsoc has quit 00:54:45 justanotheruser: the idea is that the POW would increase to keep the datarate in a stream sane. And thus that would push people off onto other streams where the pow was lower (but the anonymity set smaller). 00:55:15 ...which is basically what sane people propose for consensu blockchains in general. 00:55:38 I see. And there is no in depth explanation for their streams? 00:55:43 it's just that how that'll actually work in bitmessage si a lot more obvious - no "oops I let a tx spent a bit of dust that didn't actually exist" problem 00:55:49 justanotheruser: not that I've seen 00:56:15 there is a stream setting on addresses, so the stream stuff is implemented but no 'fee intelligence' if you will. 00:56:36 justanotheruser: you can also do steams based on sharding H(addr) space (roughly speaking) 00:56:53 I think they don't quite have the incentives well aligned. they guy sending to you pays the pow for your choice of stream. 00:57:05 so, duh, yea, of course I'm going to pick stream 0. 00:57:14 let you suckers pay the cost of messaging me. 00:57:32 gmaxwell: yup, although another way to look at it, is the person messaging you is picking the size of the anonymity set thye want *their* message to be in 00:57:40 Well there is an incentive to have someone message you right? 00:57:54 I mean to send a message 00:58:15 So if you don't agree on the stream then it wouldn't be sent 00:58:23 justanotheruser: yup, and stream would be part of addr 00:58:24 petertodd: well no the recipent picks the the stream. Not the sender, and thats generally good because its the recipents privacy that is triciker. 00:58:45 I think the incentive issue is probably not fatal, as justanotheruser says— people want to recieve messages. 00:58:49 But it is interesting. 00:59:05 eristisk has joined #bitcoin-wizards 00:59:21 gmaxwell: right, but you can easily imagine a system where you have receivers listening to some fraction of the addr space by prefix, and senders get to pick how much of the prefix they match based on how much pow they spend 00:59:39 gmaxwell: limit bandwidth based competition for a given prefix specificity 01:00:33 gmaxwell: hilariously, that matches really well to what PoW algorithms actually do... but in the exact wrong way 01:01:12 How does the reduced anonymity effect the anonymity of coinjoins? Does it even matter? 01:01:48 justanotheruser: depends on how anonymous you want to be... 01:01:59 I don't know that it even matters. ... though I assume anyone would use bitmessage over tor. 01:03:27 justanotheruser: oh, you mean coinjoin over bitmessage? meh, bitmessage isn't a great message layer for cj anyway from a usability perspective 01:04:05 petertodd: there are no more sutiable traffic analysis resistant privacy networks. 01:04:07 petertodd: Why not? I would think it is great, it just needs a layer on top of it to handle it 01:04:10 justanotheruser: needing a PoW to send a message is ugly vs. using fees for it 01:04:27 justanotheruser: and you can use fees to pay for it with the nLockTime trick 01:05:17 petertodd: I think gmaxwells idea of using PoS is better. 01:05:48 People don't really want to pay double fees, one for the message and one for the coinjoin. 01:06:14 justanotheruser: you don't have too though, you make a nLockTime'd tx spending one input, and then respend it in the coinjoin 01:06:41 justanotheruser: either way you spend some tx fee, and you can arrange all of this such that the attacker doesn't learn much 01:06:55 petertodd: how would you determine the coinjoin tx without being able to communicate with the network first? 01:07:17 justanotheruser: your communication includes that nLockTime'd tx - that's how you pay for it 01:07:54 petertodd: well you would have to pay a fee for that tx, then everyone would have to pay a fee for the coinjoin tx to go through 01:08:05 justanotheruser: which you have to anyway - tx's aren't free 01:08:22 petertodd: yes, but with PoS you only have to pay one 01:09:02 justanotheruser: no, it's identical to pos, except that you ensure something of value is actually lost 01:09:34 justanotheruser: after all, you can't prove pos other than by signing for a txotu scriptPubKey, this is the same, except you've signed a valid-in-the-future transaction with some minor fee 01:11:25 petertodd: When you have stake that means you payed a fee to get the coins. That is what you lost. 01:12:18 justanotheruser: it's the same argument as merge-mining: to the attacker they can re-use something they already have (txouts sitting around) for free 01:12:23 except for cases where millionaires don't pay fees, but there aren't enough of those to worry about 01:12:32 orperelman has quit 01:13:15 petertodd: they can use it for free, but they can only use a certain amount of it. Then they have to make another tx to spend again. The coinjoin tx takes care of this. 01:14:28 s/use a certain amount of it/use it to a certain extent. 01:15:21 justanotheruser: yes, but now you have to have a database of UTXO's whose stake has been proved, vs. there's a natural time limit because the fee sacrifice tx's get mined 01:16:13 gmaxwell: does pinnochio take care of petertodds concern? 01:17:46 petertodd: Wouldn't proof of burn also remove anonymity in the same way? 01:18:39 justanotheruser: yes, emphasis on the same way, they're both identical re: anonymity, but the burn version has better resistance to DoS attack 01:21:47 petertodd: I don't understand pinnochio fully, but gmaxwell said it would work for proof of burn and I think he said it would work with PoS 01:22:01 It's a pretty big research paper 01:22:15 what concern? 01:22:16 And I have to look stuff up every page 01:22:22 you guys said a bunch of stuff 01:22:35 gmaxwell: (08:15:21 PM) petertodd: justanotheruser: yes, but now you have to have a database of UTXO's whose stake has been proved, vs. there's a natural time limit because the fee sacrifice tx's get mined 01:22:37 justanotheruser: pinnochio is orthogonal to the choice between proof-of-stake and proof-of-sacrifice 01:23:15 petertodd: then your comment was irrelevant to the discussion of which was the better method 01:23:27 what pinnochio lets you do is make compact blind proofs from something where you have efficiently extractable authenticated data. 01:23:29 because they both have that glaw 01:24:03 justanotheruser: pinnochio's proof-of-stake for anti-DoS still requires a UTXO database, or you can re-use proofs. (it becomes like some weird zero-coin thing in that case) 01:24:35 right now because we don't have a committed utxo proof-of-sacrifice will be smaller unless you expect all validators to keep a copy of the utxo themselves. Having the verifiers have a utxo database might actually be a bunch better since it could be restructured in a way to make the proofs small. 01:24:36 justanotheruser: for the proof-of-burn case, then pinnochio is less desirable because you have to do a separate burn that's actually mined 01:25:22 petertodd: my suggest for rate limiting based on POS is that you do get a once per $time_interval random ID out of your stake. 01:25:32 gmaxwell: proof-of-stake for anti-dos requires you to at worst end up storing something like a bloom table of spent stakes 01:25:52 gmaxwell: it's doable, but potentially ugly long-term if people really want to attack it 01:25:54 yea, you'd then use a hashtable that you keep for $time_interval 01:26:13 gmaxwell: I mean, you've created an incentive to make a lot of utxo's you know... or failing that, you let rich people block coinjoin 01:26:32 gmaxwell: at least proof of burn ensures they'll spend fees doing so 01:26:32 petertodd: well of course the proof can emerge a bound on its value. 01:26:47 couldn't your "proof of time" be the hash of your proof plus the unix time being below a certain value? 01:26:58 proof of burn can't be done non-interactively in zero knoweldge. 01:27:43 PoS and PoS can be. 01:27:51 gmaxwell: no, but my trick of nLockTime'd tx's isn't a serious disadvantage - note how you can very much use a different txout then the one you actually join 01:28:02 for coinjoin PoB is pretty great, I agree. 01:28:19 since coinjoin inherently must expose a txout. 01:28:35 yeah, and for everything else, proof-of-prior sacrifice *with* some kind of domain-specific tag is pretty decent 01:28:38 for something like a replacement for BitMessage's pow I prefer PoS or PoS. 01:28:57 gmaxwell: PoS and PoS (i do keep reading that as piece of s**t...) 01:29:27 Proof of Stake or Proof of sacrifice. 01:29:38 sipa: PoS and PoX I prefer myself 01:29:47 gmaxwell: should their stake expire after a certain number of blocks? Otherwise they can use the network at no cost 01:30:07 justanotheruser: you'd prove that you had stake as of some reference time that moves periodically. 01:30:17 e.g. first block after midnight utc every day. 01:30:29 justanotheruser: funny how you actually want the inverse of coinage in this case 01:30:39 petertodd: yes, coin/days 01:30:50 every day at the first block after midnight all the message nodes snapshot their utxo and reorg it into a hash tree and save the root. 01:31:20 Then when you want to use a message for this hour you run the ZK proof to get a token good for the hour that proves you had a coin in the last day's utxo snapshot. 01:32:09 likewise for proof of sacrifice, except you just extract sacrifice like transactions. 01:32:16 gmaxwell: heck, just prove you have a txout that existed in some time period, and spent a txout preior with some amount of coin-days destroyed 01:33:23 yea, whatever, you can get compact proofs of any of this if you don't mind the participants needing to bitcoin nodes and thus generating the data extracts themselves. 01:33:56 gmaxwell: well, that case you'll have all that data in your wallet actually 01:33:58 unfortunately using bitcoin's own data for ZK proofs is kinda craptastaic because of having to traverse a whole variable length transaction just to extract an output. 01:34:06 yup 01:34:19 but if you extract the data directly you can reorder how its stored. 01:34:35 How big is the proof of stake using pinnochio? 01:34:43 e.g. use exactly the ultraprune data structure though bitcoin itself never commits to it... all participants would come up with the same value. 01:36:03 justanotheruser: the proofs are 288 bytes (well, in the pinnochio paper they might be a bit larger, but they can be done in 288 bytes), plus a few more bytes to identify the serial number, epoch, and utxo set that its relative too. 01:36:54 That's not bad 01:39:03 gmaxwell: Why is a proof of SHA256 so big? 01:41:18 justanotheruser: SHA256 is a non-trivial function? 01:41:33 maaku: So ECDSA isn't? 01:42:03 that's an apples-to-hot-wheels-cars comparison 01:42:24 gmaxwell: I do not appear to have an easily-accessible sidechain that reorgs out 1000-blocks, if -loadblock can be used to replay the blk*.dat files and the dat files have the sidechains stored in them by default. 01:42:29 justanotheruser: you don't need to prove ECDSA in this case 01:42:37 gmaxwell: I have one more place where I can look. Would you like me to check? 01:43:06 Because ECDSA is special in that it naturally yields compact proofs of knoweldge. There are very few things that do this. 01:43:15 midnightmagic: not that urgent I have it at home someplace. 01:43:20 gmaxwell: how does that work? 01:43:29 roidster has joined #bitcoin-wizards 01:43:32 ok 01:43:45 roidster is now known as Guest82569 01:44:07 gmaxwell: If it's cleanly possible to get a copy of that I would sure love one. :-D 01:44:09 petertodd: an ECDSA signature is a proof you know the discrete log of the public key value. 01:44:43 gmaxwell: ah, and these schemes can do that directly? 01:45:15 petertodd: no no. Perhaps we're miscommunicating. 01:45:34 I thought justanotheruser was asking why the pinnochio proofs were much bigger than an ECDSA signature. 01:46:02 gmaxwell: right, I took it as asking why you couldn't feasible make a pinnochio proof of a ECDSA sig 01:46:07 ECDSA is basically a scheme designed for creating a compact proof... for a very specific operation 01:46:48 petertodd: oh you could, and ... like all other GGPR'12 proofs would be 288 bytes. Though the proving time might be awful. 01:47:14 gmaxwell: right, and the proving would be some crazy thing that basically implements ECDSA with some circuit 01:47:40 right, with an arithemetic circuit over some finite field. 01:48:10 (or some boolean circuit, though usually arithemetic circuits are more compact, e.g. they make sha256 quite compact) 01:49:09 eristisk has quit 01:56:48 so the pinnochio source code is available, but I don't see any license anywhere 01:57:19 oh wait, I found it, Microsoft non-commercial, not too useful 02:05:09 jron has quit 02:12:37 petertodd: meh, that doesn't worry me _that_ much. The verifier is just a couple dozen lines of code given a sutiable pairing library. (which they don't provide, but there are several sutiable liberally licensed ones available) 02:14:05 the interesting code they provide is the circuit generator and the prover which are non-normative so long as you don't make something which is married to a single validation key. 02:16:44 about coloring in the context of zerocash, i think they could include another value in the hash, being the color 02:17:50 gmaxwell: that kind of sucks about the EdDSA high bit.. i was looking forward to compact k of n sigs, blind sigs & such :( 02:19:14 adam3us: I mean, it would only be a couple of lines of code to add schnorr signatures to sipa's library. compact k of n is kind of a killer feature. 02:20:00 gmaxwell: kind of annoyed at DJB now that is an unclean hack disguised as a feature. it fails composability 02:23:54 adam3us: well, I was made kind of annoyed by the "Safe or Not" summary table most recently added to safercurves 02:24:09 which has now three times caused me to get questions with urgent concerns that bitcoin's curve is not safe. 02:25:41 gmaxwell: the guys on IRTF/CFRG are making an RFC for safe curves.. can be good place to ask questions or complain if u see problems. they seem to have a good collection of people who understand ECC & coding 02:26:18 gmaxwell: as there is a guy moving pretty fast on getting an RFC through standardizing the safe curves 02:26:22 It's my opinion that the addition of the binary safe or not table debased an otherwise thoughtful site to marketing tripe... since it happily fails bitcoin's curve because the endomorphism shaves off 1.5 bits of security, while meanwhile his curves cofactor of 8 shaves off at least three bits of his already smaller curve, and then his implementation throws away another bit for that optimization. 02:26:27 wyager has joined #bitcoin-wizards 02:26:31 wyager has quit 02:27:18 jron has joined #bitcoin-wizards 02:30:35 "safe or not" is pretty stupid when it comes to proclamations of security completely devoid of context 02:31:50 if someone wants to advocate for schnorr and bip-32 comaptability with the RFC safe curves, that'd be a noble thing to do 02:35:04 what is considered unsafe about secp256k1? 02:35:28 http://safecurves.cr.yp.to/ 02:35:32 scroll down 02:35:48 it's "not safe" if it doesn't meet all of DJB's criteria. 02:36:07 the criteria are all interesting. Few of them would justify not-safe for failing them 02:36:17 jron has quit 02:37:13 esp since the critiera omits other no less reasonable considerations like "cofactor == 1", presumably since his own curves fail it. 02:37:38 chiefly, the fact that it doesn't have "25519" in its name 02:41:06 I gave a somewhat irritated response here: https://bitcointalk.org/index.php?topic=380482.0 (being that it was the second time that day I'd been asked about it) 02:46:29 jtimon has quit 02:55:44 DougieBot5000 has quit 02:58:13 Ursium has quit 02:59:03 jron has joined #bitcoin-wizards 03:28:14 wizards, i am enrolled in a "numerical iterative methods" class which is very open ended 03:28:34 can you think of any interesting (or useful to bitcoin) numerical analysis projcets? 03:35:47 andytoshi: network simulations can fall in that bucket. 03:36:38 andytoshi: if you wanted to fool with an altcoiny thing, control loops for difficulty adjustment. What else? Hm. anti-spam/dos attack hurestics perhaps. 03:38:41 mr_burdell has joined #bitcoin-wizards 03:49:35 Guest82569 has quit 03:58:32 Ursium has joined #bitcoin-wizards 04:03:20 Ursium has quit 04:30:18 mr_burdell has quit 04:35:02 jron has quit 05:01:14 Ursium has joined #bitcoin-wizards 05:06:15 Ursium has quit 05:09:55 jron has joined #bitcoin-wizards 05:22:53 gmaxwell, just take your entire hardfork list and implemetn them 05:29:27 orperelman has joined #bitcoin-wizards 05:38:33 justanotheruser has quit 05:45:09 orperelman has quit 05:48:39 justanotheruser has joined #bitcoin-wizards 05:50:09 justanotheruser1 has joined #bitcoin-wizards 05:51:20 justanotheruser1 has quit 05:51:20 justanotheruser1 has joined #bitcoin-wizards 05:52:55 justanotheruser has quit 05:55:55 justanotheruser1 has quit 06:00:43 justanotheruser has joined #bitcoin-wizards 06:01:59 Ursium has joined #bitcoin-wizards 06:05:26 justanotheruser1 has joined #bitcoin-wizards 06:05:54 justanotheruser has quit 06:07:24 Ursium has quit 06:10:32 justanotheruser1 has quit 06:10:32 justanotheruser1 has joined #bitcoin-wizards 06:12:34 Is there an alternative to pandora that has a GP or BSD license? 06:12:58 * Pinocchio 06:14:01 justanotheruser1 is now known as justanotheruser 06:17:05 fractastical has joined #bitcoin-wizards 06:30:36 fagmuffinz has joined #bitcoin-wizards 06:34:14 go1111111 has joined #bitcoin-wizards 07:02:24 maaku has quit 07:02:42 maaku has joined #bitcoin-wizards 07:03:05 maaku is now known as Guest13248 07:04:30 Ursium has joined #bitcoin-wizards 07:09:45 Ursium has quit 07:22:27 roidster has joined #bitcoin-wizards 07:42:36 roidster has quit 07:51:40 brisque has joined #bitcoin-wizards 08:01:03 iddo has quit 08:01:10 iddo has joined #bitcoin-wizards 08:05:17 Ursium has joined #bitcoin-wizards 08:10:00 Ursium has quit 08:26:19 Guest13248 is now known as maaku 09:06:00 Ursium has joined #bitcoin-wizards 09:06:05 <_ingsoc> _ingsoc has joined #bitcoin-wizards 09:11:48 Ursium has quit 09:12:23 andytoshi: numerical iterative analysis? perfect one for you: selfish attack? 09:32:16 fractastical has quit 09:47:21 TD[gone] is now known as TD 09:51:25 is there a EdDSA mailing list? or should i just email DJB? want to figure out this highbit/constant time 'hack' limitation on composability, thats kind of broken. 10:05:24 brisque has quit 10:05:41 brisque has joined #bitcoin-wizards 10:07:05 hnz has quit 10:11:55 hnz has joined #bitcoin-wizards 10:25:11 go1111111 has quit 10:30:41 brisque has quit 10:37:57 Ursium has joined #bitcoin-wizards 10:40:11 jtimon has joined #bitcoin-wizards 11:18:53 shesek has quit 11:31:01 shesek has joined #bitcoin-wizards 11:51:56 <_ingsoc> _ingsoc has quit 11:53:16 <_ingsoc> _ingsoc has joined #bitcoin-wizards 11:59:13 typex has quit 11:59:13 typex has joined #bitcoin-wizards 12:18:28 adam3us: the 'hack' is pretty simple, the second answer here explains it: http://crypto.stackexchange.com/questions/11810/when-using-curve25519-why-does-the-private-key-always-have-a-fixed-bit-at-2254/11818 12:19:15 and it's also easy to avoid, even if you want to run in constant time -- but then we'd have a nonstandard implementation 12:21:51 it might be worthwhile to bug him and ask what he was thinking, because it really is ugly and you're a name he ought to recognize.. 12:30:13 lianj has quit 12:30:44 lianj has joined #bitcoin-wizards 12:30:44 lianj has quit 12:30:44 lianj has joined #bitcoin-wizards 12:54:06 <_ingsoc> _ingsoc has quit 13:15:24 <_ingsoc> _ingsoc has joined #bitcoin-wizards 13:28:12 andytoshi: hmm so neves is saying it doesnt matter, if the code does the defense as the reference does, it is still constant time. what about the other bits? a[255]=0,a[254]=1, a[2]=a[1]=a[0]=0 13:28:38 adam3us: none of those will necessarily be the case after public HD derivation 13:29:53 adam3us: andytoshi: a[255]=0 maybe ok, as |n| < 255 (the order) i presume from the h=8 (cofactor) 13:36:13 adam3us: a[255] it appears is always zero, yeah, we'd be fine there (though why are we "using 255-bit strings" with only 254 actual bits??) 13:36:39 and as you say (and gmaxwell has been whining for weeks), bit 254 might not be set after pubic HD derivation, or multisig with additive signatures 13:37:18 this seems weird, i dunno why the reference implementation didn't just hardcode the 254 in there 13:38:39 maybe add a big comment saying not to change that if you are reimplementing, but i think it's pretty obvious that if you make your loop bounds depend on the input you are asking for timing attacks 13:38:55