--- Log opened Tue Oct 15 00:00:11 2013
02:12 < warren> sipa: http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/2000/300/2318/2318.strip.gif
02:16 < sipa> let me guess
02:16 < sipa> yup :)
02:26 < warren> sipa: just as likely as my one time pad
05:36 < wumpus> https://github.com/bitcoin/bitcoin/issues/3090 CodeBug : should compare return value from memcmp with zero.
05:36 < wumpus> wrong channel
08:45 < HM3> since Bitcoin already uses boost you could use boost array instead of 'vch' in CKey
08:45 < HM3> would have got operator== for free
09:56 < petertodd> BlueMatt: from the point of view of a SPV node, verifying that a block header is correct is verifying it fully, so relaying that header (or even full block) to other SPV nodes does no harm.
09:57 < sipa> well, you would at least want to announce that you did not verify transactions in that case
09:57 < petertodd> BlueMatt: anyway, I put that in the BIP to show how NODE_BLOOM should be thought of "I'm willing to apply bloom filters to stuff I relay to you" and nothing more
09:57 < petertodd> sipa: which you do because you didn't set NODE_NETWORK (in that case)
09:58 < sipa> right, NODE_BLOOM is orthogonal to what you are relaying
09:58 < petertodd> sipa: exactly
09:59 < petertodd> You could (uselessly) say NODE_BLOOM and !NODE_* just means I'm willing to apply bloom filters to the nothingness I will relay to you; if you implement this I suggest you apply for an art grant.
09:59 < sipa> perhaps apply it to addr or alert messages :p
10:00 < petertodd> With an extended NODE_BLOOM definition that makes a lot of sense.
14:41 < gmaxwell> uh. Michael Gronager has ... um. not quite sure what to call it: https://bitcointalk.org/index.php?topic=310954
14:43 < petertodd> looks fixable to me, though ugly
14:44 < gmaxwell> yea, it's apparently already fixed.
14:45 < gmaxwell> 50% drop in namecoin exchange rate though.
14:45 < petertodd> good example of how blockchains can separate proof-of-data distribution, global consensus on ordering, and the actual rules themselves...
14:45 < petertodd> ha, yeah, I should have quickly bought some at the low point :P
15:07 < warren> amusing to see the deniers in the thread
15:10 < amiller> does anyone know who first created namecoin
15:10 < sipa> vinced?
15:15 < K1773R> gmaxwell: (namecoin) holy, thats horrible... i wonder why nobody looked at it :S
15:16 < sipa> i suppose because nobody competent cared? *ducks*
15:16 < amiller> but no one has heard from vinced in a long time?
15:17 < petertodd> K1773R: namecoin isn't getting used for anything yet; it just hasn't caught on
15:17 < petertodd> K1773R: well, other than speculators...
15:18 < K1773R> petertodd: i used it as backup solution for important stuff
15:18 < sipa> eh?
15:18 < petertodd> K1773R: backup? how so?
15:18 < K1773R> your aware its just a simple key/value storage?
15:19 < sipa> yes
15:19 < sipa> but there are certainly easier ways
15:19 < K1773R> https://github.com/runn1ng/namecoin-files <-- some public horrible implementations :P (i made a own one)
15:20 < petertodd> K1773R: ha, did you know that namecoin disabled the IsStandard() test?
15:21 < warren> is it rickrolled?
15:22 < petertodd> warren: a lot worse than that...
15:22 < petertodd> http://explorer.dot-bit.org/b/7f48b8b9c494479c6f7cf980e0458167d4fddb92aeb1e5c468143e51bdd022a4
15:28 < petertodd> gmaxwell, warren: http://gpg.ganneff.de/policy.txt_v1.3 <- interesting example of two PGP keys signing a single document without the multiple PGP block solution we came up with; I wonder what tool made that
15:29 < midnightmagic> I was using namecoin as a datestamper.
15:30 < petertodd> midnightmagic: note how merge-mining automatically links it to the more secure bitcoin blockchain in that case
15:31 < midnightmagic> yes. Uuk's cryptostamper was too difficult to use also.
15:31 < petertodd> Uuk's?
15:32 < sipa> chronobit
15:32 < midnightmagic> Uukgoblin wrote a cryptostamper you could merge-mine on using (i.e.) p2pool's --merged option.
15:32 < midnightmagic> yes, chronobit.
15:32 < petertodd> oh, that piece of shit...
15:32 < midnightmagic> oh now.
15:33 < petertodd> really annoys me to see people bringing up chronobit; perfect example of geeks completely ignoring usability
15:33 < sipa> i never used it; what was bad about it?
15:33 < sipa> ah
15:33 < petertodd> sipa: takes about a thousand times more work than just using bitcoin directly
15:33 < warren> currently your chronobit timestamp granularity is maybe a day, if you're lucky, unless you keep the entire sharechain which nobody does.
15:33 < sipa> yes, but it scales O(1) !!
15:33 < petertodd> sipa: so does Bitcoin given the 1MB blocksize... :P
15:33 < midnightmagic> just difficult to use. I got it self-claiming it was working and it could verify stamps and such, but then i just gave up because even the email-to-usenet pgp stamper from the uk was easier
15:34 < petertodd> warren: p2pool has the same 2 hour logic as bitcoin, so it'll never be better than that
15:35 < petertodd> midnightmagic: yup, bitcoin timestamping is just so easy to understand and verify
15:36 < petertodd> w/ bitcoin utxo timestamping I've been thinking how you could do a really nice - for the user - standard for OpenPGP keys/sigs that was "co-operative": create the timestamp with a UTXO entry, and if you see a sig without a timestamp, create one too for everyone to use.
15:37 < petertodd> what's "lovely" is how bc.i has the API to make it all easy to verify, and you can fall-back to searchrawtransactions, or in the future, UTXO proofs + whatever crap Mike and co are going to implement to make SPV nodes lives easy
15:41 < petertodd> note that for PGP, timestamping doesn't need much granularity - you just want a timestamp that you can use to reason that at the time a signature was created, the corresponding key wasn't compromised/revoked
15:42 < petertodd> true of a heck of a lot of uses actually...
15:50 < gmaxwell> lol hogwash 12:33 < petertodd> sipa: so does Bitcoin given the 1MB blocksize... :P
15:50 < gmaxwell> "It's O(1) so long as no one uses it" is hardly a great argument.
15:50 < petertodd> gmaxwell: No, it's O(1MB) :P
15:51 < petertodd> gmaxwell: In fact, most algorithms are O(the entire universe)...
15:51 < gmaxwell> If you're happy to have some random website store your data so you can search for it... it'll be a lot cheaper to just ask them to store it than try to compete with people for 1MB space, since that site surely can have more disk space than limited blocks. :)
15:52 < petertodd> gmaxwell: Keep in mind, my usual argument is that yes, that's true, but how many uses of data are out there than *can* pay x cents per KB that "cheap" transactions imply?
15:53 < petertodd> Namecoin is an especially ugly example, because a Namecoin on Bitcoin can afford to pay rather large fees for name updates; way in excess of what a cheap transaction is.
15:57 < petertodd> gmaxwell: Oh, have I explained to you yet how I don't think UTXO bloat is a problem?
15:57  * sipa is curious
15:57 < amiller> go on
15:59 < petertodd> It's really simple: create a *TXO* commitment data structure with a merkle mountain range; this is a data structure that has ~O(1) appends, and O(log n) updates. Txouts in this structure are marked unspent or spent.
16:00 < petertodd> The key thing is that you can prove the current state of any txout with a proof of O(log n) size, and you can also use those proofs to update the state securely. This means every tx can now just have proofs of the txouts existance, and miners can update the txo commitment without actually having the blockchain data.
16:00 < petertodd> Thus your UTXO set is an optimization, rather than a requirement, and in essense storing the UTXO data is pushed to the people who actually own the UTXO's.
16:01 < petertodd> Realisticly you'd want to just have nodes store, say, the last 1 year worth of UTXO's or something; essentially expiration, but you can still spend old UTXO's, just at greater cost.
16:02 < amiller> so you need *part* of the UTXO to construct the proof that *your* tx is valid
16:02 < petertodd> amiller: exactly
16:02 < amiller> utxo as a service makes sense to me
16:03 < petertodd> yup, and that service can be distributed easily too - you only need the part of the utxo set/part of blocks relevant to what you want to store
16:05 < amiller> there are some things like
16:05 < amiller> polynomial representations of sets
16:05 < amiller> that are pretty efficient
16:06 < amiller> where if the set contains your element
16:06 < amiller> and you know your element
16:06 < petertodd> you still get the compact fraud proofs that utxo sets get you too in this scheme
16:06 < amiller> you can take any representation of the set
16:06 < amiller> and easily prove that your element is in it
16:06 < petertodd> lol, how do those work?
16:07 < amiller> http://www.cs.berkeley.edu/~dawnsong/papers/set-int-full.pdf
16:08 < amiller> maybe this one http://www.ece.umd.edu/~cpap/published/cpap-rt-nikos-11.pdf
16:10 < amiller> hmm.
16:10 < amiller> basically you have a polynomial in some field
16:11 < amiller> the polynomial looks like f(x) = Product{  a0(x0 - x), a1(x1 - x), ....  aN(xN - x)  }
16:11 < amiller> so that polynomial has roots at x0 and x1 and such
16:11 < amiller> and you represent the polynomial just by its evaluation on a random element in the field s
16:12 < amiller> i dunno maybe that doesn't work
16:12 < sipa> those aN's seem useless
16:12 < petertodd> huh, can't say I understand it
16:12 < gmaxwell> petertodd: how do you prove if your coin is already spent or not in your mountain range thing?
16:13 < petertodd> gmaxwell: you just provide a merkle path from the txout to the TXO commitment - the mountain range gets modified every time a txout is spent and the commitment of the current version of it is included in every block
16:14 < gmaxwell> oh you made inserts cheap, but updates need the longer proof so you can modify it?
16:14 < sipa> so you need to know the mountain range locally, to be able to prove a coin still exist?
16:14 < gmaxwell> (inserts just need the current 'rightmost edge'
16:14 < gmaxwell> )
16:14 < sipa> so transactions can't be valid across block updates?
16:15 < petertodd> gmaxwell: yeah, *appends* are essentially O(1), and updates need to update the log n hashes from the txout to the tip
16:15 < petertodd> sipa: what do you mean?
16:15 < sipa> say i want to spend a coin
16:15 < gmaxwell> like you write a txn containing an update proof, and the the txn next to it in the set is updated.. not your proof is no good.
16:15 < petertodd> sipa: oh, right, they can still be valid though, because nodes in between have enough block data to rewrite the parts that are changed
16:15 < sipa> right
16:16 < gmaxwell> Iff they do, right?
16:16 < petertodd> Like, if I have a full copy of the blockchain data, and so do you, for me to prove some tx is valid, I don't need to give you any proof at all. If you're missing part, I may need to give you some proof, and that proof may change on the next block. (but only part of the proof will change)
16:16 < petertodd> gmaxwell: yeah, I wouldn't have people *sign* the proofs that a tx is valid for instance
16:17 < gmaxwell> might couple well with OWAS fees, since relaying nodes would be paid for keeping a txn valid.
16:17 < amiller> you might be able to structure the utxo so that an old proof is likely to stay valid
16:18 < amiller> like you can pay to put your coin in the VIP section that isn't updated so often
16:18 < petertodd> gmaxwell: Yup, or for finding the up-to-date proof that a tx is valid.
16:18 < gmaxwell> well if the proof has the right structure, then the composition rule stuff we talked about would apply.
16:18 < petertodd> amiller: Yeah, I was thinking about that, but proving compactly that a given txo is in the "vip section" gets tricky and ugly fast. :(
16:18 < petertodd> gmaxwell: composition rule?
16:18 < gmaxwell> e.g.  if you have proof A and see a block that would invalidate it then you would also know enough to fix the proof.
16:19 < petertodd> gmaxwell: oh right, yeah that's easy to implement
16:19 < gmaxwell> petertodd: e.g. if you have a proof of   A->B and A->C  you can form A->{B,C}
16:19 < petertodd> gmaxwell: better yet, you can parallize all this stuff too
16:19 < gmaxwell> well, parallel has fungibility problems, no?
16:20 < gmaxwell> e.g. if you have coins in streams, spending cross streams would be more costly.
16:20 < petertodd> gmaxwell: no, by parallize I just mean how if you have n txs, the actual updates to the data structure can be done in parallel on your local computer
16:20 < gmaxwell> oh oh okay I thought you were saying you could have N mountain ranges.
16:22 < petertodd> gmaxwell: nope, well, not yet anyway :) figuring out how to do that is my next goal... but I suspect that always runs into issues of censorship, where someone manages to get the only copies of some part of the txo set and prevents people from spending their coins
16:22 < gmaxwell> petertodd: well the whole problem with this set of issues is that you can't have an "autonoymous cold wallet"
16:22 < petertodd> gmaxwell: I think you need a proof-of-stake scheme for that; force miners to prove they have the consent of some majority (floating) of the people holding txouts
16:23 < gmaxwell> keeping your own data sounds great, except you require the person keeping it to be eternally vigilent.
16:23 < petertodd> gmaxwell: yup, I think that's unsolvable unfortunately
16:23 < gmaxwell> well, it's not, but I don't like the solutions.
16:24 < petertodd> what do you think solutions to that might be?
16:24 < gmaxwell> You need a one way accumulator that doesn't grow, so you can tick off spent coins.
16:25 < petertodd> Point is accumulators always either grow, or the proofs that your coin is in the accumulators require updating.
16:26 < gmaxwell> petertodd: sure, but what if the accumulator only tracks spent coins?  Of course something that doesn't grow at all can't be collision free...
16:27 < gmaxwell> e.g. MMR to prove your coin existed, and then some kind of cryptographic accumulator that to check that it hasn't been spent.
16:27 < petertodd> gmaxwell: Right, now you can get down to 1 bit per txout for a spent coin accumulator, but you're not going to get lower than that... and if you do the numbers on an accumulator with acceptably low risk of collission it needs to be huge.
16:29 < petertodd> *probabalistic accumulator
16:30 < gmaxwell> so an interesting thing is that the bitstring can never have a weight greater than 21e14. I wonder if that helps.
16:30 < petertodd> ?
16:31 < gmaxwell> you can never have more than 21e14 unspent coins.
16:31 < petertodd> what do you mean by "the bitstring" though?
16:32 < gmaxwell> the spentness data.
16:33 < gmaxwell> I guess it doesn't really help, even though the number of 1s is limited the potential storage is still infinite.
16:33 < petertodd> oh, you mean by how many satoshis can be in circulation?
16:33 < gmaxwell> right.
16:33 < petertodd> yeah, those satoshis can be respent over and over again
16:33 < gmaxwell> sure but if they are they take away a 1 and move it elsewhere.
16:34 < gmaxwell> I was thinking about how an efficient representation of the bit array is minimum size for all spent and for none spent, and largest when p=.5
16:34 < K1773R> petertodd: hehe, i tested that script (download not uploading to chain) and it worked slowly
16:35 < petertodd> gmaxwell: Ah right.
16:36 < petertodd> K1773R: which script?
16:38 < petertodd> gmaxwell: It's interesting how you could think in terms of capping the whole UTXO set such that every human being could hold some bitcoins - a gigabyte of bits if represented properly
16:39 < petertodd> Represent it such that the actual UTXO scriptPubKey has to be provided along with an appropriate proof.
16:39 < sipa> you probably want some per-human granularity above "something/nothing"
16:40 < petertodd> sipa: The value of the UTXO would be part of the proof you are asked to provide to spend it.
16:41 < sipa> ah
16:44 < petertodd> sipa: anyway, the other part of that observation, is how the UTXO set could also be nothing more than H(outpoint) truncated to, say, 160bits, giving you 160 giga bytes - also reasonable.
16:44 < petertodd> Again, make transactions provide the outpoints they're spending.
16:47 < petertodd> (note how close this proposal is to P2SH)
17:08 < K1773R> petertodd: https://github.com/runn1ng/namecoin-files
17:19 < HM2> lol
18:00 < amiller> i have been thinking about a weird idea
18:00 < amiller> i am not sure whether it's possible to even state this clearly
18:00 < amiller> one of the main points of this one bitcoin economics paper is that following the stated rules is only a "focal point"
18:01 < amiller> http://www.weis2013.econinfosec.org/papers/KrollDaveyFeltenWEIS2013.pdf
18:01 < amiller> it would conceptually be easy to perturb various rules and if everyone switches all at once, then there's not obstacle to doing so
18:01 < amiller> like a hardfork change requires nothing more than a hardfork
18:01 < amiller> could there be a way to bake in the rules so that it would be hard to perturb them without breaking the whole thing?
18:02 < amiller> there's something like a lower bound, which is that everyone could just stop working on bitcoin and switch to some other protocol all at once
18:02 < amiller> but then the transaction history would all be different and such
18:02 < amiller> there's no way to prevent everyone leaving bitcoin and participating in some other protocol instead
18:02 < amiller> but a hardfork change is different because it builds on the previous history
18:02 < gmaxwell> arguably thats the most ethical way to change the rules, but evaporation is a risk.
18:03 < amiller> so something like error correcting code
18:03 < amiller> where the validation code is built into the history somehow
18:03 < amiller> i mean you could embed the source code to the validation rules in the history
18:03 < amiller> like a commitment to it
18:03 < gmaxwell> E.g. people would be forced to change only by economic realityies and network effect, but not by the software.
18:03 < amiller> but it's not binding
18:03 < amiller> maybe there's a way to build the validation code commitments
18:03 < gmaxwell> amiller: well you could make it binding. and use a majority vote. But voting for rules is not actually just.
18:04 < amiller> into everyones public keys
18:04 < gmaxwell> Democracy isn't a virtue, its a compromise.
18:04 < amiller> so that if you perturbed the valiadtion rules at all
18:04 < amiller> you would get no security whatsoever
18:04 < amiller> so it's like every slightly changed ruleset using the same transaction history would be trivial/broken
18:04 < amiller> then the only way to proceed would be to commit transactions satisfying the correct rues
19:42 < gmaxwell> petertodd: you going to try to do a windows binary for dust-b-gone or should I try to nag someone else to do it?
19:42 < petertodd> gmaxwell: nag someone else - I don't have a copy of windows to do it on
19:45 < gmaxwell> petertodd: nor do I. :) OK.
19:47 < petertodd> gmaxwell: fwiw there hasn't exactly been many people using it...
19:48 < gmaxwell> petertodd: yea, I know, but no drool and clickly way to run it is one barrier.
19:49 < gmaxwell> I saw someone trying who was hung up on some python dependencies.. I think the windows exe magic stuff fixes that too.
19:49 < petertodd> gmaxwell: yeah, I think I helped that guy
--- Log closed Wed Oct 16 00:00:13 2013