| 00:00:20 | petertodd: | gmaxwell: well basically, the depth of that tree is purely your anonymity set |
| 00:00:25 | gmaxwell: | yes |
| 00:00:39 | gmaxwell: | 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 | petertodd: | jtimon: it's only scalable if you can figure out the right mining incentives and solve the data-hiding attack sufficiently |
| 00:01:24 | gmaxwell: | 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 | gmaxwell: | 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 | jtimon: | 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 | petertodd: | jtimon: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html |
| 00:05:07 | petertodd: | 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 | maaku: | petertodd: that doesn't have generic-coloring stuff you were just talking about right? |
| 00:05:31 | petertodd: | 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 | petertodd: | maaku: not explicitly, but the basic ideas in that paper can be applied to such schemes |
| 00:06:06 | maaku: | petertodd: is this accurate to what you are talking about: |
| 00:06:23 | maaku: | 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 | jtimon: | petertodd: in that thread you only had commited utxi, not utxo |
| 00:06:31 | petertodd: | maaku: yup |
| 00:06:42 | petertodd: | jtimon: right, but the logic applies equally to utxo too |
| 00:06:58 | maaku: | you'd need a much more powerful script language to do interesting things with that |
| 00:07:06 | maaku: | but you certainly could do interesting things |
| 00:07:20 | petertodd: | maaku: heh, I'll say... such scriptPubKey's are quine's after all! |
| 00:07:35 | jtimon: | I'm sorry guys, I'm not sure I follow |
| 00:07:49 | gmaxwell: | petertodd: the coloring constraint can even validate a issuing authority signature, to make sure the the initial attachment was permitted. |
| 00:07:52 | maaku: | jtimon: http://en.wikipedia.org/wiki/Quine_%28computing%29 |
| 00:07:58 | jtimon: | but what I meant by making the utxi scalable through expriries |
| 00:07:59 | gmaxwell: | So you can't just go affixing it ot new random coins. |
| 00:08:04 | petertodd: | 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 | petertodd: | gmaxwell: yup, or make it part of the program operating "if prev txout == magic return true" |
| 00:09:00 | gmaxwell: | petertodd: and to avoid the awful outcomes in my covenant thread... you make sure the color virus has a kill switch. |
| 00:09:03 | jtimon: | 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 | gmaxwell: | e.g. a way to spend it to tell it to not attach to the output. |
| 00:09:36 | maaku: | 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 | maaku: | it's a bit of complexity, but probably worth it |
| 00:10:11 | petertodd: | 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:11:04 | petertodd: | maaku: I gotta read the freimarkets spec... |
| 00:11:24 | jtimon: | nobody forces them, is just the best they can do, not sure I understand the second question... |
| 00:12:19 | gmaxwell: | http://www.itbusiness.ca/news/royal-canadian-mint-readies-its-version-of-bitcoin-mintchip/46113 mintchip is moving forward? heck yea. |
| 00:12:23 | maaku: | 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 | petertodd: | 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 | maaku: | petertodd: it may be sufficient reason to revamp script entirely |
| 00:13:14 | petertodd: | gmaxwell: I'll be interested to see if that alleged privacy leak is still in the spec... |
| 00:13:28 | maaku: | (we mostly dropped it because doing introspection was a kludge without LISP-like semantics) |
| 00:13:37 | petertodd: | maaku: it's a pretty useful feature IMO - I first thought of it for fidelity-bonded bank stuff |
| 00:13:50 | petertodd: | maaku: I suspect you can do it reasonably nicely with real forth semantics |
| 00:14:22 | gmaxwell: | petertodd: man, I wish I'd thought to ask them to be able to do something to do trustfree binding with bitcoin. |
| 00:14:48 | petertodd: | gmaxwell: if it was possible by accident they probably would have changed it to prevent it... |
| 00:15:31 | gmaxwell: | petertodd: e.g. just a "I've been paid!" message signed by your chip is enough. |
| 00:16:19 | petertodd: | gmaxwell: sure, although good luck on it being crypto-compat with bitcoin |
| 00:16:27 | maaku: | has anyone looked at hard-fork scripting improvements? other than Merklized scripts |
| 00:16:43 | petertodd: | maaku: I'm not sure there are any scripting improvements that actually need a hard fork you know... |
| 00:16:44 | gmaxwell: | Merklized scripts don't have to be a hardfork improvement. |
| 00:16:53 | gmaxwell: | You just P2SH deploy the update. |
| 00:17:05 | jtimon: | petertodd: does this require any snark-like tech? maaku: what are the differences from "regular stateless validation" |
| 00:17:07 | jtimon: | ? |
| 00:17:26 | petertodd: | jtimon: not at all |
| 00:17:28 | maaku: | jtimon: i think petertodd is explaining stateless validation |
| 00:17:34 | petertodd: | maaku: yup |
| 00:18:15 | gmaxwell: | maaku: things I want merklized scripts, restore missing opcodes, extra checksig flexibility, true scalable threshold signatures (e.g. schnorr). |
| 00:19:11 | petertodd: | "Money instantly moves from one cloud-based, MintChip account to another" <- it's cloud-based now? hmm... |
| 00:19:15 | jtimon: | 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 | gmaxwell: | 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 | petertodd: | jtimon: it's got nothing to do with either |
| 00:19:57 | gmaxwell: | petertodd: oh dear, did they make it suck? |
| 00:20:15 | petertodd: | gmaxwell: wouldn't surprise me... they probably noticed phones don't have card-readers |
| 00:20:44 | petertodd: | gmaxwell: and if they made it suck, they probably also made it possible to reverse tx's due to hacks... |
| 00:20:53 | gmaxwell: | damnit |
| 00:20:59 | jtimon: | can't you put an NFC card near a phone? |
| 00:21:16 | petertodd: | jtimon: that's harder than making it suck |
| 00:21:33 | gmaxwell: | I hope they didn't make it suck. |
| 00:21:35 | petertodd: | jtimon: and seriously, even that is susceptable to hacks - you really need a NFC card with a LCD display |
| 00:21:42 | gmaxwell: | Even without trustless binding it was going to be awesome for bitcoin. |
| 00:22:06 | maaku: | 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 | jtimon: | yeah, I guess you need a lcd and a couple of buttons in the card |
| 00:22:31 | maaku: | i'd love both lamport signatures and ed25519-derived schnorr signatures (if that is possible) |
| 00:22:37 | petertodd: | 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 | maaku: | using the sighash byte to keep compatability |
| 00:22:55 | gmaxwell: | I am less enamored with ed25519 than I was. I like our curve better now. :P |
| 00:23:06 | maaku: | why? |
| 00:23:10 | gmaxwell: | maaku: just have a second checksig operator. |
| 00:24:38 | gmaxwell: | 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 | gmaxwell: | I believe our curve also has higher security against all known attacks, outside of implementation mistakes, not that it matters much. |
| 00:25:38 | maaku: | but it is faster & resistant to timing attacks, isn't that pretty significant? |
| 00:26:11 | gmaxwell: | 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 | gmaxwell: | To make it constant time (and faster) they require the most siginficant bit of the private key be 1. |
| 00:26:45 | maaku: | 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 | gmaxwell: | which means that you can't have a 'randomly' generated private key, e.g. from a public derrivation. |
| 00:27:20 | gmaxwell: | 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 | maaku: | sorry confusing pronoun dereferencing : ed25519 is resistant to timing attacks and secp256k1 is not, right? |
| 00:27:33 | gmaxwell: | and the speed difference isn't so huge. |
| 00:27:45 | maaku: | hrm. ok |
| 00:29:03 | maaku: | i see, so it'd be quite a bit of work for little payoff |
| 00:29:05 | gmaxwell: | 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 | maaku: | which kills bip32, i understand now |
| 00:29:43 | petertodd: | so why does that kill bip32? |
| 00:29:54 | gmaxwell: | 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 | gmaxwell: | petertodd: it kills type-2 derrivation since you can't tell if the private key will have the MSB set. |
| 00:30:31 | gmaxwell: | 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:31:07 | gmaxwell: | 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 | petertodd: | 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 | gmaxwell: | And they're planning on doing this with the ed25519 curve. |
| 00:31:32 | gmaxwell: | And I don't think they've yet realized that they won't be able to use the standard implementation… |
| 00:31:48 | jtimon: | 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 | gmaxwell: | (I only realized this because I went and tried to implement ed25519 for bitcoin) |
| 00:32:20 | gmaxwell: | petertodd: BIP32 perhaps, but not the privacy purposes of it. |
| 00:32:24 | gmaxwell: | Or stealth addresses. |
| 00:32:29 | gmaxwell: | Which is basically the same usecase tor has. |
| 00:32:53 | petertodd: | gmaxwell: yup, although OTOH a merkle tree would do it, at the cost of size |
| 00:32:53 | gmaxwell: | (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 | gmaxwell: | petertodd: not for privacy, I could see your hashroot was the same. :P |
| 00:33:23 | petertodd: | jtimon: it makes sense |
| 00:34:25 | petertodd: | 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 | jtimon: | 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 | petertodd: | 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 | petertodd: | jtimon: your proof that your ccoin is valid just needs to be that the signature on the genesis txout was valid |
| 00:36:26 | maaku: | 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 | gmaxwell: | 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 | petertodd: | gmaxwell: yes! not that I ever said it was a good idea :P |
| 00:37:17 | gmaxwell: | petertodd: dear god, that idea ... so bad. ... must stab |
| 00:37:19 | jtimon: | petertodd, flavien is talking about "inflatable colored coins" in which the same address can be used to just issue more |
| 00:37:21 | maaku: | If you assume your RNG is good or use deterministic signatures, key reuse is not a problem (from that perspective only) |
| 00:37:29 | petertodd: | gmaxwell: pity you can't stab someone over the internet |
| 00:37:56 | jtimon: | so maaku says flavien is right... |
| 00:37:57 | gmaxwell: | I'm pretty sure there is an onion site for that. |
| 00:37:58 | petertodd: | jtimon: yes, which is a dumb idea, just use the signature to sign a message saying some arbitrary txout is colored |
| 00:38:06 | maaku: | but you still wouldn't want to tie it to an unchanging address anyway, for a multitude of other reasons |
| 00:38:45 | maaku: | 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 | maaku: | (assuming perfect RNG or deterministic signatures) |
| 00:39:06 | gmaxwell: | 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 | maaku: | but those are invalid assumptions for real-world cryptography |
| 00:39:36 | petertodd: | gmaxwell: of course, which is why I expected the idea to raise your blood pressure :P |
| 00:40:08 | petertodd: | * petertodd has been paid off by the NSA to kill gmaxwell via heart disease |
| 00:40:30 | maaku: | 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 | jtimon: | 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:28 | maaku: | 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 | maaku: | which would protect you against spinning up two separate servers, who each sign separate messages with the same K value |
| 00:47:39 | warren: | petertodd: I knew it! |
| 00:47:44 | maaku: | (due to saved random state in the VM image and a lack of entropy) |
| 00:47:51 | justanotheruser: | Is bitmessage off topic here? |
| 00:48:06 | maaku: | justanotheruser: so long as it involves arcane spell |
| 00:48:08 | maaku: | s |
| 00:48:21 | justanotheruser: | ? |
| 00:48:25 | jtimon: | 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 | maaku: | 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 | jtimon: | tokens allow you to change the p2sh one addres doesnt |
| 00:50:10 | maaku: | although if you had bip-32 in script... |
| 00:50:19 | maaku: | yes |
| 00:50:45 | maaku: | if you could do bip-32 derivation in script though, you could get by with a single address |
| 00:51:07 | justanotheruser: | Anyways, how well does bitmessage scale? Would it work with 10 million users? |
| 00:51:21 | jtimon: | not if you want to radically change the config |
| 00:51:45 | maaku: | yeah |
| 00:52:13 | gmaxwell: | justanotheruser: scaling is largely in terms of the anonymity set size. |
| 00:53:01 | gmaxwell: | 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 | justanotheruser: | Nice use of parenthesis there. How is scaling in terms of the anonymity set size? Will the network break into sections or something? |
| 00:54:45 | gmaxwell: | 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 | petertodd: | ...which is basically what sane people propose for consensu blockchains in general. |
| 00:55:38 | justanotheruser: | I see. And there is no in depth explanation for their streams? |
| 00:55:43 | petertodd: | 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 | petertodd: | justanotheruser: not that I've seen |
| 00:56:15 | gmaxwell: | there is a stream setting on addresses, so the stream stuff is implemented but no 'fee intelligence' if you will. |
| 00:56:36 | petertodd: | justanotheruser: you can also do steams based on sharding H(addr) space (roughly speaking) |
| 00:56:53 | gmaxwell: | 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 | gmaxwell: | so, duh, yea, of course I'm going to pick stream 0. |
| 00:57:14 | gmaxwell: | let you suckers pay the cost of messaging me. |
| 00:57:32 | petertodd: | 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 | justanotheruser: | Well there is an incentive to have someone message you right? |
| 00:57:54 | justanotheruser: | I mean to send a message |
| 00:58:15 | justanotheruser: | So if you don't agree on the stream then it wouldn't be sent |
| 00:58:23 | petertodd: | justanotheruser: yup, and stream would be part of addr |
| 00:58:24 | gmaxwell: | 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 | gmaxwell: | I think the incentive issue is probably not fatal, as justanotheruser says— people want to recieve messages. |
| 00:58:49 | gmaxwell: | But it is interesting. |
| 00:59:21 | petertodd: | 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 | petertodd: | gmaxwell: limit bandwidth based competition for a given prefix specificity |
| 01:00:33 | petertodd: | gmaxwell: hilariously, that matches really well to what PoW algorithms actually do... but in the exact wrong way |
| 01:01:12 | justanotheruser: | How does the reduced anonymity effect the anonymity of coinjoins? Does it even matter? |
| 01:01:48 | petertodd: | justanotheruser: depends on how anonymous you want to be... |
| 01:01:59 | gmaxwell: | I don't know that it even matters. ... though I assume anyone would use bitmessage over tor. |
| 01:03:27 | petertodd: | 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 | gmaxwell: | petertodd: there are no more sutiable traffic analysis resistant privacy networks. |
| 01:04:07 | justanotheruser: | petertodd: Why not? I would think it is great, it just needs a layer on top of it to handle it |
| 01:04:10 | petertodd: | justanotheruser: needing a PoW to send a message is ugly vs. using fees for it |
| 01:04:27 | petertodd: | justanotheruser: and you can use fees to pay for it with the nLockTime trick |
| 01:05:17 | justanotheruser: | petertodd: I think gmaxwells idea of using PoS is better. |
| 01:05:48 | justanotheruser: | People don't really want to pay double fees, one for the message and one for the coinjoin. |
| 01:06:14 | petertodd: | 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 | petertodd: | 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 | justanotheruser: | petertodd: how would you determine the coinjoin tx without being able to communicate with the network first? |
| 01:07:17 | petertodd: | justanotheruser: your communication includes that nLockTime'd tx - that's how you pay for it |
| 01:07:54 | justanotheruser: | 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 | petertodd: | justanotheruser: which you have to anyway - tx's aren't free |
| 01:08:22 | justanotheruser: | petertodd: yes, but with PoS you only have to pay one |
| 01:09:02 | petertodd: | justanotheruser: no, it's identical to pos, except that you ensure something of value is actually lost |
| 01:09:34 | petertodd: | 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 | justanotheruser: | petertodd: When you have stake that means you payed a fee to get the coins. That is what you lost. |
| 01:12:18 | petertodd: | 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 | justanotheruser: | except for cases where millionaires don't pay fees, but there aren't enough of those to worry about |
| 01:13:15 | justanotheruser: | 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 | justanotheruser: | s/use a certain amount of it/use it to a certain extent. |
| 01:15:21 | 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:16:13 | justanotheruser: | gmaxwell: does pinnochio take care of petertodds concern? |
| 01:17:46 | justanotheruser: | petertodd: Wouldn't proof of burn also remove anonymity in the same way? |
| 01:18:39 | petertodd: | 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 | justanotheruser: | 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 | justanotheruser: | It's a pretty big research paper |
| 01:22:15 | gmaxwell: | what concern? |
| 01:22:16 | justanotheruser: | And I have to look stuff up every page |
| 01:22:22 | gmaxwell: | you guys said a bunch of stuff |
| 01:22:35 | justanotheruser: | 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 | petertodd: | justanotheruser: pinnochio is orthogonal to the choice between proof-of-stake and proof-of-sacrifice |
| 01:23:15 | justanotheruser: | petertodd: then your comment was irrelevant to the discussion of which was the better method |
| 01:23:27 | gmaxwell: | what pinnochio lets you do is make compact blind proofs from something where you have efficiently extractable authenticated data. |
| 01:23:29 | justanotheruser: | because they both have that glaw |
| 01:24:03 | petertodd: | 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 | gmaxwell: | 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 | petertodd: | 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 | gmaxwell: | 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 | petertodd: | 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 | petertodd: | gmaxwell: it's doable, but potentially ugly long-term if people really want to attack it |
| 01:25:54 | gmaxwell: | yea, you'd then use a hashtable that you keep for $time_interval |
| 01:26:13 | petertodd: | 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 | petertodd: | gmaxwell: at least proof of burn ensures they'll spend fees doing so |
| 01:26:32 | gmaxwell: | petertodd: well of course the proof can emerge a bound on its value. |
| 01:26:47 | justanotheruser: | couldn't your "proof of time" be the hash of your proof plus the unix time being below a certain value? |
| 01:26:58 | gmaxwell: | proof of burn can't be done non-interactively in zero knoweldge. |
| 01:27:43 | gmaxwell: | PoS and PoS can be. |
| 01:27:51 | petertodd: | 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 | gmaxwell: | for coinjoin PoB is pretty great, I agree. |
| 01:28:19 | gmaxwell: | since coinjoin inherently must expose a txout. |
| 01:28:35 | petertodd: | yeah, and for everything else, proof-of-prior sacrifice *with* some kind of domain-specific tag is pretty decent |
| 01:28:38 | gmaxwell: | for something like a replacement for BitMessage's pow I prefer PoS or PoS. |
| 01:28:57 | sipa: | gmaxwell: PoS and PoS (i do keep reading that as piece of s**t...) |
| 01:29:27 | gmaxwell: | Proof of Stake or Proof of sacrifice. |
| 01:29:38 | petertodd: | sipa: PoS and PoX I prefer myself |
| 01:29:47 | justanotheruser: | gmaxwell: should their stake expire after a certain number of blocks? Otherwise they can use the network at no cost |
| 01:30:07 | gmaxwell: | justanotheruser: you'd prove that you had stake as of some reference time that moves periodically. |
| 01:30:17 | gmaxwell: | e.g. first block after midnight utc every day. |
| 01:30:29 | petertodd: | justanotheruser: funny how you actually want the inverse of coinage in this case |
| 01:30:39 | justanotheruser: | petertodd: yes, coin/days |
| 01:30:50 | gmaxwell: | 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 | gmaxwell: | 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 | gmaxwell: | likewise for proof of sacrifice, except you just extract sacrifice like transactions. |
| 01:32:16 | petertodd: | 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 | gmaxwell: | 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 | petertodd: | gmaxwell: well, that case you'll have all that data in your wallet actually |
| 01:33:58 | gmaxwell: | 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 | petertodd: | yup |
| 01:34:19 | gmaxwell: | but if you extract the data directly you can reorder how its stored. |
| 01:34:35 | justanotheruser: | How big is the proof of stake using pinnochio? |
| 01:34:43 | gmaxwell: | 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 | gmaxwell: | 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 | justanotheruser: | That's not bad |
| 01:39:03 | justanotheruser: | gmaxwell: Why is a proof of SHA256 so big? |
| 01:41:18 | maaku: | justanotheruser: SHA256 is a non-trivial function? |
| 01:41:33 | justanotheruser: | maaku: So ECDSA isn't? |
| 01:42:03 | maaku: | that's an apples-to-hot-wheels-cars comparison |
| 01:42:24 | midnightmagic: | 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 | petertodd: | justanotheruser: you don't need to prove ECDSA in this case |
| 01:42:37 | midnightmagic: | gmaxwell: I have one more place where I can look. Would you like me to check? |
| 01:43:06 | gmaxwell: | Because ECDSA is special in that it naturally yields compact proofs of knoweldge. There are very few things that do this. |
| 01:43:15 | gmaxwell: | midnightmagic: not that urgent I have it at home someplace. |
| 01:43:20 | petertodd: | gmaxwell: how does that work? |
| 01:43:32 | midnightmagic: | ok |
| 01:43:45 | roidster: | roidster is now known as Guest82569 |
| 01:44:07 | midnightmagic: | gmaxwell: If it's cleanly possible to get a copy of that I would sure love one. :-D |
| 01:44:09 | gmaxwell: | petertodd: an ECDSA signature is a proof you know the discrete log of the public key value. |
| 01:44:43 | petertodd: | gmaxwell: ah, and these schemes can do that directly? |
| 01:45:15 | gmaxwell: | petertodd: no no. Perhaps we're miscommunicating. |
| 01:45:34 | gmaxwell: | I thought justanotheruser was asking why the pinnochio proofs were much bigger than an ECDSA signature. |
| 01:46:02 | petertodd: | gmaxwell: right, I took it as asking why you couldn't feasible make a pinnochio proof of a ECDSA sig |
| 01:46:07 | sipa: | ECDSA is basically a scheme designed for creating a compact proof... for a very specific operation |
| 01:46:48 | gmaxwell: | 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 | petertodd: | gmaxwell: right, and the proving would be some crazy thing that basically implements ECDSA with some circuit |
| 01:47:40 | gmaxwell: | right, with an arithemetic circuit over some finite field. |
| 01:48:10 | gmaxwell: | (or some boolean circuit, though usually arithemetic circuits are more compact, e.g. they make sha256 quite compact) |
| 01:56:48 | petertodd: | so the pinnochio source code is available, but I don't see any license anywhere |
| 01:57:19 | petertodd: | oh wait, I found it, Microsoft non-commercial, not too useful |
| 02:12:37 | gmaxwell: | 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 | gmaxwell: | 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 | adam3us: | about coloring in the context of zerocash, i think they could include another value in the hash, being the color |
| 02:17:50 | adam3us: | 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 | gmaxwell: | 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 | adam3us: | gmaxwell: kind of annoyed at DJB now that is an unclean hack disguised as a feature. it fails composability |
| 02:23:54 | gmaxwell: | adam3us: well, I was made kind of annoyed by the "Safe or Not" summary table most recently added to safercurves |
| 02:24:09 | gmaxwell: | which has now three times caused me to get questions with urgent concerns that bitcoin's curve is not safe. |
| 02:25:41 | adam3us: | 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 | adam3us: | gmaxwell: as there is a guy moving pretty fast on getting an RFC through standardizing the safe curves |
| 02:26:22 | gmaxwell: | 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:30:35 | CodeShark: | "safe or not" is pretty stupid when it comes to proclamations of security completely devoid of context |
| 02:31:50 | maaku: | 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 | sipa: | what is considered unsafe about secp256k1? |
| 02:35:28 | gmaxwell: | http://safecurves.cr.yp.to/ |
| 02:35:32 | gmaxwell: | scroll down |
| 02:35:48 | gmaxwell: | it's "not safe" if it doesn't meet all of DJB's criteria. |
| 02:36:07 | gmaxwell: | the criteria are all interesting. Few of them would justify not-safe for failing them |
| 02:37:13 | gmaxwell: | esp since the critiera omits other no less reasonable considerations like "cofactor == 1", presumably since his own curves fail it. |
| 02:37:38 | maaku: | chiefly, the fact that it doesn't have "25519" in its name |
| 02:41:06 | gmaxwell: | 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) |
| 03:28:14 | andytoshi: | wizards, i am enrolled in a "numerical iterative methods" class which is very open ended |
| 03:28:34 | andytoshi: | can you think of any interesting (or useful to bitcoin) numerical analysis projcets? |
| 03:35:47 | gmaxwell: | andytoshi: network simulations can fall in that bucket. |
| 03:36:38 | gmaxwell: | andytoshi: if you wanted to fool with an altcoiny thing, control loops for difficulty adjustment. What else? Hm. anti-spam/dos attack hurestics perhaps. |
| 05:22:53 | phantomcircuit: | gmaxwell, just take your entire hardfork list and implemetn them |
| 06:12:34 | justanotheruser1: | Is there an alternative to pandora that has a GP or BSD license? |
| 06:12:58 | justanotheruser1: | * Pinocchio |
| 06:14:01 | justanotheruser1: | justanotheruser1 is now known as justanotheruser |
| 07:03:05 | maaku: | maaku is now known as Guest13248 |
| 08:26:19 | Guest13248: | Guest13248 is now known as maaku |
| 09:12:23 | adam3us: | andytoshi: numerical iterative analysis? perfect one for you: selfish attack? |
| 09:47:21 | TD[gone]: | TD[gone] is now known as TD |
| 09:51:25 | adam3us: | 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. |
| 12:18:28 | andytoshi: | 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 | andytoshi: | 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 | andytoshi: | 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.. |
| 13:28:12 | adam3us: | 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: | adam3us: none of those will necessarily be the case after public HD derivation |
| 13:29:53 | adam3us: | adam3us: andytoshi: a[255]=0 maybe ok, as |n| < 255 (the order) i presume from the h=8 (cofactor) |
| 13:36:13 | andytoshi: | 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 | andytoshi: | 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 | andytoshi: | this seems weird, i dunno why the reference implementation didn't just hardcode the 254 in there |
| 13:38:39 | andytoshi: | 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 | adam3us: | andytoshi: 256-bits (0..255) probably just for power 2 & word size divisibility. not necessary he says you can reuse the bit in bit-stealing if u want. |
| 13:39:22 | andytoshi: | oh, good to know |
| 13:42:27 | adam3us: | andytoshi: so the thing with the co-factor is there is think a small subgroup also as n=h*l (l subgroup size, h cofactor, no points on curve), so trailing 000 is actually computing d=rand(0,l), Q=dG, Q'=8Q i think to avoid the small subgroup, |
| 13:44:50 | adam3us: | andytoshi: (ie the useful private key is 251 bits, and presumably |l|=251) but still u stay in the subgroup once u start there, so Q"=Q'+MAC(chain,ctr)G is still in the subgroup (hopefully!) |
| 13:45:37 | adam3us: | andytoshi: actuall i guess |l|=252, the top-bit is not "useful" as its fixed but its still part of the private key |
| 13:47:45 | andytoshi: | adam3us: understood, though i suppose i don't understand why this subgroup is so bad that we actually need to zero it out |
| 13:47:54 | andytoshi: | i guess fixing a representative of the coset is needed for determinism |
| 13:48:05 | adam3us: | andytoshi: actually take that back |l|=253, paper: l is the prime 2^252+2... |
| 13:50:16 | adam3us: | andytoshi: maybe its fixable. its just an obtuse way of saying d=rand(0,l-1) Q=8dG right? |
| 13:50:49 | adam3us: | andytoshi: so do the *8 part after HD derivation |
| 13:51:03 | andytoshi: | that's my understanding, and also i think it's just obtuse so that he can hold bit 254 fixed |
| 13:54:13 | andytoshi: | adam3us: at first glance, doing *8 after derivation would make HD work, i don't think the cofactor is a problem for us (though it weakens security by those 3 bits, and gmaxwell is pissed that djb considers this "better" than the ~1.5 bits our curve loses by fast parameter choices) |
| 13:54:35 | andytoshi: | but i don't see how we can hold bit 254 on |
| 13:54:54 | andytoshi: | though i guess we could grind through HD keys until we get one with bit 254 set :} |
| 13:56:05 | andytoshi: | (kidding!) anyway i've gotta run, good talking to you |
| 13:58:57 | adam3us: | andytoshi: Bernstein et al's style is obtuse in general :( cleary if ou do Q=dG (d chosen rand(0,l-1)) then you do HD derivation Q"=Q+M(c,i)G, and finally Q"=8Q' then there is no guarantee that top bit is 1 as its mod l, but we dont care about that anyway |
| 13:59:35 | adam3us: | andytoshi: well with public derivation u have no way to know what the top bit of the private key is. |
| 17:39:43 | maaku: | farewell net netrality, we hardly knew ye |
| 17:41:25 | nsh: | :/ |
| 18:05:12 | gmaxwell: | maaku: you don't have any great ideas on how to prevent incentive buggary with expensive validation do you? |
| 18:10:05 | gmaxwell: | andytoshi: you called it correctly on my complaints. WRT cofactor there are two complaints, one it that there is the direct rho security reduction from the decrease in the order, compariable in magnitude to the rho reduction he dings secp256k1 on. The other is that having a non-trivial cofactor is a necessary precondition for index calculus, though just a single extra distinct prime factor is probably no concern, all thing equal we ... |
| 18:10:11 | gmaxwell: | ... should prefer thing with a cofactor of 1. |
| 18:26:51 | adam3us: | gmaxwell: so do u know does the trailing 000 bits of d matter? that also will be lost by HD derivation |
| 18:28:22 | pigeons: | andytoshi: is there an irc channel or bitmessage broadcast address or something anouncing pending coinjoin sessions? |
| 18:29:51 | _ingsoc_: | _ingsoc_ is now known as _ingsoc |
| 18:32:07 | TD: | TD is now known as TD[gone] |
| 18:32:38 | gmaxwell: | adam3us: so long as you compute the derivation the right way you can preserve it. Basically the scalar you compute in it has to also be a multiple of 8. |
| 18:33:22 | gmaxwell: | adam3us: because the order is prime*8 the sum of any two numbers which are themselves a multiple of 8 will still be a multiple of 8, thats what results in it being a subgroup. |
| 18:33:52 | andytoshi: | pigeons: no, not yet, i have just released a client and having trouble finding testers during my free moments |
| 18:34:26 | andytoshi: | i'll check out bitmessage tho, that'd be fun to set up |
| 18:35:16 | adam3us: | gmaxwell: but if you are working in the subgroup, the scalars are then mod l not mod n=8l? or is B a generator of the full group? |
| 18:36:58 | gmaxwell: | oh darn. hm. I think you're right. obviously the basepoint isn't going to generate the full group. |
| 18:37:17 | gmaxwell: | then I don't understand anymore why the private key is constrained. |
| 18:38:23 | adam3us: | gmaxwell: well a base point could be generator of the full group, i think (if they chose it that way?); and that may explain the 8s that appear in the verification relationship perhaps. |
| 18:54:20 | maaku: | gmaxwell: what's the context of "expensive validation" - my script musing on #bitcoin-dev? |
| 18:54:35 | gmaxwell: | maaku: yea |
| 18:55:49 | maaku: | well in some of the applications i'm imagining it could be more efficient to validate a message signature than a transaction |
| 18:56:53 | maaku: | so, you could sign the transaction itself as a message, efficiently proving you have the inputs, and then get gray-listed if the actual validation fails |
| 18:57:51 | maaku: | e.g. the script is "if real-transaction then endif " |
| 18:58:13 | maaku: | i would like a better method though |
| 19:00:31 | maaku: | you could require something like the above if the (explicit) instruction count is greater than some normal-use threshold |
| 19:02:03 | maaku: | pigeons: ;;cjs |
| 19:02:09 | maaku: | ;;cjs |
| 19:02:10 | gribble: | Coinjoin Status: There is no currently open session. Visit https://www.wpsoftware.net/coinjoin/ or http://xnpjsvp7crbzlj3w.onion/ to start one. |
| 19:02:34 | maaku: | andytoshi: but it'd be nice if there was an announcement when a new session started |
| 19:05:19 | adam3us: | gmaxwell: so i was musing an analogous argument to pegged side-chain security (cant inflate supply of main chain) could be used to introduce SNARKs + committed-tx or some variant of it in a zero-coin like zerotrust mixer on the main chain |
| 19:06:09 | michagogo|cloud: | Anyone have a link to andytoshi's cj client? |
| 19:06:12 | adam3us: | gmaxwell: or perhaps more simply, just make a zerocash snark as a reference example of a pegged-side chain (though i note even green put a disclaimer in his talk that this is a bit bleeding edge and could have problems) |
| 19:06:37 | EasyAt: | maaku: Couldn't I send a bogus TX that has a ton of operations to verify to chew through processing power? |
| 19:07:58 | adam3us: | gmaxwell: which seems kind of ironic (proposing to integrate zerocash in the pattern in which zeroin was proposed), now that zerocash is proposed as an alt. (and I and Hal were more excited about moving zerocoin into its own alt) |
| 19:08:12 | EasyAt: | You would have to do a ton of ops before you realize the TX isn't valid |
| 19:09:15 | maaku: | EasyAt: yes, which is why as I said above you might require that the owner provide a quick-verifying signature over the transaction of the expensive inputs |
| 19:09:23 | maaku: | so you know the transaction came from him |
| 19:09:26 | adam3us: | anyone how big is the UTXO set if compacted now? |
| 19:09:33 | maaku: | and then gray-list the inputs if the validation fails |
| 19:09:42 | maaku: | adam3us: gettxsetinfo or something similar |
| 19:10:21 | maaku: | EasyAt: then it at least becomes expensive to perform DoS |
| 19:10:42 | andytoshi-logbot: | * andytoshi-logbot is logging |
| 19:12:15 | michagogo|cloud: | Oh, are the logs not live? |
| 19:12:20 | EasyAt: | maaku: What do you mean by gray list? |
| 19:12:34 | maaku: | e.g. only pay attention to transactions with inputs that have less than 20 instructions, *or* transactions enveloped with a less-than-20-ops signature for the expensive inputs |
| 19:13:18 | maaku: | gray list would be a list of inputs you no longer relay transactions for, maybe for a period of time or require higher fees |
| 19:14:38 | andytoshi: | michagogo|cloud: source is at https://github.com/apoelstra/cj-client |
| 19:14:58 | andytoshi: | michagogo|cloud: windows build at http://download.wpsoftware.net/bitcoin/cj-windows.zip |
| 19:15:15 | michagogo|cloud: | thanks |
| 19:15:24 | gmaxwell: | andytoshi: about 300 mbytes. |
| 19:15:26 | gmaxwell: | oops |
| 19:15:28 | gmaxwell: | adam3us: |
| 19:15:44 | michagogo|cloud: | "cj-windows.zip is not commonly downloaded and could be dangerous." |
| 19:15:44 | andytoshi: | gmaxwell: !!!! ;) |
| 19:15:57 | gmaxwell: | bitcoind gettxoutsetinfo |
| 19:15:57 | gmaxwell: | { "height" : 280494, "bestblock" : "00000000000000024c41edbc27cb0d093b593a47030b886fade01f9d19b8047a", "transactions" : 2597060, "txouts" : 8350183, "bytes_serialized" : 293414423, "hash_serialized" : "ca53e5d3a59fc7a3dca134cce6942c2af5d85c2ce21d985c8b06526e795faf74", "total_amount" : 12262214.79395749 |
| 19:16:02 | gmaxwell: | } |
| 19:16:07 | andytoshi: | michagogo|cloud: populism is not security, your browser uses faulty assumptions |
| 19:16:13 | michagogo|cloud: | andytoshi: I know |
| 19:16:22 | michagogo|cloud: | I wasn't ascribing any meaning to that thing |
| 19:16:31 | michagogo|cloud: | Just wanted to let you know Chrome was flagging it |
| 19:16:43 | gmaxwell: | what a shitty thing |
| 19:16:44 | andytoshi: | ok, good to know |
| 19:16:51 | andytoshi: | chrome should really be flagging windows.. |
| 19:16:53 | gmaxwell: | I bet if you throw the same binary on github you get no warning. |
| 19:17:05 | michagogo|cloud: | btw, I assume it uses RPC? |
| 19:17:07 | michagogo|cloud: | Which calls? |
| 19:17:17 | michagogo|cloud: | (i.e. can it work on 0.8.6?) |
| 19:17:34 | andytoshi: | michagogo|cloud: listunspent, createrawtransaction, decoderawtransaction, signrawtransaction, getaddress, walletpassphrase |
| 19:17:44 | andytoshi: | i think those are fine |
| 19:18:02 | gmaxwell: | also gettxout |
| 19:18:05 | andytoshi: | oh, gettxout, dumpprivkey |
| 19:18:28 | gmaxwell: | you might want to use getrawchangeaddress but I think its git-only. |
| 19:18:51 | gmaxwell: | perhaps try getrawchangeaddress and if it isn't there, use getnewaddress? |
| 19:18:59 | michagogo|cloud: | In about 7 minutes when my 0.8.6-compatible blocks and chainstate finish copying over I'll see |
| 19:19:06 | andytoshi: | gmaxwell: what is the difference? |
| 19:19:41 | gmaxwell: | andytoshi: change addresses get hidden in the transaction list. But perhaps not. actually nevermind that if you do that people will spazz. |
| 19:20:24 | gmaxwell: | though .. actually you really should have a feature to let the user specify recipent addresses for the CJ outputs. (Personally I send my CJ outputs to offline wallets!) |
| 19:21:21 | andytoshi: | gmaxwell: agreed, my original UI sketch had such a thing |
| 19:21:28 | andytoshi: | but it's hard to design a UI for that non-intrusively |
| 19:21:43 | michagogo|cloud: | andytoshi: Hm, it doesn't seem to be launching |
| 19:22:00 | michagogo|cloud: | The process is ther, but just sitting at 164K of memory |
| 19:22:03 | michagogo|cloud: | there* |
| 19:22:05 | andytoshi: | michagogo|cloud: any output? |
| 19:22:08 | michagogo|cloud: | and not visibly opening anything |
| 19:22:29 | andytoshi: | my guess is that it's stalled pinging my server.. |
| 19:22:32 | michagogo|cloud: | Oh, that's why |
| 19:22:42 | michagogo|cloud: | I don't know why it took so long to show up |
| 19:22:53 | michagogo|cloud: | "Our information on this file is inconclusive." |
| 19:22:56 | andytoshi: | oh, weird, it's quick for me (and i'm a good 2500km from the server) |
| 19:23:08 | michagogo|cloud: | "We recommend not using this file unless you know it is safe." |
| 19:23:13 | gmaxwell: | well it does connect to the remote server at startup. |
| 19:23:15 | andytoshi: | oh fuck windows |
| 19:23:19 | michagogo|cloud: | andytoshi: Nah |
| 19:23:27 | michagogo|cloud: | Not Windows, security software |
| 19:26:27 | adam3us: | gmaxwell: so that is 275MB vs 13GB for utxo vs txo about 2% |
| 19:27:23 | gmaxwell: | more like vs 16G. |
| 19:28:00 | adam3us: | gmaxwell: oh i thought jgarzik said his torrent was 13G |
| 19:28:04 | gmaxwell: | adam3us: sipa did some charts a long time ago, utxo size looked to be ~log() the blockchain size. |
| 19:28:16 | gmaxwell: | the torrent doesn't take it up to tip. |
| 19:29:45 | adam3us: | gmaxwell: (sending email cc green re contact from the other crypto guy mentioned in PM, i thought I'd take the opp to correct his 16GB bitcoin vs 1.2GB zercocash claim;) |
| 19:36:59 | michagogo|cloud: | andytoshi: eww, always-on-top? |
| 19:37:58 | nsh: | you don't get anywhere in the dog-eat-dog world of windowing systems by ceding your platform |
| 19:39:29 | andytoshi: | michagogo|cloud: what is always on top? |
| 19:39:37 | michagogo|cloud: | The cj client |
| 19:39:47 | andytoshi: | really? |
| 19:39:54 | michagogo|cloud: | Yes. |
| 19:40:06 | maaku: | who doesn't like it on top |
| 19:40:22 | michagogo|cloud: | * michagogo|cloud |
| 19:40:30 | andytoshi: | oh, oops, i had gtk_window_set_keep_above () in there |
| 19:40:37 | andytoshi: | i didn't notice because i don't use a floating WM |
| 19:40:40 | gmaxwell: | * gmaxwell xmoand user unaffected |
| 19:40:53 | michagogo|cloud: | ;;google xmoand |
| 19:40:54 | gribble: | [Arena PvP] Xmo and Xtk 2v2 - Forst Mage/Mage pt 1 - YouTube: ; Xmo and Xtk TCB Double Frost Mage 2v2 Arena Part 1 - YouTube: ; Xmo and Xtk 2v2 Act II Double Frost Mage 2v2 Arena Part 1 - YouTube: |
| 19:41:07 | gmaxwell: | yea, srsly. y'all use a floating window manager? sucks to be you. |
| 19:41:08 | jtimon: | xmonad? |
| 19:41:09 | andytoshi: | ....and a thought gmaxwell had a floating WM :P |
| 19:41:11 | michagogo|cloud: | And |
| 19:41:27 | michagogo|cloud: | Ah* |
| 19:41:28 | andytoshi: | michagogo|cloud: thanks much for testing, you are the first person with a normal system to have done so |
| 19:41:28 | gmaxwell: | No, I use xmonad. |
| 19:41:30 | andytoshi: | i'll refresh the build |
| 19:42:03 | jtimon: | hehe, I tried some tiling VM but I left it due to a lack of time for config |
| 19:42:05 | gmaxwell: | (I was happy I didn't need to report problems with the tiling wm, I guess I know why now) |
| 19:42:15 | jtimon: | I will definetely try again though |
| 19:42:16 | gmaxwell: | jtimon: to configure xmonad is very simple. |
| 19:42:45 | gmaxwell: | You join #haskell and nice people do it for you. |
| 19:42:46 | jtimon: | I shouldn't had started with ratpoison, but the name was so cool |
| 19:42:47 | nsh: | senate judiciary hearing on NSA started 10m ago |
| 19:42:56 | michagogo|cloud: | andytoshi: Is there a way to cj on testnet? |
| 19:42:57 | nsh: | http://www.c-span.org/Live-Video/C-SPAN3/ http://www.judiciary.senate.gov/hearings/hearing.cfm?id=32caee8082f9297f0e7df6280b369172 |
| 19:42:59 | jtimon: | the two I used more were i3 and qtile |
| 19:43:13 | michagogo|cloud: | ;;tcjs |
| 19:43:13 | gribble: | Error: "tcjs" is not a valid command. |
| 19:43:19 | michagogo|cloud: | ;;cjst |
| 19:43:19 | gribble: | Error: "cjst" is not a valid command. |
| 19:43:22 | andytoshi: | michagogo|cloud: yeah, there is a cjconfig.conf file |
| 19:43:22 | nsh: | (Cass Sunstein currently summarizing review panel findings) |
| 19:43:33 | gmaxwell: | nsh: what did they find? |
| 19:43:35 | andytoshi: | in cjclient/, wherever Bitcoin/ is |
| 19:43:35 | michagogo|cloud: | andytoshi: What's the URL for the testnet page? |
| 19:43:54 | jtimon: | gmaxwell: hehe, I doubt the #python nice people will config qtile for me |
| 19:43:58 | andytoshi: | michagogo|cloud: oh, right, i forgot the server needed to support it |
| 19:44:01 | andytoshi: | one moment, i'll put it up.. |
| 19:44:13 | michagogo|cloud: | andytoshi: There doesn't seem to be a %appdata%/cjclient |
| 19:44:34 | gmaxwell: | "Classified. Classified, classified classified classified classified classified classified. Classified classified classified classified. Classified classified classified, classified classified classified classified; Classified. |
| 19:44:38 | gmaxwell: | " |
| 19:44:42 | jtimon: | funny video introducing qtile http://www.youtube.com/watch?v=r_8om4dsEmw |
| 19:44:53 | nsh: | gmaxwell, something like that aye |
| 19:45:01 | andytoshi: | michagogo|cloud: is it listing your coins correctly? |
| 19:45:18 | gmaxwell: | jtimon: this is why you have to use xmonad. The programmers in other languages have actual applications for their skills. Whereas with haskell the only thing they have to do is configure xmonad for people. |
| 19:45:32 | michagogo|cloud: | andytoshi: I don't have a mainnet client open yet |
| 19:45:43 | andytoshi: | oh, my cjclient/ dir is using c:/users/apoelstra/Local Settings/Application Data/cjclient |
| 19:45:43 | michagogo|cloud: | Ah, looks like the copy finished |
| 19:45:45 | michagogo|cloud: | one moment |
| 19:45:51 | andytoshi: | i don't think that Local Settings/ should be there |
| 19:45:53 | jtimon: | gmaxwell: loool |
| 19:45:58 | michagogo|cloud: | andytoshi: XP? |
| 19:46:03 | andytoshi: | michagogo|cloud: wine |
| 19:46:10 | michagogo|cloud: | WineXP? |
| 19:46:19 | andytoshi: | uh, i dunno |
| 19:46:20 | michagogo|cloud: | Or even earlier? |
| 19:46:27 | andytoshi: | yeah, winecfg says XP |
| 19:46:31 | michagogo|cloud: | I know Wine lets you choose which version of Windows to pretend to be |
| 19:46:43 | michagogo|cloud: | And I know that Application\ Data is pre-Vista |
| 19:47:19 | andytoshi: | ok, i'll figure out the glib function to get %APPDATA%.. |
| 19:47:24 | andytoshi: | bitcoin is in %APPDATA%/Bitcoin yes? |
| 19:47:29 | michagogo|cloud: | Indeed |
| 19:47:39 | michagogo|cloud: | (C:\Users\Micha\AppData\Roaming) |
| 19:49:37 | michagogo|cloud: | ;;blocks |
| 19:49:38 | gribble: | 280495 |
| 19:50:26 | michagogo|cloud: | andytoshi: oh, btw, it's not showing my coins |
| 19:50:38 | andytoshi: | michagogo|cloud: yeah, it's looking for Bitcoin/ in the wrong place |
| 19:50:52 | michagogo|cloud: | Ah, I see |
| 19:50:55 | michagogo|cloud: | https://www.irccloud.com/pastebin/u9B6Gp0X |
| 19:51:33 | michagogo|cloud: | andytoshi: Ah, I see. Specifically, it's using %localappdata% |
| 19:51:49 | michagogo|cloud: | I guess it doesn't plant its folder unless it manages to find Bitcoin/? |
| 19:52:57 | andytoshi: | michagogo|cloud: it doesn't plant its folder unless something changes, yeah |
| 19:55:52 | jgarzik: | adam3us, gmaxwell: current bootstrap.dat @ block 279,000 is 14222116865 bytes |
| 19:57:25 | michagogo|cloud: | Hmm, I wonder how hard it would be to change linearize.py to allow it to be given an existing bootstrap.dat and have it detect the latest block in there |
| 19:57:47 | jtimon: | maaku, what were you thinking on getting from factor to add to joy ? |
| 19:57:49 | sipa: | ;;blocks |
| 19:57:50 | gribble: | 280495 |
| 19:58:10 | michagogo|cloud: | (so you can point it at an older bootstrap, and say "bring this up to 279,000") |
| 19:58:27 | michagogo|cloud: | Oh, wait, this is the wrong channel :S |
| 19:58:33 | jtimon: | or nothing concrete? |
| 19:59:43 | jtimon: | I'm thinking that joy should be easy to merklize, no? |
| 20:08:11 | andytoshi: | michagogo|cloud: ok, i have refreshed the windows download to use %APPDATA% properly (and fixed the keep-on-top thing) |
| 20:11:05 | michagogo|cloud: | Hey, there're my coins |
| 20:11:22 | andytoshi: | :D |
| 20:12:05 | michagogo|cloud: | andytoshi: Wait, so all this does is shuffle your coins around in your wallet? |
| 20:12:20 | andytoshi: | michagogo|cloud: yeah, it doesn't do spends right now |
| 20:12:26 | andytoshi: | i'm not sure how best to UI that |
| 20:12:50 | michagogo|cloud: | Imitate the Bitcoin-Qt UI? |
| 20:13:16 | michagogo|cloud: | andytoshi: Not working |
| 20:13:21 | michagogo|cloud: | Syncing with joiner, session ID unknown |
| 20:13:21 | michagogo|cloud: | Join server: error setting certificate verify locations: |
| 20:13:21 | michagogo|cloud: | CAfile: /usr/i686-w64-mingw32/sys-root/mingw/etc/pki/tls/certs/ca-bundle.crt |
| 20:13:21 | michagogo|cloud: | CApath: none |
| 20:13:35 | andytoshi: | weeird |
| 20:13:59 | andytoshi: | what if you delete the libcurl DLL? |
| 20:14:48 | michagogo|cloud: | The program can't start because libcurl-4.dll is missing from your computer. Try reinstalling the program to fix this problem. |
| 20:15:07 | andytoshi: | <.< ok, i'll look into this |
| 20:15:14 | andytoshi: | thx |
| 20:15:22 | michagogo|cloud: | np |
| 20:34:16 | andytoshi: | michagogo|cloud: ok, i have stolen some DLLs from msysgit, can you try redownloading? |
| 20:35:18 | michagogo|cloud: | * michagogo|cloud scrolls up a bunch |
| 20:44:46 | michagogo|cloud: | * michagogo|cloud slaps explorer.exe around a bit with a large trout |
| 20:45:02 | sipa: | * sipa suggests installing an operating system |
| 20:45:29 | michagogo|cloud: | sipa: Hmm? |
| 20:46:57 | sipa: | nevermind, silly joke :) |
| 20:47:08 | andytoshi: | sipa: lol, be thankful that somebody on this channel has a normal system to test with |
| 20:47:11 | michagogo|cloud: | andytoshi: You messed up again |
| 20:47:17 | andytoshi: | michagogo|cloud: what now? |
| 20:47:22 | michagogo|cloud: | Same message as when I renamed libcurl |
| 20:47:33 | michagogo|cloud: | Except that it's complaining about libcrypto.dll being missing |
| 20:47:41 | sipa: | andytoshi: true that |
| 20:47:54 | andytoshi: | michagogo|cloud: oops :} i forgot to put that one in the zip |
| 20:48:02 | michagogo|cloud: | (and it is, indeed, missing) |
| 20:48:08 | andytoshi: | ..no i didn't .. it disappeared |
| 20:49:06 | andytoshi: | michagogo|cloud: sorry about that, fixed, can you redownload? |
| 20:50:09 | michagogo|cloud: | * michagogo|cloud puts http://download.wpsoftware.net/bitcoin/cj-windows.zip at the bottom of the buffer |
| 20:50:47 | nsh: | could you statically link these libs, andytoshi? |
| 20:51:27 | maaku: | michagogo|cloud: not hard i would think, just scan backwards to find the last block |
| 20:51:50 | andytoshi: | nsh: probably, but i'd have the same problems as i do with bundling DLLs, plus the usual problems (no upgradability, etc) of static linking, plus potentially bad linking issues |
| 20:52:09 | michagogo|cloud: | ;;cjs |
| 20:52:10 | gribble: | Coinjoin Status: There is no currently open session. Visit https://www.wpsoftware.net/coinjoin/ or http://xnpjsvp7crbzlj3w.onion/ to start one. |
| 20:52:17 | nsh: | * nsh nods |
| 20:52:31 | michagogo|cloud: | andytoshi: nope |
| 20:52:34 | michagogo|cloud: | Syncing with joiner, session ID unknown |
| 20:52:34 | michagogo|cloud: | Join server: SSL certificate problem, verify that the CA cert is OK. Details: |
| 20:52:34 | michagogo|cloud: | error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed |
| 20:54:23 | maaku: | jtimon: nothing concrete - just pointing out that Joy is a pure, simple academic language |
| 20:54:34 | maaku: | which is very good for a consensus system |
| 20:55:14 | maaku: | but in my experience, there is usually a handful of select hacks which offend purists but greatly simplify real world usage |
| 20:55:36 | maaku: | and Factor is a practical language of the Forth tradition, so we should look at that to see if there's anything to borrow |
| 20:55:46 | michagogo|cloud: | andytoshi: I g2g to sleep now |
| 20:55:50 | nsh: | maaku, any good examples of Joy in use? (that i might find accessible) |
| 20:55:51 | michagogo|cloud: | (or at least to bed...) |
| 20:55:57 | andytoshi: | michagogo|cloud: ok, thanks for testing |
| 20:55:57 | michagogo|cloud: | Good luck. |
| 20:56:00 | nsh: | 'night |
| 20:56:04 | maaku: | and yes, Joy - or any concatinative language - should be trivial to Merklize |
| 20:56:15 | michagogo|cloud: | I may be able to test more of future days |
| 20:56:17 | michagogo|cloud: | on* |
| 20:59:57 | maaku: | nsh: any kind of covenant |
| 21:00:35 | maaku: | e.g. i issue MarkBTC which is an IOU with 1% interest, but attach a covenant allowing my to buy it back at any time for principle + interest |
| 21:01:26 | petertodd: | http://www.reddit.com/r/Bitcoin/comments/1v7ayg/revolution_in_bitcoin_privacy_stealth_addresses/ <- getting good feedback on stealth addrs on reddit |
| 21:05:15 | nsh: | * nsh nods, opens tabs |
| 21:06:45 | maaku: | more generally, my musing on this started from trying to Etherium within the context of just changing bitcoin's scripting system |
| 21:08:04 | nsh: | to Etherium? |
| 21:10:58 | maaku: | heh, to do what is trying to be done with Etherium within a (minimally extended) bitcoin |
| 21:11:08 | maaku: | e.g. turing-complete financial contracts |
| 21:11:56 | maaku: | coin covenants, etc. |
| 21:12:50 | maaku: | for example, with a couple of script extensions and re-enabled opcodes, petertodd could make mastercoin fully validating and spv-safe |
| 21:12:57 | maaku: | (using covenants) |
| 21:13:34 | nsh: | interesting |
| 21:13:58 | nsh: | any notes or discussion online? |
| 21:14:53 | maaku: | this is an idea only 12 hours old :P |
| 21:15:01 | nsh: | ah, cool :) |
| 21:15:06 | gmaxwell: | maaku: at least you won't end up in the sad situation of having created a stack based language without roll or rotate. |
| 21:15:19 | petertodd: | maaku: actually months old - I proposed it for fidelity bonded bank stuff ages ago |
| 21:15:54 | maaku: | gmaxwell: :\ |
| 21:16:11 | maaku: | petertodd: yeah i figured you'd been working on this, based on our conversation |
| 21:16:40 | maaku: | petertodd: did that involve quines? I thought that part was new |
| 21:17:05 | petertodd: | maaku: nah, it needed quines too, and actually credit may go to gmaxwell come to think of it - I'd have to check my IRC logs |
| 21:17:18 | maaku: | ah i'll go read those threads then |
| 21:17:30 | nsh: | ooo quines |
| 21:17:41 | maaku: | nsh: that's how the covenant workss |
| 21:17:55 | nsh: | oh, fascinating |
| 21:18:16 | petertodd: | maaku: I *think* most of it was private conversation actually - wizards didn't exist back then |
| 21:18:37 | nsh: | can you(s) elaborate? |
| 21:18:39 | petertodd: | maaku: (this was almost a year ago now) |
| 21:18:43 | gmaxwell: | Yea, well, my 'invention' in the covenant thread is that you could produce a quine SNARK transaction, which is slightly surprising since you don't know the validation key for a snark until you've finished the circuit. |
| 21:18:43 | maaku: | mandate (some of) the outputs to have the same conditionals |
| 21:18:56 | gmaxwell: | Without the snark there are dumb ways to accomplish it. |
| 21:19:14 | gmaxwell: | With the snark it sounds impossible if you don't think about it from the right perspective. |
| 21:19:25 | nsh: | hmm |
| 21:19:32 | maaku: | /dumb/boring/ |
| 21:19:48 | gmaxwell: | yea, fair enough. |
| 21:20:47 | maaku: | nsh: yeah actually the coincovenant thread is basically a listing of what you could do with a turing-complete script language and introspective builtins |
| 21:21:04 | maaku: | the snark is just a really cool addition |
| 21:21:20 | gmaxwell: | Yea, I think nothing there requires the snark except for efficiency. |
| 21:21:33 | gmaxwell: | might be good to add some examples that need zero knoweldge |
| 21:25:58 | maaku: | petertodd gmaxwell: btw didn't mean to take credit for this old idea. i thought nsh meant the benefits of using Joy |
| 21:27:15 | nsh: | i'm curious in general and specific :) |
| 21:27:48 | petertodd: | I'm curious if joy brings us any joy. |
| 21:32:07 | maaku: | cdr=-\ |
| 21:32:12 | maaku: | 6jm |
| 21:32:20 | maaku: | sorry |
| 21:33:08 | petertodd: | maaku: glad to see you have (formerly) strong passwords |
| 21:33:18 | maaku: | haha, toddler found my keyboard |
| 21:33:44 | maaku: | gmaxwell: well there are bounties. you'd need a zk proof to safely claim a sha256 collision |
| 21:35:00 | maaku: | you can even design a covenant which forces revelation if the coins are to be actually used |
| 21:35:16 | petertodd: | * petertodd says hi to little maaku |
| 21:36:58 | sipa: | cdr-=\ -> that's actually potentially valid C code |
| 22:34:51 | pigeons: | adam3us: I just saw https://github.com/atoponce/d-note uses hashcash to generate a token before you can submit |
| 23:05:35 | jtimon: | ok, so I need a name for the TC merklized extrospective scripting extension I just understood hours ago |
| 23:06:40 | jtimon: | otherwise "the new thing" is taken and I cannot learn or think about anything else new too me |
| 23:06:58 | sipa: | tc? |
| 23:07:11 | sipa: | extrospective? |
| 23:07:48 | nsh: | turing complete, no idea |
| 23:08:11 | nsh: | network-external inputs maybe |
| 23:08:15 | jtimon: | tc = turing complete |
| 23:09:12 | jtimon: | extrospective = you can reference the scripts in the outputs of future transactions, parts in them, and maybe also the current utxo and the block header |
| 23:09:33 | petertodd: | jtimon: that's a pretty good description IMO |
| 23:09:34 | jtimon: | something outside the script itself |
| 23:09:45 | jtimon: | thank you |
| 23:10:15 | petertodd: | jtimon: more than current utxo too, but likely committed data of some kind within (to be clear) |
| 23:11:52 | jtimon: | although joy is a new addition and not necessary for the idea I like joyScripts, although I also like quineScripts, and we could also just maintain coincovenants (although not all uses use quines/covenants) |
| 23:14:04 | jtimon: | petertodd, you mean previous data in the chain? I guess it could work if people provide proofs to the miners, but for some reason I haven't found yet, that intuitively scares me |
| 23:14:26 | jtimon: | also I don't know any use et neither |
| 23:14:41 | jtimon: | *yet |
| 23:15:03 | petertodd: | jtimon: well, there's the model where it's proof based, referencing the prevblock hash, or you can have a model where miners are expected to actually have some set of data on hand. (that could take a lot of potential forms) |
| 23:16:53 | jtimon: | stateless validation is very attractive |
| 23:17:33 | jtimon: | I'm not sure what you mean by referencing the previous block hash |
| 23:17:36 | gmaxwell: | any stateful process can be reduced to a stateless one just by gathering up the state and presenting it as an input. |
| 23:18:14 | petertodd: | jtimon: IE, make your script take a proof in the form of a merkle path to the prevblockhash |
| 23:18:57 | jtimon: | petertodd: what kind of commited utxo are we assuming if any? |
| 23:19:16 | petertodd: | jtimon: could be a lot of forms, could be a committed MMR TXO too |
| 23:19:42 | jtimon: | I see, just one of them |
| 23:20:15 | petertodd: | jtimon: well, you can do both if you really want :P |
| 23:20:31 | petertodd: | jtimon: and actually, if you do expiration, both could make a lot of sense |
| 23:21:56 | jtimon: | well, I think expiration would be necessary for your TXI thing, but I don't know much about MMR |
| 23:23:00 | jtimon: | the advantages and stuff, I just read that once but I don't remember the motivation |
| 23:23:12 | jtimon: | I'm going to read again |
| 23:24:10 | jtimon: | but maybe a hybrid commited expired-TXI + UTXO would make sense too? |
| 23:24:23 | petertodd: | exactly |
| 23:24:30 | jtimon: | oh, I see |
| 23:24:45 | jtimon: | you use the MMR structure for the TXI ? |
| 23:25:16 | petertodd: | one interesting thing is that you probably want the PoW algorithm to be tightly coupled to some subset of blockchain data - perhaps the last year/GB of it - so a PoW on the UTXO set is an attractive idea |
| 23:25:34 | petertodd: | right, for long-term MMR works really well |
| 23:26:34 | petertodd: | note that when I say "UTXO" set that doesn't necessarily mean it the way you would mean in bitcoin - for some extrospective scripting consensus system your utxo set might mean a lot of things that may or may not be coins |
| 23:27:21 | jtimon: | to be honest, I'm thinking in freimarket's utxo |
| 23:27:30 | petertodd: | e.g. the absolute extreme you can take this idea is for the system to be essentially a key-value global consensus, where keys are H(script) and values the output of those scripts (basically) |
| 23:27:38 | jtimon: | with asset types, unique bitstrings... |
| 23:27:43 | petertodd: | yup |
| 23:28:04 | petertodd: | and mastercoin needs to look something like that if it's going to be useful |
| 23:28:36 | jtimon: | well, values also have refHeight for interest/demurrage and I guess some other minor details |
| 23:28:56 | petertodd: | right |
| 23:29:00 | jtimon: | why " you probably want the PoW algorithm to be tightly coupled to some subset of blockchain data"? |
| 23:29:24 | petertodd: | my extreme example, which I guess I could call MetaCoin, could be done such that the scripts themselves are what define consensus currency systems within MetaCoin |
| 23:29:49 | petertodd: | jtimon: because you want there to be incentive for miners to actually publish the contents of the blocks they mine, rather than just headers |
| 23:30:32 | petertodd: | jtimon: basically with stateless validation you can wind up with miners having no blockchain data at all, and then find out that only a single party has the data, and hence can assist others in creating transactions (or no-one has the data and the coin gets stuck!) |
| 23:30:39 | jtimon: | an interesting thing is that with unique tokens, you have effectively a per-asset namespace that you can use as generic key/value store |
| 23:31:08 | petertodd: | jtimon: yes, *but* that's only useful if either multiple values can be associated with a single key, or the keys are scripts |
| 23:32:08 | petertodd: | jtimon: see, you can view a decentralized consensus system's blockchain as a weird type of cryptographic accumulator - it's easy enough to create a proof that some tx-thing existed or didn't exist in that chain, but you must have blockchain data to update (and create) those proofs |
| 23:32:59 | jtimon: | but the holders could take care of keeping their data, no? |
| 23:33:20 | gmaxwell: | how can you keep data if miners aren't even sending you enough to update your copy? |
| 23:34:22 | petertodd: | gmaxwell: well, remember how with MMR TXO you can get transactions mined with the assistance of third-parties who create the txin proofs for you? of course, with the txin proofs, miners with no blockchain data at all can safely mine the txs |
| 23:35:02 | petertodd: | gmaxwell: hence, you can wind up with a system that appears to work just fine, until one day you realize only one entity has a copy of some or all blockchain data - even worse if you've got some sharded (U)TXO set scheme going on |
| 23:35:06 | jtimon: | gmaxwell I thought your part of the trie in which your data resides cannot be modified if not by you, maybe I misundertood something about maaku's updatable structure |
| 23:36:14 | jtimon: | I also don't understand this senstence "that's only useful if either multiple values can be associated with a single key, or the keys are scripts" |
| 23:36:16 | petertodd: | jtimon: yeah, but what forces miners to actually publish the content of blocks to other miners? nothing |
| 23:36:45 | petertodd: | jtimon: e.g. with my "one entity has a copy of the blockchain" example, miners could be just sending their blocks to that entity, but not to each other, and the system will appear to work just fine |
| 23:36:58 | petertodd: | jtimon: maybe that happens due to lazyness, maybe due to sybil attack, who knows? |
| 23:37:20 | jtimon: | they need to publish the new root of the trie, and they want other miners to believe them, so they will send all the proofs they used to update the tree |
| 23:37:24 | petertodd: | jtimon: in a sharded system, it means you can 51% attack some *subset* of the (U)TXO space, likely with less than 51% of hashing power |
| 23:37:25 | gmaxwell: | jtimon: your own coin could only be modified by you, but all the neghboring branches can be modified by the holders of 2^levels-up coins. |
| 23:38:09 | petertodd: | jtimon: nope. Miners will lose money if they mine invalid blocks, so we can trust them not too do that 95% of the time, and it's in your incentive to very quickly mine the longest chain so you're not wasting your time... |
| 23:38:40 | petertodd: | jtimon: and if tx's can provide proof that they are valid to include in a block, all the better! |
| 23:38:52 | jtimon: | you're trying to explain me the problem of relying on archive nodes |
| 23:39:02 | petertodd: | jtimon: or hell, imagine some scheme where we're using SCIP moon magic so that miners can prove their blocks *are* valid |
| 23:39:28 | petertodd: | jtimon: roughly speaking, but it's really even deeper than that |
| 23:39:56 | jtimon: | I thought that wasn't a problem with maaku's latest updatable utxo design |
| 23:40:24 | petertodd: | jtimon: no it is, it's just not as likely to be an actual problem as some sharded blockchain scheme. |
| 23:40:44 | petertodd: | jtimon: mainly I'm interested in solving that because I think it's an important part of making consensus schems more scalable |
| 23:40:55 | jtimon: | miner 1 receives all the proofs it needs from regular users to update from UTXOn-1 to UTXOn |
| 23:41:21 | jtimon: | he sends the mined block and all those proofs to all miners |
| 23:41:38 | jtimon: | I'm still missing the problem |
| 23:42:12 | petertodd: | it's simple: what forces him to actually send those proofs to other miners? they can mine just fine without them, and have incentives to skimp on doing proper validation |
| 23:42:42 | jtimon: | you said it yourself " Miners will lose money if they mine invalid blocks" |
| 23:42:47 | petertodd: | now systems where miners can mine pairs of blocks, one valid and one invalid, as gmaxwell has suggested, help here |
| 23:42:58 | petertodd: | jtimon: yes, which means we can trust them not too! |
| 23:43:05 | jtimon: | if you don't send me the proofs, I don't hash on top of your chain |
| 23:43:28 | petertodd: | why not? if I'm not hashing, I'm not making money 99% of the time where the block *was* valid |
| 23:43:37 | jtimon: | and because I want everybody to hash on top of my block, I send the proofs to every miner |
| 23:43:38 | petertodd: | I might as well take that risk |
| 23:43:52 | petertodd: | as I say, the incentive isn't as strong as you think |
| 23:43:56 | jtimon: | I prefer to mine block n-1 |
| 23:44:14 | petertodd: | why? you'll make more money if you mine block n 99% of the time |
| 23:44:47 | jtimon: | ok, I don't trust your 99 but I get your point |
| 23:45:24 | petertodd: | remember, what the bitcoin sourcecode implements doesn't necessarily match what a rational miner will actually do |
| 23:45:56 | jtimon: | so miners would have the incentive to send fake invalid blocks to distract competition |
| 23:46:13 | petertodd: | right now that costs too much because you can only mine either a valid, or an invalid, block |
| 23:46:23 | sipa: | they have an incentive to send fake invalid blocks to 49% of their competition... |
| 23:46:25 | petertodd: | now, if the system allows you to mine both simultaneously, perfect! |
| 23:46:32 | jtimon: | so that 99 turns into a 1 and everybody is happy again |
| 23:46:59 | petertodd: | yes |
| 23:47:45 | petertodd: | and/or tie your PoW scheme to some subset of blockchain data, and the other miners simply can't mine on your block unless you give them the data, therefore they'll mine on block n-1 and eventually overtake you (unless you have 51%, but we're screwed there...) |
| 23:47:58 | jtimon: | what's the problem then? we only need miners to spam each other so that they don't trust new blocks without the corresponding proofs |
| 23:48:49 | jtimon: | oh, I see, I guess your solution is better |
| 23:49:20 | petertodd: | well, actually I think both solutions are good, and for different reasons: the "firedrill" one helps test fraud proof code and ensure it actually works, which is valuable in of itself |
| 23:49:49 | jtimon: | sorry, I forgot you were trying to explain me the problem that justified the solution but I forgot you had a solution |
| 23:50:00 | petertodd: | heh |
| 23:50:45 | petertodd: | now here's the next problem: suppose we decide to shard the blockchain, we'll say UTXO's starting with MSB=0 go on one side, MSB=1 go on the other |
| 23:51:12 | petertodd: | so that's basically two parallel chains, and and they timestamp each other (really forming a *timestamp* chain over both) |
| 23:51:22 | jtimon: | sorry, what was sharding again? |
| 23:51:39 | petertodd: | jtimon: shard as in how databases are split up |
| 23:52:31 | jtimon: | like partitioning the blockchain? |
| 23:52:33 | petertodd: | now miners only mine one or the other chains contents, but %100 of the hashing power goes to the timestamp |
| 23:52:36 | petertodd: | jtimon: yes |
| 23:53:09 | jtimon: | sorry again, what's MSB=0 ? |
| 23:53:18 | petertodd: | MSG=most significant bit |
| 23:53:25 | jtimon: | ok |
| 23:54:01 | petertodd: | now, suppose somehow one entity controls 95% of the hashing power on chain 0, and they just don't publish block contents, but *do* contribute to the overall timestamping hashing power |
| 23:54:33 | petertodd: | they can't attack the timestamp - they only have 40% of the total hashing power - but they can make it impossible for any transactions to happen on chain 0 |
| 23:55:15 | jtimon: | sorry, I got lost here "now miners only mine one or the other chains contents, but %100 of the hashing power goes to the timestamp" |
| 23:55:36 | petertodd: | suppose then they stop their attack - you're left with a bunch of blocks that have been timestamped, but the actual contents of them have vanished, which means you can't modify the state of the chain unless you "roll-back" to whatever data is publicly available, but what's the right rule to handle that? |
| 23:56:05 | jtimon: | the purpose of sharding is to have lighther miners, I guess |
| 23:56:24 | petertodd: | jtimon: suppose a block header for the timestamp contains hashes of the most recent header in the subchains |
| 23:56:45 | petertodd: | jtimon: exactly, specifically spread the bandiwdth out so that you don't need to keep up with all tx's to mine |
| 23:56:56 | jtimon: | and who pows the timestamp? |
| 23:57:01 | jtimon: | nobody? |
| 23:57:27 | petertodd: | well, one easy way is to say that the two chains are merge-mined with the timestamp |
| 23:57:38 | petertodd: | and then set the pow difficulty to be exactly half of the timestamp difficulty |
| 23:57:59 | jtimon: | isn't merged mining like the opposite of sharding? |
| 23:58:48 | petertodd: | jtimon: no! in this case it's just a way of having a very strong pow for what orders transactions - the timestamp chain - while allowing for two separate chains |
| 23:59:30 | petertodd: | e.g. a block header in this scheme consists of PrevTimestampHash, MergeMineRoot, Time, etc. |
| 23:59:45 | petertodd: | and the subblock headers are just PrevSubChainHash, MerkleRoot |