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