--- Log opened Fri May 31 00:00:51 2013
00:01 < realazthat> mmm
00:02 < realazthat> gmaxwell: eli mentions implementing something analogous to zerocoin
00:02 < realazthat> what is your opinion on that?
00:08 < petertodd> zooko: thoughts? like a better name than pos-key-value?
00:09 < petertodd> zooko: come up with a good one or it's gunna be zookey
00:09 < zooko> Haha!
00:09 < petertodd> zookeydns!
00:10 < petertodd> Hmm... actually, overruled, it's now zookey
00:10 < zooko> Well, I didn't understand all of it.
00:10 < zooko> Haha!
00:10 < zooko> Very funny
00:10 < zooko> I'm honored.
00:10 < petertodd> What didn't you understand?
00:10 < zooko> So, I was chatting in here with gmaxwell about some relatedish topics, IIUC.
00:10 < petertodd> At least I didn't name it zooko^2...
00:10 < zooko> Namely, the possibility of a rebooted and improved Namecoin.
00:10 < petertodd> ...which should be done
00:11 < petertodd> ooh, zookeyv has a nice ring too it
00:15 < zooko> Let's see... I didn't fully understand why a Bitcoin or Bitcoin-like thingie would be necessary or useful for this catalog of identities.
00:15 < zooko> Also, I think the notion of "identity" that was being discussed, especially by jgarzik is underspecified and maybe not that useful.
00:16 < zooko> Sorry for the delay -- there is a security investigation ongoing here and I'm trying to ignore it and have fun hacking instead. ☺
00:16 < petertodd> Fun...
00:16 < petertodd> Well, it all boils down to a global consensus on a mapping of keys to values right?
00:16 < petertodd> So zookeyv is just that mapping, which can be used for a lot of things.
00:16 < petertodd> How do you come to a global consensus? Voting. We know of no other way.
00:17 < zooko> Okay, so that is what I have always perceived as the core usefulness of Namecoin.
00:17 < zooko> I'm not sure what you mean by "voting". My answer would be "Bitcoin". ☺
00:17 < petertodd> How do we vote? Proof of work; proof of sacrifice is really just transferrable proof of work.
00:17 < petertodd> See, this could be implemented directly on Bitcoin, but then people would try to kill me.
00:18 < zooko> ;-)
00:18 < petertodd> Specifically gmaxwell, and he knows where I live.
00:18 < zooko> Okay, so my answer would be "The Bitcoin Idea".
00:18 < zooko> Which is the first plausible global consensus system.
00:18 < petertodd> Indeed, and once you have one global consensus system, you don't need any more.
00:18 < zooko> I think there are more options than proof-of-work, proof-of-sacrifice...
00:18 < petertodd> There's proof-of-stake
00:19  * zooko nods.
00:19 < petertodd> ...and really proof-of-stake is proof-of-work done in the past.
00:19 < zooko> Okay, so suppose we're going to maintain a k-v mapping with global consensus.
00:19 < petertodd> *proof-of-work-done-in-the-past
00:20 < zooko> Like with Bitcoin-proper, we relieve some of the burden on the consensus system by asking it only to determine which of multiple conflicting signed statements to honor, instead of
00:20 < zooko> asking it to speak for everyone.
00:20 < zooko> Right?
00:21 < zooko> In the same way that Bitcoin doesn't ask the global consensus to determine everyone's account balance, but only to choose which spend to honor when there are conflicting spends.
00:21 < petertodd> Ok, but lets rephrase that: Bitcoin is a consensus system, and for every unspent txout (the key!) it assigns a value (what transaction spent it!)
00:24 < zooko> Ok.
00:24 < zooko> But those keys are use-once.
00:25 < Luke-Jr> add a version number to the key name, and voila…
00:26 < petertodd> Sure, but lots of key-value maps are set once, doesn't make it not a key value map.
00:31 < zooko> Luke-Jr: I don't quite see what you mean.
00:31 < zooko> petertodd: I didn't mean it isn't a key-value map...
00:32 < Luke-Jr> zooko: version 0 of a key is the first time it's set; version 1 overrides that to set it a 2nd time, etc
00:32 < zooko> So, maybe this is what Luke-Jr was getting at, if you have this set-once kind of thing, you can always use it as a set-many kind of thing by every time you set the set-once key, the value has the next key bundled into it.
00:32 < Luke-Jr> that's an option too
00:32 < Luke-Jr> I'd just make it deterministic :P
00:33 < Luke-Jr> "next key bundled into it" is arguably what Bitcoin does :P
00:33 < zooko> Yeah!
00:33 < petertodd> Exactly, and as jdillon pointed out, you can make a updatable key-value store that way: https://bitcointalk.org/index.php?topic=186264.msg2037810#msg2037810
00:33 < petertodd> Of course, he pointed that out because he wants to show that raising the blocksize limit is madness...
00:34 < Luke-Jr> right now*
00:34 < petertodd> Luke-Jr: correct, *removing* the blocksize limit
00:35 < petertodd> zooko: jdillon is the same guy that timestamped 50K PGP fingerprints into the blockchain to prove a point
00:36 < Luke-Jr> petertodd: glare at him for me
00:36 < Luke-Jr> if you want to prove a point, testnet is the place for that -.-
00:37 < petertodd> anyway... his underlying idea there is sound, the key-value system now called zookeyv that I outlined basically takes that simple structure and makes it efficient, and importantly, gives incentives to not hide your actual keys and values
00:37 < zooko> petertodd: heh heh
00:38 < zooko> So is your "zookeyv" design using the technique of bootstrapping set-once keys to get effectively set-many keys?
00:38 < petertodd> well... very roughly speaking kinda
00:39 < zooko> I don't understand why it is important to disincentivize hiding keys and values.
00:39 < zooko> Or... or what "hiding" could mean here. ☺
00:39 < petertodd> Its more that we can attach a value to those set-once keys, to decide *which* set once key is now canonical, and instead of values being keys directly, they're block headers
00:41 < petertodd> Oh, and the key, that's actually the previous block(s) in the dag
00:41 < zooko> Hm.
00:41 < zooko> I didn't follow that last bit.
00:41 < zooko> There is never a question about which set-once key is canonical, if
00:41 < zooko> you already have a global consensus system to resolve conflicting claims about that from the controller of the key.
00:41 < zooko> Right?
00:42 < zooko> And what's a block header?
00:42 < petertodd> Well, lets suppose we have an updatable set-once key, as Luke described.
00:42 < zooko> Actually I didn't understand that.
00:42 < zooko> The version I described, in which you have a key that can really be set at most once
00:43 < zooko> and then whenever you set it, you set it to a tuple of (value, new-key).
00:43 < zooko> That I understand.
00:43 < petertodd> Basically he's just saying that if your keys follow the convention key-1, key-2, key-3 then you basically *do* have a set-more-than-once key-value map.
00:43 < zooko> (By the way, it dovetails with a thing called "Guy Fawkes Protocol".)
00:43 < petertodd> (assuming consensus about the current set of all k-v pairs)
00:43 < zooko> But, that's, but,...
00:43 < petertodd> Bitcoin has consensus about the state of the txout set.
00:43 < zooko> Someone who didn't control key-1 could set a value for key-2.
00:44 < petertodd> Sure, but what if we look at the whole set of those keys, and decide which one is canonical based on a PoW?
00:44 < petertodd> Which is what the blockchain kinda does...
00:45 < zooko> Um.
00:45 < zooko> Okay, "what if". My answer is, it might not work, might be complicated and dangerous, and also why would we want that?
00:46 < zooko> The thing where you set-once key1 → (value1, key2)
00:46 < petertodd> Do you understand how the Bitcoin blockchain itself is basically one such key value system?
00:46 < zooko> would be secure.
00:46 < zooko> I think so.
00:47 < petertodd> Good. Now lets repalce the proof-of-work, with proof-of-sacrifice.
00:47 < zooko> So, like I was saying earlier, it seems wise to ask as little as possible from a global consensus system.
00:47 < petertodd> (tied to Bitcoin)
00:47 < petertodd> Sure, but we only have one good global consensus system, and that's Bitcoin, so build on it.
00:47 < zooko> Instead of asking Bitcoin-proper what each person's balance is, we ask it only to reject N-1 double-spends.
00:47 < petertodd> That's irrelevant to zookeyv
00:48 < zooko> Likewise, instead of asking it to decide whether key-1 and key-2 both belong to the same "owner" or authority spehere or whatever, let's just ask it to choose at most one of the "set-once" operations authorized by key1.
00:48 < zooko> Then let's use key1 → (value1, key2) to tie key1 to key2.
00:48 < petertodd> Sure, but step back for a minute....
00:49 < petertodd> Lets suppose you had a Bitcoin blockchain, where instead of the hash-based proof of work, you decided on what was the blockchain based on 
00:49 < petertodd> Bitcoin sacrifices.
00:49 < zooko> I don't see why it matters how the global consensus system decides.
00:49 < zooko> Although, I'm interested in the Bitcoin sacrifices idea!
00:49 < petertodd> It matters a heck of a lot because we have to build the damn thing...
00:50 < zooko> But I don't see why it matters for this.
00:50 < zooko> Hrm.
00:50 < petertodd> Anyway, point is, so you can make a blockchain where the best chain is picked by proof-of-sacrifice.
00:50 < zooko> Okay.
00:51 < petertodd> Now, the transactions that actually sacrifice funds, you can "mark" them in such a way that by examining the Bitcoin blockchain you can be sure to know about every such sacrifice.
00:51 < zooko> Haha! Security firedrill. Hilarious.
00:51 < zooko> Sorry.
00:51 < petertodd> (essentially there is global consensus on what sacrifices have been made for this PoS blockchain)
00:51 < petertodd> lol
00:51 < zooko> Distracted by that...
00:52 < zooko> Okay, so I think I understand... for example, you could spend to an address which is all 0 bits.
00:52 < petertodd> Now because of that consensus, you can be sure that *if* a sacrifice was made to add a block to the chain, you at least know that happened, if not what the contents of the block actually where.
00:52 < zooko> Ugh, I'm sorry, I missed a step again.
00:52  * zooko thinks.
00:53 < zooko> I still don't understand why it matters whether the consensus system that provides the set-once key-value pairs is PrOW or PrOSa. But I'm still interested in PrOSa.
00:54 < petertodd> Again, strictly speaking, it doesn't, but to actually make one, PoS is a *much* better option.
00:54 < zooko> Okay, so to help me understand, let's move back to more like normal Bitcoin.
00:54 < petertodd> Namecoin is k-v via PoW remember
00:54 < Luke-Jr> PoS = proof of stake
00:54 < zooko> Or something else that I find more familiar.
00:54 < Luke-Jr> petertodd: namecoin's k-v is proof of sacrifice
00:55 < petertodd> Pff, proof-of-stake == PoT, because that's what it's proponents are usually smoking
00:55 < Luke-Jr> lol
00:55 < petertodd> Luke-Jr: No, I mean the namecoin blockchain itself, not how you buy a name on it.
00:55 < Luke-Jr> oh
00:56 < petertodd> zooko: Well, I am talking about something like normal Bitcoin...
00:57 < petertodd> I'm describing how in my zookeyv system we determine what is the state of the blockchain.
01:00 < zooko> petertodd: okay, so suppose we have some way to achieve global consensus on a "blockchain",
01:00 < petertodd> see, you're talking on a level different than what I'm talking about
01:00 < zooko> where the relevant thing about a "blockchain" for this purpose is that a blockchain doesn't contain any conflicting set-once's for any key.
01:01 < petertodd> ok
01:01 < zooko> Am I on the right track so far?
01:01 < petertodd> Not really
01:02 < zooko> ☹
01:02 < petertodd> You're getting hung up on what you do with the keys and values, not how you decide them,.
01:02 < zooko> Ah yes.
01:03 < zooko> So, what do you mean "how you decide them"? But don't tell me (yet) about how you would implement it!
01:03 < zooko> Instead tell me what properties it would have.
01:03 < zooko> Who gets to choose what the set-once value for key1 will be?
01:04 < petertodd> But see, zookeyv's underlying model allows for a whole bunch of ways to implement the deciding bit depending on what your problem is.
01:04 < zooko> By "who gets to choose", I hope to be getting at what you were talking about -- how you decide them.
01:04 < zooko> You mean a whole bunch of ways to determine who gets to choose the value for key1?
01:05 < petertodd> No, a whole bunch of ways to decide what the key-value mappings are.
01:05 < zooko> Isn't that the same thing?
01:05 < petertodd> What's more interesting, is how do you do the mappings on top of Bitcoin.
01:05 < petertodd> Because once you have one key-value mapping, you can build upon that to do all kinds of ones.
01:05 < petertodd> (specifically one set once key-value mapping)
01:05 < petertodd> (for the basic reasons Luke was getting at...)
01:06 < zooko> So Bitcoin-proper fits into this model in this way, IIUC: who gets to decide? Anyone who knows a certain ecdsa private key. What sorts of values can they put in? Only highly constrained values -- transactions.
01:07 < zooko> Oh, and a third question: what form can the key take? A highly constrained form -- txouts.
01:07 < petertodd> Sure, but the point is once you create the basic mapping, you can start applying rules to it and what not.
01:07 < petertodd> The fundemental thing is to have the set-once key-value mapping!
01:07 < zooko> Okay, so what policy do you want from your basic mapping?
01:07 < petertodd> But this is the thing, so how would you do a basic key-value mapping on top of Bitcoin?
01:07 < zooko> By "policy" I mean who gets to set which keys.
01:07  * zooko thinks about that.
01:09 < zooko> How *I* would do it is that I would implement set-multiple-times key-value mapping on top of Bitcoin.
01:09 < petertodd> No-no, how would you do the set-once key value mapping? (and it's ok if both key and value are limited to 20 bytes each)
01:09 < zooko> The policy of "who gets to decide" is that anyone who knows a certain private ecdsa signingkey can issue a "set" operation.
01:10 < zooko> Are you saying you'd *prefer* set-once instead of set-many? Or that you think the former would be easier to implement directly on top of Bitcoin?
01:10 < zooko> BTW, my Tahoe-LAFS system is an example of a distributed set-many k-v system...
01:10 < petertodd> No, this is an exercise, tell me how you would implement the former.
01:10 < zooko> Okay, to implement set-once, I would choose the policy to be that anyone who knows a certain secret can issue the set-once for a certain key.
01:11 < zooko> This is Ross Anderson's "Guy Fawkes Protocol".
01:11 < zooko> Whenever you use your set-once, you set the value to a tuple of (value1, key2).
01:11 < petertodd> Ok, so how would that be encoded into an actual transaction?
01:11 < zooko> Oh, well that didn't answer how to *implement* it...
01:11 < zooko> Okay now this is the hard part for me.
01:11  * zooko thinks.
01:11 < petertodd> Yes, I'm big on implementing stuff, er, big on talking about implementing stuff...
01:12 < zooko> ☺
01:12 < zooko> I'm not clear on all the details of the transaction format.
01:12 < zooko> I
01:12 < petertodd> Do you know what a scriptSig and scriptPubKey are?
01:13 < zooko> 'm particularly uncertain about the script opcodes and which ones are not disabled...
01:13 < zooko> Um, scriptSig and scriptPubKey are of that class of things that I *have* momentarily understood more than once in the past.
01:13 < petertodd> Read the thing about scripts/transactiosn on the wiki until you understand - you won't understand zookeyv without understanding them.
01:13 < zooko> But I think I need a refresher.
01:13 < zooko> Which thing?
01:14 < petertodd> https://en.bitcoin.it/wiki/Script#Scripts
01:14 < petertodd> and https://en.bitcoin.it/wiki/Transaction
01:14 < zooko> Will do!
01:14 < zooko> Thanks for the good conversatio.
01:14 < petertodd> np
20:38 < amiller> timestamping isn't inherently enough
20:38 < amiller> for any useful protocol
20:38 < amiller> it's also not enough to assign an ordering to a set of objects determine the order of them
20:39 < amiller> suppose I tell you, here are transactions A, B, D, E, and F
20:39 < amiller> (suppose you agree that the order that they were timestamped in corresponds to the ordinary lexical ordering)
20:40 < amiller> do you see the problem that you might be concerned about the omission of 'C'
20:40 < amiller> suppose later i say also there was C
20:40 < amiller> so actually the valid ordering of events is really A B C D E F
20:40 < amiller> well that didn't contradict the first ordering
20:46 < amiller> a good sign you're going down the wrong track is if you start with "timestamping" as an end in itself, it's more important to consider an entire protocol in which an irrevocable decision is made based on the presence of timestamping evidence, i don't know that i have any in mind
20:46 < amiller> maybe a (admittedly contrived) example is patent law
20:47 < amiller> prior art invalidates a patent, and prior art is basically a timestamp evidence argument
20:47 < gmaxwell> no it's not.
20:47 < gmaxwell> prior art requires _public pratice_, a timestamp is not terribly helpful to you... unless it's, say, a newspaper timestamping itself.. though if your invention is described in a newspaper no one cares about the timestamp.
20:48 < amiller> but just being 'able' to present prior art isn't an adequate system, a lot of prior art goes missed, and so there are some systems in place to try to encourage digging up the prior art through like crowdsourcing (i'll find the nice link in a minute)
20:53 < amiller> so the problem with high compression timestamping
20:53 < amiller> for example just putting a hash of some data in a big ol' merkle tree with tons of other data
20:54 < amiller> and only the root hash is in a public place
20:55 < amiller> is that you can't be sure at any time that some earlier data won't be revealed and preempt whatever you think is the correct order
20:56 < amiller> so if at any finite time you make some irrevocable decision, it's not just based on the timestamp order but also on the order in which they are revealed / circulated
20:56 < amiller> or to give an other example, you could convince people of two separate histories by selectively revealing preimages of timestamped data on a common chain
--- Log closed Sat Jun 01 00:00:54 2013