--- Log opened Thu Oct 17 00:00:16 2013
13:29 < grau> !seen amiller
13:29 < amiller> present
13:30 < grau> hi, did you recon that bribe is possible with the double spend attack I described?
13:30 < grau> in https://bitcointalk.org/index.php?topic=312801.0
13:31 < gmaxwell> I need to ask theymos to do some html obfscuation of the moderator names
13:31 < gmaxwell> it's impossible for me to search for myself on the forum.
13:32 < grau> amiller: ^^?
13:32 < gmaxwell> easier to search IRC: http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/10/25#l1351169953
13:32 < amiller> grau i don't see how you prevent the bribe frm just being picked up by someone else in a different block
13:33 < amiller> becuase ther's no way to mark a tx as dependent on ehgiht
13:33 < amiller> if a seuqence of tx ending in an anyone-can-pay are valid in one fork
13:33 < amiller> you can just take them all and apply them to any other fork too
13:33 < gmaxwell> amiller: sure there is.. and I explained this to you before.
13:34 < grau> you can only apply it if it is valid there but it is not if it was spent
13:34 < grau> the idea is that the bribing transaction is only valid in its fork since it is a double spend
13:35 < grau> on the original fork
13:35 < amiller> i agree you could use that to fork *away* from the original fork
13:35 < amiller> i guess you couldn't force them to be on your fork though
13:35 < amiller> maybe someone would just work on a different fork with both the blacklisted tx *and* the bribe?
13:35 < grau> not forcing but making it rational to be there
13:35 < gmaxwell> amiller: you can do things like pay for a double spend by spending the output of the double spend into a sequence of anyone can spend transactions with progressive nlocktime.
13:36 < amiller> hmmmm
13:36 < amiller> i see.
13:36 < amiller> i remember now thinking that that didn't work when it began with a coinbase, but you could do it generally
13:37 < amiller> you should go in increasing order though raather than decreasing i think
13:37 < gmaxwell> yea, see the link above I told you this before. (And I believe I have a 2011 post on BCT about it, but @#$@#$ search for myself)
13:37 < grau> what distrubs me is that if bribe is possible then it does not matter if you have majority of mining power just if you pay enough
13:37 < amiller> 1 btc for the first block, 2 for the second block on top, then 4, 8 then done
13:37 < amiller> because
13:37 < gmaxwell> grau: if the majority is "greedy", correct.
13:37 < amiller> you wouldn't want people to start fighting until it was basically already settled
13:37 < gmaxwell> amiller: interesting!
13:38 < amiller> so the reward for participating in the next block should always be larger than all the previous blocks since the bribe started
13:38 < gmaxwell> amiller: my thought was that the first one had the largest marginal value.
13:38 < grau> gmaxwell: miner are greedy
13:39 < amiller> grau, for the moment, miners are just *weird*
13:39 < gmaxwell> grau: they are observably not entirely greedy.
13:39 < gmaxwell> yea, "weird" is more accurate.
13:39 < amiller> they're part greedy, part lazy, part nutso
13:39 < amiller> lazy basically means "honest" for the moment since the reference client is pretty fair
13:40 < gmaxwell> well they're also actually part honest. and greedyness can include not wanting the debase their own coins.
13:40 < amiller> yeah.
13:40 < amiller> they're not exactly myopic, they seem to adhere to some kinds of long term interest along those lines
13:41 < amiller> including the up front investment in hardware...
13:41 < amiller> but.
13:41 < amiller> i'm personally comfortable just modeling them as greedy because i think that is what they'll eventually converge on
13:41 < grau> amiller: exactly as more and more capital involved they converge to greedy
13:42 < amiller> and, potentailly worse for us, short-term greedy
13:42 < gmaxwell> Depends on how you define greedy.
13:42 < gmaxwell> Right.
13:42 < gmaxwell> Long term greedy is less concerning.
13:42 < gmaxwell> Long term greedy will probably not reorg the chain for a bit more fees: doing that makes the earned coins (and your hardware!!!) worthless.
13:42 < gmaxwell> Short term greedy will.
13:43 < gmaxwell> (or if not worthless: worth less)
13:43 < sipa> the problem with long term greedy is that it is much harder to quantize
13:43 < sipa> *quantify
13:44 < amiller> the short term greedy miner sells his btc revenue immediately for whatever other currency he likes, like advance on his electricity bill for example, and thus doesn't really need to be worried about the long term stability
13:45 < grau> I question if the number of blocks needed to be sure of a larger transfer should be reconsidered under the possibility of anonymous bribe.
13:45 < gmaxwell> amiller: but if he owns his hardware, he's not going to be so happy about the long term results... unless he can sell that easily too.
13:45 < gmaxwell> grau: they already should have been reconsidered considering pools with 30%-40% hashpower.
13:45 < gmaxwell> BTCguild ends up with 6 block runs with some regularity.
13:46 < gmaxwell> The problem is that if you start crunching the numbers on this kind of thing you end up with rather big numbers.
13:54 < gmaxwell> HOLY CRAP THAT TOOK TOO MUCH TIME
13:54 < gmaxwell> Here is the post I was looking for: https://bitcointalk.org/index.php?topic=20171.msg255631#msg255631
13:55 < gmaxwell> (I also, apparently, posted the same thing in response to claims that security could be paid by "assurance contracts": https://bitcointalk.org/index.php?topic=157141.msg1665607#msg1665607 )
13:56 < gmaxwell> amiller: in any case, we've very close to the coin burning race with this thinking.
13:57 < gmaxwell> amiller: the "if someone double spends you, you make a child transaction that sends all the coins to fees just to make sure the dude double spending you can't turn a profit"
13:57 < amiller> quick offtopic (on topic?) question
13:57 < amiller> does theymos maintain rigours backups of the forum
13:57 < amiller> does anyone else help provide backups of it?
13:58 < gmaxwell> amiller: yes and yes.
13:58 < amiller> maybe bitcoin foundation would want to sponsor archival backups of resources like the wiki and the forums because there's tons of valuable data there
13:58 < amiller> ok
13:58 < gmaxwell> there are backups, encrypted to some set of keys. Some of the global mods have copies.
13:58 < gmaxwell> It would also be nice if the forum merkelized all the posts, and could publish roots that could be timestamped.
13:58 < gmaxwell> Some of the posts may be important in the furture to twarting patent attacks.
14:01 < petertodd> gmaxwell: would it be possible to make public post archives something that can be mirroed directly?
14:02 < petertodd> (in the clear)
14:02 < gmaxwell> You've got me.
14:02 < petertodd> I can certainely write the code to merklize/timestamp it all
14:02 < petertodd> ?
14:03 < midnightmagic> just love how merkle trees are going into everything these days
14:04 < gmaxwell> petertodd: it would probably be a relatively minor modification to the backup procedure to produce a hash root that could be spit out with the backup and timestamped to allow someone with the backup to do selective reveals.
14:04 < amiller> i bought merkletrees.org from namecheap (with bitcoins)
14:04 < midnightmagic> structured storage types would allow data mining if the data were public, too, based on timestamp and username.. forum-wide diffing would be cheap
14:05 < midnightmagic> amiller: glorious :)
14:05 < petertodd> gmaxwell: What form are posts stored in? I assume a mutable database right?
14:05 < gmaxwell> midnightmagic: I don't know that we (or at least theymos) necessarily wants to enable that.
14:05 < gmaxwell> petertodd: I assume. You know as much as I do.
14:06 < midnightmagic> merkle tree + timestamp, username, + link to forum individual message?
14:06 < gmaxwell> My only extra knoweldge of the forum is that I'm a subforum mod in two sections, .. and that means I have access to the staff and donor areas and have talked to theymos a bit more than $random_person. But I don't actually know that much.
14:06 < gmaxwell> Warren probably knows more about how the forums work than I do now.
14:06 < midnightmagic> SMF puts it all into a backend database like mysql.
14:06 < grau> lets be consequent and commit the merkle root of bitcointalk.org to the blockchain :)
14:06 < petertodd> gmaxwell: The 312668.msg3357169 bit in the URL's implies we've got sequential numbers to use.
14:07 < midnightmagic> petertodd: they are sequential numbers.
14:07 < gmaxwell> petertodd: In any case, the backups would obviously seralize messages in some order, so that could get treed.
14:07 < gmaxwell> posts can be edited. so any timestamp really needs to be "as of some backup".
14:08 < midnightmagic> the main drawback of SMF is prior-edits are wiped unless theymos is running something special to version them
14:08 < midnightmagic> (or a logged database backend I suppose)
14:08 < gmaxwell> Can someone else confirm that the forum is hacked again?
14:08 < gmaxwell> Reload as a non admin on the main page or something.
14:08 < gmaxwell> (someone reporting this in #bitcoin)
14:09 < petertodd> gmaxwell: Yeah, well maybe the absolutel easiest would be to just use opentimestamps - I've got code that can do a merkle mountain range where you feed it arbitrary digests, and it gives you top-level-digests to timestamp.
14:09 < sipa> gmaxwell: haven't visited the forum in weeks
14:09 < petertodd> gmaxwell: I'm not seeing anything.
14:09 < sipa> gmaxwell: how do i recognize it being hacked?
14:09 < grau> normal
14:09 < gmaxwell> sipa: some kind of javascript animation? :P
14:09 < gmaxwell> okay, crazy user.
14:09 < gmaxwell> thanks. I wanted to get a confirmation before I called theymos. :)
14:09 < sipa> don't see naything
14:10 < petertodd> gmaxwell: Basically this would give you a database of digests where you can easily extract a tiemstamp proof for an arbitrary digest.
14:14 < amiller> forum seems fine to me?
14:14 < gmaxwell> amiller: thanks, seems like the user has some weird dns issue.
14:14 < midnightmagic> forum is fine here also
14:15 < gmaxwell> petertodd: wrt signed advertisements, I'd assume that you'd sign all of them, and have some priority flag for addresses you consider most credible.
14:16 < petertodd> gmaxwell: that works
14:18 < petertodd> gmaxwell: huh, seems that SMF stores every single post in the database, so it should be easy enough to write a script to dump the posts, hash them, and timestamp them that way
14:19 < gmaxwell> petertodd: sure, I expect it to do that. I was just suggesting that it would go along with the backup data (since you'll need the posts too)
14:20 < petertodd> gmaxwell: yup. Anyway, the only obstacle is getting a copy of the data to work on. I suspect this could be a weekend project otherwise.
14:33 < jgarzik> sipa, gmaxwell: speaking of resetting testnet...  new blocks are appearing every few seconds.  some fool ASIC miner probably aimed his machine at it.
14:34  * midnightmagic suddenly wants to run on testnet.
14:56 < HM2> :}
18:21 < HM2> Hmm, I don't think anyone is going to write a JSON Spirit replacement in Spirit X3 yet
18:21 < HM2> it's riddled with odd behaviour and possible bugs
18:47 < warren> wait huh
18:47 < warren> forum hacked?
18:48 < sipa> not again
19:09 < Luke-Jr> which forum?
19:10 < pigeons> bitcointroll.org is up
19:17 < Luke-Jr> abitcoin.org is too
19:18 < sipa> someone claimed bitcointalk was hacked again, but that seemed incorrect
19:19 < warren> btc-e's top news from today is "Urgent! bitcointalk.org was hacked! Change your password ASAP!"
19:20 < warren> yesterday btc-e was down for a few hours they claim due to a DDoS attack
20:03 < gmaxwell> petertodd: So the MMR UTXO-LOG stuff.
20:03 < gmaxwell> petertodd: ISTM that the transaction sizes would grow forever. Because the spendability proofs would be log2(utxos ever) since you cannot do a storageless rebalance of a MMR.
20:04 < warren> MMR?
20:05 < gmaxwell> merkelized mountain range it's a kind of authenticated binary tree that has ~O(1) append. Its a petertodd neologism.
20:06 < gmaxwell> https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md
20:09 < gmaxwell> warren: petertodd figured out how to make a mostly storageless bitcoin. But there is a trade-off: wallets have to actively monitor the network to process updates to their own utxo proofs or they will lose the ability to spend their coins.
20:10 < warren> that's a bit of a tradeoff =)
20:10 < gmaxwell> But full nodes and miners need basically no storage. (just ~log() hashes with respect to the size of the transaction history, and maybe block headers)
20:11 < gmaxwell> Wallets need storage ~log(total history size) * number of utxos they own.
20:12 < gmaxwell> Transactions must carry utxo update proofs, which are ~log(total history size) * UTXO spent (maybe somewhat smaller if the utxo are near each other in history) in size.
20:13 < maaku> gmaxwell: is this the updatable proofs that we had discussed earlier, if we remove PATRICIA level-compression
20:13 < maaku> ?
20:13 < gmaxwell> maaku: this is a simpler idea that is more general.
20:14 < gmaxwell> warren: if you had a cold storage wallet, for example.. to spend the coins you'd need to get current proofs for it... if you were not tracking them yourself, perhaps you could go find a kind node who has tracked all of them (requiring storage similar to bitcoin full node)... perhaps they'd sell you this data if you show then that your spend would pay them a fee.
20:14 < gmaxwell> maaku: Here is how I'd express the idea.  Forget the UTXO tree stuff.
20:14 < warren> gmaxwell: we talked about this as a way to spend expired coins in the future after litecoin implements expiration
20:15 < maaku> hrm.. i'll study it. lack of a storageless rebalance seems like a big tradeoff :\
20:15 < gmaxwell> maaku: imagine we have just a regular blockchain, and we append new txouts to it as they are created.   We compute a binary tree over this whole thing... using a tree update scheme that has ~O(1) append. (thats the mountain range link above)
20:16 < gmaxwell> When someone wants to spend a coin, they give you a proof that shows you the coin is in the tree. Which is also the same data you need to replace that coin with a "deleted coin" entry and update the root.  (by the same reason we can compose non-compressed proofs)
20:17 < gmaxwell> so miners and full nodes just need to store the leading edge of this tree (log2(history)) hashes. and any transactions they recieve will have enough data to let them mark the inputs elsewhere in the tree as spent.
20:18 < maaku> ok, so it's a perpetually growing tree, although you can safely prune branches that are fully spent
20:18 < maaku> what is the advantage over a proof-updatable index?
20:19 < gmaxwell> Right. and it grows with log() so.... thats no so bad.  Also, proofs for spending recent coins would be smaller. So the proofs for old coins grow.. but recent coins would stay small.
20:21 < gmaxwell> maaku: I think its really simple to implement and understand. If you pretend that all nodes are always online then _no one_ needs to store any third party data at all. Each wallet stores its own proofs.  Walletless nodes and miners store nothing (just log2(history) hashes)
20:21 < gmaxwell> In the real world where not all wallets are online all the time, you'd need some archive nodes that store proofs for other wallets, they'd have storage like a bitcoin full node (a little worse due to tree ineffifiency but no worse than a full history archive)... they could be paid for the service of providing historical proofs for wallets who haven't kept up to date.
20:22 < gmaxwell> (e.g. I write my spend without the required proof, but it also pays you... now you can go provide the proof to make it a valid spend)
20:23 < maaku> i suppose.. i need to think about it
20:23 < maaku> it just intrinsically seems very odd to desire pushing work off of the miners onto the wallet apps..
20:26 < gmaxwell> maaku: The key point is it's not "the work", it's "your own work".
20:26 < gmaxwell> Or at least kinda.
20:26 < warren> maaku: in our case we're thinking about this as a way to make expired coins spendable, which may reduce opposition to expiration
20:27 < warren> allowing the UTXO set to stay small and for old blocks to be pruned
20:28 < gmaxwell> maaku: there is no reason that such a scheme couldn't be coupled with all full nodes also providing the service of storing some of the utxo too.
20:28 < warren> hmm
20:29 < warren> gmaxwell: can this possibly create incentive to run full nodes?
20:29 < warren> the network needs that
20:29 < gmaxwell> This would create an incentive to run "archive" nodes. It would make running a full (verifiying node) dirt cheap.
20:30 < gmaxwell> (storage wise at least, perhaps not bandwidth)
20:34 < warren> well, we do need incentive to run archive nodes
20:35 < gmaxwell> in any case, I'm not sure that bitcoin could ever be evolved into this idea... but its an interesting idea regardless.
20:36 < gmaxwell> the prevelance of spv nodes which would become at least somewhat more expensive in this system, alone would make it hard.
20:52 < sipa> it is a very extreme form of pushing full node computations to clients
20:53 < gmaxwell> sipa: except it changes the scaling order at the same time.
20:53 < sipa> but making full nodes dirt cheap is certainly good for decentralozation
20:54 < gmaxwell> Instead of making all full nodes do work/storage proportional to the number of clients (/txouts/transactions/etc), it makes all clients do ~O(1) work/storage.
20:55 < sipa> right, full nodes are replicated
20:55 < sipa> clients aren't (typically)
20:56 < sipa> so any work moved from full nodes to client may be up to N times more expensive (with N the number of full nodes)
20:57 < petertodd> gmaxwell: remember that in the real world log2() scaling is bounded by k*256, as the universe is finite
20:58 < petertodd> gmaxwell: In addition wallets can always spend their old coins to reduce the size of the proofs, as a MMR isn't log2(history) for proof size, but log2(age)
20:58 < petertodd> gmaxwell: or to be exact, log2(age)*log2^2(history), but the latter term isn't very important
21:01 < petertodd> Something else I'd like to see in such a system is to make all transactions in a block be required to only spend transactions in previous blocks, not the current one, and then create a fixed ordering for txouts in the block. This would let you cheaply prove H(txout) existance, and in addition can be used for sharding. Spending unconfirmed coins is mainly used because you want to pay multiple people in one block interval, and that can always be replaced with transaction re-writing.
21:03 < petertodd> (basically proving that H(txout) exists or doesn't exist in n blocks now costs n*log2(m), not brilliant sure, but that's still fairly cheap and doesn't require full nodes to maintain txout indexes)
21:04 < petertodd> *expensive txout indexes
21:04 < maaku> gmaxwell: my point iswhy pay an external proof-generating service *in addition to* the miners transaction fees?
21:05 < petertodd> maaku: because specialization - why should operating specialist mining equipment and validation also be tied to having huge archives of old block data?
21:06 < petertodd> For that matter, why should fully validating to check for miner fraud be tied to having huge archives of old block data?
21:06 < petertodd> We want validation to be as cheap as possible to keep everyone honest, and we want validation to also have no barriers of entry.
21:07 < petertodd> IE for 1% of the cost, I should be able to validate 1% of the data.
21:07 < maaku> petertodd: miners just need the utxo set, not the full archive
21:07 < petertodd> maaku: The UTXO set can grow without bound, and likely will.
21:08 < maaku> yes, but still "utxo set" != "achives of old block data"
21:08 < petertodd> maaku: With MMR TXO commitments we can stop hassling every idiot who bloats the UTXO set, and for that matter, they aren't idiots anymore...
21:09 < petertodd> maaku: the UTXO set needs to be stored in full to be useful, so it's a bigger ultimate burden than old block data archives which can be partially stored and still be useful
21:09 < maaku> petertodd: no, it doesn't. you can do a proof-updatable version of the utxo indices
21:09 < maaku> where transactions come with proofs-of-inclusion for their inputs, and update proofs for their outputs
21:10 < petertodd> maaku: But without UTXO existance proofs you still need full nodes to store the UTXO set, and at that point MMR TXO commitments are much simplier.
21:10 < maaku> you can do utxo existence proofs though. that's what i was asking gmaxwell about - MMR vs UTXO-with-updatable-proofs
21:11 < petertodd> Yes I know - I thought of that idea ages ago myself, as did many other people. MMR TXO commitments are simpler is what it comes down too.
21:13 < maaku> meh, i'm not so sure about that. the index bip i'm working on is rather simple, and indexing offers additional benefits... what i'm trying to figure out is if there are things you can do in MMR which you can't in UTXO-with-updatable-proofs
21:13 < petertodd> The things you can't do are obnoxious things, like making parasitic consensus systems able to take advantage of the UTXO indexes to easily store their data.
21:15 < maaku> i think you can do the same in MMR
21:16 < maaku> as far as I can tell, the MMR tree is the same as the UTXO index, just (1) keyed by insertion order, and (2) spent outputs are left in place, right?
21:16 < petertodd> Nope, in MMR they either can't at all, because you implemented it without sorting at all, or they need to scan the chain.
21:16 < maaku> well it depnds on the app. you can still make proofs showing data inclusion, which is what I thought you meant
21:17 < petertodd> Yes, and on disk you literally end up with a huge file that you append too, and modify in place, and once enough outputs are spent you can drop sections of the file. Remarkably you can implement it with sparse files!
21:17 < petertodd> maaku: with UTXO proofs + what people want for SPV wallets getting my data is as simple as asking the next full node "hey, what txouts match <prefix>?"
21:17 < petertodd> maaku: (specifically I'm talking about what you're implementing)
21:20 < petertodd> Anyway, the key thing is can you do a UTXO commitment scheme, where you can expire old UTXOs? Because I couldn't figure out an efficient way to do the updates; maybe you can.
21:21 < amiller> i don't understand how you use mmr as a utxo
21:21 < petertodd> Like, if 99% of my UTXO's are long dead, can I still generate the UTXO tree efficiently, and still be able to throw away the majority of the data?
21:21 < amiller> i keep reading the page and i don't get it
21:21 < amiller> how do you prove it's still unspent if it isn't removed?
21:21 < petertodd> amiller: You prove that it hasn't been marked as spent.
21:22 < maaku> petertodd: yes, basically the same scheme with transactions carrying their own proofs, updated by owners or archive services for a fee
21:22 < maaku> the update itself requires no level-compression of the hash calculations
21:22 < maaku> but you can still store level-compressed tree on disk
21:22 < maaku> and just expand the skip-list into a sequence of internal nodes
21:22 < petertodd> maaku: Right, but to insert a new TXO in a radix tree I still need a lot of intermediary digests.
21:22 < maaku> so a 256-bit key requires 256 hash operations to authenticate
21:23 < amiller> petertodd, so it requires log n digests/modifications to mark it as spent?
21:23 < petertodd> maaku: Whereas for a TXO MMR appending a new TXO is cheap.
21:23 < maaku> yes, although it's also O(1) ... just with a constant factor of 256
21:23 < petertodd> amiller: correct
21:23 < petertodd> maaku: appending is O(1), with a constant factor of 1
21:23 < petertodd> (in MMR TXO commitments)
21:24 < amiller> who cares if appending is cheap if updating is log n anyway?
21:24 < amiller> i guess it's nice..
21:24 < petertodd> Also in MMR TXO commitments in the general case, where your spending recent coins, the proof size stays small, whereas in UTXO radix trees the proofs get much larger.
21:24 < maaku> petertodd: given the availability of CPU-accelerated sha256, and/or GPU acceleration, i'm don't give much weight either way
21:24 < petertodd> amiller: But it's not, it's log2(age), which is much cheaper than log2(total # of transactions)
21:25 < petertodd> maaku: bandwidth is what matters, and MMR TXO keeps bandwidth down
21:25 < petertodd> maaku: CPU/GPU whatever is completely irrelevant compared to bandwidth
21:26 < petertodd> For instance if I respend a TXO that confirmed 4 blocks ago, my proof size is only k*2!
21:26 < maaku> petertodd: yes, i'm in agreement on bandwidth vs processing
21:26 < maaku> but log2(age) is not necessarily cheaper than log2(# *unspent* transactions)
21:27 < amiller> petertodd, is this deterministic structure
21:27 < amiller> it's not randomized?
21:27 < petertodd> amiller: Yes actually, 100% deterministic consensus.
21:28 < amiller> the sturcture depends only on the number of elements and nothing about the contents of the elements i mean
21:28 < maaku> amiller: yes, as far as i can tell
21:28 < petertodd> maaku: Well, it's worth measuring, but keep in mind that there's lots of useful things you can do with UTXO abuse, and I'd rather we get out of the game of lecturing everyone about it.
21:28 < petertodd> amiller: Yup.
21:29 < amiller> i still don't see it
21:29 < amiller> do you have any more illustrations
21:29 < amiller> of like insertions 1 through 10
21:29 < petertodd> amiller: did you see gmaxwell's link on my paper about MMR's?
21:29 < amiller> or psuedo code for insertion
21:29 < amiller> i don't care about the hashes just the tree is fine
21:29 < petertodd> //github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md
21:29 < amiller> yes i have been reading that
21:29 < amiller> yeah i got that
21:29 < amiller> i can't understand it
21:30 < amiller> pseudo code for append plz
21:30 < petertodd> OK, so get out a piece of paper, and put a bunch of dots along the horizontal axis. Now from left to right, pair a few dots, then pair those pairs etc.
21:30 < maaku> amiller: just imagine a standard Merkle list
21:30 < maaku> but without satoshi's weird handling of the last element, so it's O(1) updatable
21:30 < maaku> on an append at least
21:31 < petertodd> hell, here's python code that actually implements it: https://github.com/opentimestamps/opentimestamps-server/blob/master/otsserver/dag.py#L203
21:31 < petertodd> maaku: yeah, what's interesting is the naive way of building a merkle tree, going left to right and just promoting the left most odd element, naturally gives you a MMR
21:32 < petertodd> maaku: All I've done is observed that you can cheaply build it incrementally and deterministically, as well as update it cheaply and deterministicly.
21:32 < petertodd> *right most odd element
21:32 < amiller> https://github.com/opentimestamps/opentimestamps-server/blob/master/otsserver/dag.py#L396 i can't understand how this is O(1)
21:33 < petertodd> amiller: The append? technically it's O(log2(log2(n)) for n elements
21:33 < maaku> petertodd: yeah the way bitcoin actually does Merkle trees only makes sense because of the weirdness of how it's done using C++'s vector<> type
21:33 < amiller> oh
21:33 < petertodd> amiller: O(1) for short :P I mean, seriously, log2^2(n) does *not* grow very fast...
21:33 < maaku> i spent a long time trying to make sense of that when i first encountered it
21:35 < petertodd> maaku: Now what I don't get, is how can I update a UTXO radix tree without storing nearly all of it? Like suppose I have an ancient tx0, and I add tx1 where numerically tx0 and tx0 are very close to each other - how do I update the tree without having H(tx0)?
21:35 < amiller> still don't see why it's not log n
21:36 < petertodd> amiller: Not log n for append?
21:36 < amiller> right
21:37 < petertodd> amiller: Appending needs to touch only the "mountain tips", that is the perfect merkle trees already stored, and for n items stored you'll have log2(n) trees. (roughly)
21:37 < petertodd> amiller: I mean, it's actually whatever is the expression that gives you the number of perfect trees on average in n, but log2(n) is pretty close to that.
21:38 < amiller> then how do you get loglog n instead of log n
21:39 < maaku> petertodd: i'm not sure i understand the question. what you do to update proofs is walk the pruned proof-tree updating the pruned branches, as necessary
21:39 < petertodd> amiller: oh, sorry, I mispoke, so if you have n items, because the first perfect tree has log2(m) items, where m is whatever is the largest perfect tree, then the next largest, and so on, in total the number of perfect trees is about log2(log2(n))
21:40 < petertodd> maaku: But that's it: I want a system where to be a full validating node you don't need to store the whole UTXO set.
21:40 < petertodd> maaku: Er, I mean, a mining node.
21:40 < petertodd> maaku: With UTXO radix trees you can validate, but you can't update the UTXO set.
21:40 < maaku> petertodd: where did I say you need the full set? you don't
21:41 < maaku> require incoming transactions to have their own proofs
21:41 < maaku> mempool proofs can be updated with using the delta-proof the blocks, as they come in
21:41 < petertodd> maaku: That covers spending a transaction, but it doesn't cover making a new transaction output.
21:41 < petertodd> maaku: I can delete items from the UTXO set but I can't add new ones basically.
21:42 < maaku> petertodd: ? work it out, it does work
21:42 < amiller> if i have 2^5-1 elements, i have a perfect tree of size 2^4, a perfect tree of size 2^3, etc.
21:42 < amiller> that's log, rather than a log log, number of trees?
21:42 < petertodd> maaku: I have tried to work it out, and I just don't see how it's possible. I mean, look at it this way, if you have *none* of the UTXO set data other than the last top level commitment, can you add a new txout to it?
21:43 < amiller> maaku, with utxo commitments of any kind, you never need to store the whole utxo set to validate a tx that comes with a proof
21:43 < amiller> a validating node doesn't just get given raw transactions and told to look it up
21:43 < maaku> petertodd: yes, because the update proof would consist of the path through the *last* index to where the output is to be placed, and then the data to put there
21:44 < amiller> it's given transactions and proof
21:44 < amiller> maaku, now the quetsion is what's required to take a raw transaction and build a proof
21:44 < petertodd> maaku: There is no update proof! It's a brand new txout.
21:44 < amiller> maybe you don't want an spv node to have to do it themself
21:44 < amiller> maaku, but suppose you are a storing node that has clients
21:44 < amiller> customers i mean
21:44 < amiller> for each addrses you care about, you may have to store up to 256 digests to support creating a proof for any transaction they have
21:44 < maaku> amiller: yes, someone somewhere needs to store the relevant paths to access coins in the utxo structure
21:44 < amiller> per coin they have
21:44 < amiller> maaku, yes but no one has to store *all* of them
21:45 < maaku> amiller: agreed
21:45 < amiller> each person interested in a utxo may have to store (and update) the proofs relative to those
21:45 < amiller> but they're not too many
21:45 < maaku> amiller: yes
21:45 < petertodd> amiller: Meh, call it appends are log2(n) if you want. :) I'd have to think through that one carefully, but anyway in any real situation there will never be more than, IIRC, 16 mountains or something like that so it's always pretty cheap.
21:45 < maaku> amiller: what are you arguing against?
21:45 < amiller> petertodd, well, it depends on whether they're growing unboundedly?
21:45 < amiller> i guess still ther'll never be too many
21:45 < amiller> but yes i'll call it log n until i'm convinced otherwise :3
21:46 < petertodd> amiller: Yeah, you can see how it's certainly less than the log2(n) height of a tree.
21:46 < maaku> amiller: it wouldn't be 256 digests - the proofs are stored level-compressed, so it's log2(unspent outputs)
21:46 < amiller> that assumes they're random
21:46 < amiller> which is maybe
21:46 < amiller> but sure
21:47 < amiller> also if you do it level compressed you can do the concurrent proofs but w/e
21:47 < petertodd> maaku: Basically you're describing a system where someone has to have every single historic UTXO ever created just in case someone happens to need to create a new UTXO that happens to be adacent to it in the radix tree, and that's not good.
21:47 < maaku> amiller: *stored* level-compressed, but expanded when used
21:47 < amiller> ok
21:48 < maaku> petertodd: no, i'm not. maybe you'll just have to wait for the bip to see
21:48 < petertodd> maaku: Whereas MMR TXO commitments are a system where you can throw out every bit of blockchain history, and still add new blocks.
21:48 < amiller> petertodd, oh, i see, you're right
21:48 < amiller> that's a good point
21:48 < amiller> you don't know what to hold on to
21:48 < amiller> in order to create a new address
21:48 < amiller> when you create a new address it's random bits
21:48 < maaku> to create a transaction you need *just* the path through the utxo set to your outputs
21:48 < petertodd> amiller: Yeah, you absolutely need the adjacent UTXOs to create the proof of modification.
21:48 < amiller> you'd have to go find people to query for each branch
21:48 < amiller> it's possible that the only people who had a relevant branch have gone and died
21:48 < petertodd> maaku: Yes, and that path needs at least one adjacent UTXO, which can be of any age.
21:48 < amiller> no one cares about them and they don't care about their coins
21:49 < amiller> but now it's a hazard for anyone creating a new address
21:49 < amiller> merkle mountain range fixes that just fine
21:49 < amiller> mmmm +1 insertion order sorted tree
21:49 < petertodd> amiller: Lol, I like the way you're describing it as a sorted tree. :P
21:50 < petertodd> amiller: Fortunately for the purposes of expiration it's sorted in the right order!
21:50 < amiller> every tree has a sort order, just sometimes it's a random permutation :o
21:50 < petertodd> amiller: Or I should say, pseudo-expiration.
21:50 < amiller> you can immediately forget it all
21:50 < amiller> it's great
21:51 < petertodd> amiller: Ha, yeah, it's one of those crazy systems that's almost too good: if everyone can forget it immediately, we damn well better hope someone doesn't.
21:51 < amiller> nah
21:51 < amiller> you remember if you care
21:51 < amiller> if you don't care then you forgot your private key anyway
21:51 < amiller> now here's the trouble is
21:51 < petertodd> amiller: Fortunately I think you can securely do a "pay to help me get this ancient txout mined" service with a joint transaction.
21:51 < amiller> you can have updates
21:51 < amiller> and if you aren't relatively alive to hear the updates
21:51 < amiller> and eveyrone forgets intermediate state before you get yours
21:51 < amiller> then you might not be able to find it from anyone
21:52 < amiller> say you send a new coin to yourself, then you go into a coma for 50 years, then come back
21:52 < amiller> can you spend your coin
21:52 < amiller> all the tips have changed
21:53 < petertodd> amiller: Yeah, it absolutely could happen, although it's likely there will always be at least one person with a copy out there somewhere.
21:53 < amiller> kinda?
21:54 < petertodd> The other thing is that keeping your wallet updated is actually depecently cheap because you only need to watch for transactions that modify your proof. In addition if you update your proof once, the chain data you need to update it again is much lessoned - just the transactins that changed the lower part of your proof as the upper part is more recent.
21:54 < amiller> maybe you still want to do proof of storage over the whole tree to be sure
21:55 < petertodd> amiller: Yeah, it's hard to say... I suspect that given that everything is easily fraud proofed, we can skip proof of storage so long as finding fraud is rewarded somehow.
21:55 < amiller> no i mean
21:55 < amiller> you want to encourage people to store the data
21:55 < amiller> if it's plausible that someone who should be enabled to spend it might not have that data
21:55 < petertodd> amiller: Right, but the "pay to spend" system works fine for that.
21:55 < maaku> ok i see what you're saying now, but i hadn't thought it was a concern since the signer has control over the transaction id... they can always pick a new one that they can find a path for
21:55 < amiller> no it doesn't
21:55 < amiller> you can pay to spend if someone has the data
21:56 < petertodd> What we need is to encourage people to *validate* the data, which != storing it.
21:56 < maaku> assuming they don't pay an archive node to find a path for them
21:56 < amiller> but you can't pay them ahead of time to store it and update it forever
21:56 < amiller> okay here's a  thing is
21:56 < petertodd> maaku: Yeah, but that basically means those archival nodes need to be found every !@#$ time you create a transaction, or even for that matter just to add coinbase outputs to the set.
21:56 < amiller> maybe if i know i'm aobut to go into a coma or am afraid of it
21:56 < amiller> and want to purchase go into coma for 50 years insurance
21:56 < petertodd> amiller: No, but they can make a business decision that there's enough demand. And anyway, as I said, updating your proofs is incremental.
21:57 < amiller> i can sponsor a bounty that rewards people over time for doing proofs of storage of whatever is the most valid node
21:57 < amiller> it doesn't matter if it's incremental if the point is that i go away for a long time then come back
21:57 < amiller> i'm not interactive and receciving updates during that time
21:57 < petertodd> amiller: Well, you know how you do that? You create nLockTime'd transactions! To spend the txs way in the future they have to prove them!
21:58 < petertodd> When they brodcast the proofs, you can reuse that data to prove your own transactions!
21:58 < petertodd> *broadcast
21:58 < amiller> that's not a great solution for minor economic reasons and periodic proofofstorage is better somewhat
21:58 < amiller> if it seems like you have a poor chance of being the winner then there's no reason to do it
21:59 < petertodd> But this is the thing, we *want* people to be able to expire ancient data! Think 300 years in the future when transactions in the first 10 years of blocks just don't ever happen.
21:59 < petertodd> This is the only thing that can keep the blockchian data required to mine from growing without bound.
21:59 < amiller> i agree that this should be set by market forces of people who want it or are willing to insure themselves
21:59 < amiller> if i go into a coma and haven't paid for lifesupport then it's my problem
21:59 < amiller> if i or someone gracious wants to pay somehow to keep my data validated then ok
21:59 < petertodd> Yeah, and market forces are enough, we do *not* need to add proof-of-storage to the consensus protocol.
22:00 < petertodd> Where as with UTXO commitments, you absolutely do need proof-of-storage.
22:00 < amiller> i'll let that slide for now
22:00 < amiller> petertodd, yes, agreed, because with the utxo trie you never know *which* bits you'll need for appending new data
22:00 < amiller> which is an outstanding revelation
22:01 < gmaxwell> 18:04 < maaku> gmaxwell: my point iswhy pay an external proof-generating service *in addition to* the miners transaction fees?
22:01 < gmaxwell> Right now, ~no one is paid for it. And miners (if you mean the guys who own asics)
22:01 < gmaxwell> don't do it at all... you could argue that the pool op is paid for that
22:01 < gmaxwell> service but it's only as an accidental side effect, and it highly incentivizes
22:01 < gmaxwell> centeralizing that ability. vs letting each user keep their own or pay for
22:01 < gmaxwell> their own retrevial very naturally scales and doesn't create a
22:01 < gmaxwell> centeralization incentive, I think.
22:02 < petertodd> amiller: Yeah, MMR TXO also naturally has good access requirements, which mean that archiving data to tape and so on is very practical.
22:02 < petertodd> amiller: (even when you want to be the "help me mine my txout" service)
22:03 < petertodd> gmaxwell: Did you see how paying to help get a txout mined can be done in a trust free manner too? Just create a transaction spending the txout that gives some BTC to the service - if they can't get it mined they don't get paid.
22:03 < amiller> that's a crap solution
22:03 < petertodd> amiller: ?
22:04 < amiller> it's not good for replication
22:04 < petertodd> amiller: Why do you need to replicate?
22:04 < amiller> like, you'd prefer to have the reward for that paid in some way that encourages several people to have it
22:04 < amiller> because that service doesn't have terribly much incentive to store it redundantly
22:04 < amiller> they'd miss out on the future rewards i suppose
22:04 < petertodd> amiller: Well sure, but frankly that's impossible with math.
22:05 < amiller> no it isn't
22:05 < amiller> that's what pow does
22:05 < gmaxwell> petertodd: well almost. Say you make two versions, one paying a and one paying b.   A fails to do the lookup. B does it. When A hears the transaction from B he can attach B's proof.  ... find for the user bad for the service.
22:05 < amiller> that's the whole point of this massively replicated apparatus we have
22:05 < petertodd> amiller: No, proof-of-work simply proves a bunch of work was done, it doesn't prove that the work was done in a geographically separated set of disaster resistant datacenters.
22:05 < amiller> it doesn't *prove* that, but it *causes* that
22:05 < amiller> that's exactly what it causes
22:06 < amiller> incentivizes, rather
22:06 < gmaxwell> amiller: thats the users own darn problem, if he wants great storage he can pay for it. Importantly, it doesn't have the commons resource problem of making everyone pay for something that only benefits one user.
22:06 < petertodd> gmaxwell: Yeah, those services are going to want to either mine the txs themselves, or have meatspace contracts.
22:06 < amiller> agreed with both of those
22:06 < petertodd> gmaxwell: Well, actually you can fidelity bond those contracts...
22:07 < petertodd> amiller: I dunno about causes that... just look at pools...
22:07 < gmaxwell> yea, and it's super cheap to maintain your own if you're already running a FVN
22:07 < amiller> petertodd, pools are geoseparated disaster resistant data centers, it's hosted mining that's the problem
22:07 < gmaxwell> and to have tit for tat mutual watching agreements in communities of interested.
22:08 < petertodd> amiller: Pff, we're talking like a dozen pools at most - that's not very convincing disaster resistance compared to the thousands (probably) of full nodes.
22:08 < amiller> petertodd, no i mean the pool operators don't matter, the fact is pool participants all have gpus at their homes
22:08 < petertodd> amiller: Anyway, as gmaxwell said "It's your own fucking fault if your wallet becomes unspendable!"
22:08 < amiller> if you make a storage hard pow then it's the mining devices that are the replicated storage
22:08 < petertodd> amiller: GPUS != blockchain data
22:09 < petertodd> amiller: ok, true, but we're not changing the proof-of-work algorithm
22:09 < petertodd> amiller: maybe in some alt-coin
22:09 < amiller> yes you are, when it becomes obvious you have to
22:09 < petertodd> gmaxwell: sorry if I slightly misquoted you there :P
22:09 < amiller> what i'm *not* saying is that you'd have to make it mandatory that the consensus puzzle is over the whole merkle thing
22:09 < amiller> one option is to make it so you can pay to have it included
22:09 < gmaxwell> releastically the required redundancy for txout data is only three or four copies, lets say. But for decenteraization we need tens or hundreds of thousands of full nodes.  And the risk of not having enough copies should be born by the owners of the data which was inadequately replicated but bitcoin makes it a risk for the whole network.
22:09 < petertodd> amiller: people in comas for 50 years waking up to not being able to spend their wallets isn't a good reason :P
22:10 < amiller> so you can pay to have whatever replication factor you want
22:10 < amiller> i'm not arguing any particular solution here because it's not settled
22:10 < amiller> i'm just saying that including it in a storage proof of work puzzle of some kind is an approach to getting replication, which is closer to what you want than just paying one service specific
22:11 < petertodd> Problem is replication factor is a human thing, and it *can't* be proven with a proof-of-work. Sure you can make a storage hard proof-of-work that kinda sorta implies it, but it tells us nothing about how many data centers need to burn down.
22:12 < amiller> the point is i agree that the cool thing about this is that it's not the network's problem if your old data is forgotten, and it can be up to the individual user to take appropriate precuations to pay people to store the relevant data in the right way
22:12 < amiller> we're all in fierce agreement here
22:12 < petertodd> I suspect in reality the "pay to get my txout mined" is more than sufficient to get at least a dozen full copies out there, and remember that if you leave your computing running, even as a partial node, you can both contribute to the validation effort and keep the proofs for yoru txouts up-to-date.
22:12 < gmaxwell> yea, and it's tricky to not create huge outsourcing or consolidation benefits that way. amiller: your best solution against outsourcing requires some pretty tricky economic reasoning on the part of miners which is currently disproven by existing practice (not just in bitcoin but in every place humans transact— no one ever demands cryptographic proof of anything)
22:12 < amiller> insertion-order-sorted merkle tree is outstandingly cool in this regard
22:13 < amiller> or MMR if you prefer :3
22:13 < gmaxwell> petertodd: well and a logical thing is to also include kind of DHTish recovery service. E.g. randomly keep X gbytes worth of data, so you can have a chance to partake in people paying for recovery.
22:13 < petertodd> Ha, hey, I dedicated Merkle Mountain Ranges to all the hikes in the Canadian Rockies I've had with my dad, so I'm fighting to make the name stick. :P
22:14 < amiller> i'm okay with that :)
22:14 < petertodd> amiller: Hey, at least I didn't call it Todd Trees.
22:14 < amiller> lol
22:14 < gmaxwell> amiller: MMR also implies that you care about the cheap insert rule. :)
22:14 < petertodd> gmaxwell: Yeah, and the "DHT" in this case needs nothing more than sipa's block ranges really - it'd be a long time before the DHT actually needs routing.
22:15 < amiller> i'll consider that MMR refers to not just the data structure but all the implied good properites it has :)
22:15 < gmaxwell> petertodd: yea, locality is good as it reduces the storage and computation required.
22:16 < gmaxwell> I wish sharding it were easier, but there are weird fungibility problems with sharding.
22:16 < petertodd> gmaxwell: I'm pretty sure I can do a sharding scheme that doesn't have fungibility issues actually, although it will have scary fraud issues.
22:17 < gmaxwell> you are not helping my confidence there!
22:17 < petertodd> gmaxwell: It'd also have 51% attack issues given we need a market for transaction fees... although I think with my "per-tx pow" scheme and some proof-of-stake sprinkled in it just barely works...
22:18 < gmaxwell> it works if you have a hierarchal currency. E.g. a master coin that everyone validates. And then shard coins. And you can only spend within shards and between shards and master.  But that hurts fungibility.
22:18 < petertodd> gmaxwell: Yes, multiple currencies makes it really easy. I think on the forum I gave the toy example of a circular set of currencies, where mining always mined an adjacent pair basically.
22:19 < petertodd> (good post to timestamp come to think of it...)
22:20 < amiller> i'm beginning to think even fungibiility doesn't matter asm uch
22:20 < amiller> one thing i've been worrying about with, say, ripple or color coin currencies is how you pay the miners if they don't care about your currency
22:21 < amiller> but you *don't* have to pay all the miners, you only need to pay enough of them
22:21 < amiller> you can mine your own irrelevant transactions if you can afford the cpu but no one else likes your currency
22:21 < amiller> the more broadly valuable your sillycoins are the easier it is to convince all the miners to include it
22:22 < petertodd> amiller: With wallet support it'd be easy enough to paper over the fungibility problems by just trying hard to keep the user's wallet well balanced, and accepting that some transactions take a few more confirms.
22:22 < amiller> sure
22:22 < amiller> you can have an automated portfolio of colored coins too
22:22 < petertodd> amiller: Someone more versed in graph theory than me could probably come up with some scheme where you have log(n) steps to spend any coin.
22:23 < amiller> you could have an altcoin that had proof of work mining, no startup bonus, only self issued currencies, and fees are just paid in IOUcoins of any user's discretion
22:24 < amiller> the only problem is that we don't have much reason yet to be confident that the whole consensus thing works with the current system with all the block bonuses removed
22:24 < petertodd> amiller: Well, do you understand my circularly set of pair-wise-mined currencies example?
22:24 < petertodd> amiller: You can still have block bonuses their.
22:25 < amiller> block bonuses are gonna go away anyway so the question is are voluntary transactions fees just to the miner good enough
22:25 < amiller> i like the idea that eventually you'll have to bribe the next miner to build on your block rather than 'discouraging' it
22:26 < petertodd> Yeah, and anyway to make such schemes work we have to get fraud proofs to work well, and I think right now TXO commitments are the logical way to do that...
22:28 < petertodd> One interesting thing about all this stuff, is suppose we got a nice, shardable, ultra-decentralized currency: I suspect we'd want a token system, with fixed values, so that the transactions related to the lowest value tokens moving around can be reglegated to the lowest security chain.
22:28 < petertodd> Otherwise the whole thing just becomes a nice way to instant-message your friends...
22:28 < amiller> petertodd, no the trick is insurance
22:28 < amiller> i sort of have an idea of how navigating the multi hierarchy currency works
22:29 < amiller> the main questions is how you exchange value from a small currency to a larger one
22:30 < amiller> like even if you have a locally-meaningful currency, it's still beneficial to have a broader audience observe the transactions
22:30 < petertodd> See, I'm thinking of a system where for a long, long time, the "1 satoshi" chain has basically no attention paid to it so fraud is rampant and people don't trade in single satoshis.
22:31 < petertodd> Because if you *can* cheaply trade in single satoshis, securely, then what stops me from timestamping everything? At some point something needs to break down, and there needs to be some way to "communicate" back the cost of the whole system to it's users.
22:31 < petertodd> There Ain't No Such Thing As A Free Lunch!
22:32 < amiller> i think we vaguely agree again :)
22:32 < gmaxwell> shard by txout value.. interesting.
22:32 < gmaxwell> but that creates a linear hieararchy which is kinda lame.
22:32 < petertodd> Yeah, I think it'd probably work best with some kind of storage-hard proof-of-work, especially if it can somehow be directly related to validation.
22:33 < petertodd> gmaxwell: Maybe it doesn't need to be linear? Maybe it's just opportunisticly sharded, IE you mine whatever part of the UTXO set that you want too, and we use fraud proofs to keep people honest.
22:33 < petertodd> A worthless chain won't have many people actually validating it, so every so often someone will get away with fraud, or the data will get lost and coins will become unspendable.
22:34 < petertodd> Conversely the 2^32 satoshi chain is actually economically important, and it's basically impossible to get away with fraud.
22:34 < amiller> sorry in advance for the following ramble but just be glad it's not in bitcoin-dev
22:34 < petertodd> All those chains can operate in lock-step too, so atomic transactions are still possible. (though exchanging a 2x 1 satoshi tokens for a 2 satoshi token won't be possible)
22:34 < amiller> what strikes me as really strange is that with the bribery/incentive/rational modeling it seems like we're headed towards a system that works even if people just do wahtever benefits them
22:35 < amiller> what's the role of the protocol or constitution in that case?
22:35 < amiller> what's even the need for a correct set of rules if following them is optional but just benficial by default somehow
22:35 < amiller> and i wonder if the explanation is that it's arbitrage of some kind between two kinds of rationality
22:35 < amiller> there's like the immediate greedy decision that you'd make fully anonymously
22:36 < amiller> and a separate kind of policy that you want to enforce on everyone else
22:36 < amiller> like it's easy to show support for a certain rule when it's probably not going to affect you anyway, like by building on someone else's block
22:37 < petertodd> I'll warn you, I'm this close to inviting you to #postmodern-bitcoin... :P
22:37 < amiller> likewise it's easy to deviate from the rule when the benefit is clear
22:37 < amiller> yeah well
22:37 < petertodd> heh, though go on :P
22:38 < amiller> that was the end of the thought i guess
22:38 < amiller> sometimes there's a new datastructure at the end, not this time
22:39 < petertodd> gmaxwell: Oh, and you know, what's really interesting with multiple powers of two token chains is that MMR TXO commitments are the perfect data structure for them, given the mandatory data required to mine a new block is very small, and they can continue even if all the data is lost.
22:40 < gmaxwell> well.. there is less need to shard if full verifying requires little state.. the primary advantage is potential bandwidth.
22:40 < petertodd> amiller: Yeah, the meta-protocol/constitution really is then "what is the protocol for convincing other people to use my protocol/continue to use it"?
22:41 < petertodd> gmaxwell: Right, but remember I'm assuming no explicit transaction rate limits, so at some point something goes to infinity.
22:41 < petertodd> gmaxwell: Which means at some point one of the low value chains isn't secure.
22:42 < petertodd> amiller: As for incentives, I think any of these systems *must* work even if all participants are only short-term rational, and should work even if what the participants goals are varies hugely.
22:42 < petertodd> amiller: for instance we must be able to deal with data-spam with technical, rather than sociological measures
22:42 < amiller> we don't yet have a satisfactory explanation for the circular value argument of currency tokens as money
22:43 < amiller> the appeal of the commodity value money is that it starts somewhere
22:43 < amiller> here the simplest explanation is you can use the money to pay tx fees
22:43 < petertodd> amiller: sure we do, Rai stones are heavy!
22:43 < amiller> that just shows that there's a social demand/benefit for some mechanism of exchange
22:43 < amiller> it doesn't actually help you design an optimal system
22:44 < amiller> we're still making models of gold at this point
22:44 < petertodd> amiller: I think the more interesting question is what happens as tx fees rise/how much are people willing to pay for security?
22:44 < amiller> they're valuable because you can bribe miners with them and you can bribe miners with them because htey're valuable
22:45 < amiller> yeah there's that whole paying-for-system-security-is-eveyrone-else's-problem
22:45 < petertodd> proof-of-work is ugly because the total cost of the work needs to be some small % of the total value of the system, but in Bitcoin that means destroying it costs a small % of the total value of the system... systems incorporating proof-of-stake could in theory be better, requiring up to the total value of the system to destroy, but it's unclear how to actually build them
22:45 < amiller> yeah i agree with that
22:45 < gmaxwell> #include <unworkability_of_pos.h>
22:46 < petertodd> gmaxwell: I'm actually thinking that proof-of-stake can be used in conjunction with proof-of-work, especially if you have a jam-free network available
22:46 < amiller> my intuition is that there's a great theorem in here somewhere that you *have* to burn something of *objective* value, i.e., computational energy, in order to defend against an anonymous attacker
22:47 < gmaxwell> amiller: I agree.
22:47 < petertodd> gmaxwell: *relatively high bandwidth jam-free network
22:47 < amiller> if you have a proof of stake then it's a guarantee that there's a trusted party lurking somewhere
22:47 < gmaxwell> petertodd: yes, also, make me god of the universe and all this can work too... lots of things are easy when you can just pick preconditions. :)
22:47 < petertodd> amiller: Yes, but can we divise a system where you burn computational energy from the past, or *must* it be computational energy you burn *now*?
22:48 < amiller> i think it can't be from the past i think it has to be a present decision where you have the option of not burning it but benefiting it
22:48 < petertodd> amiller: Because if it can be computational energy you burn in the past, you can defeat 51% attackers by sacrificing your own coins in opposition.
22:48 < gmaxwell> petertodd: only if you have a perfect system for accounting for stored value, which we don't have as we're trying to build one.
22:48 < petertodd> amiller: IE replace-by-fee scorched earth applied to whole blockchains
22:48 < amiller> yeah you can sacrifice your own current coins by buying hashpower now
22:48 < gmaxwell> and yea, the works too.
22:49 < gmaxwell> thus checkpoints-in-txn-that-gate-fees.
22:49 < petertodd> gmaxwell: Yes, the chicken-and-egg problem is ugly but... with a infinite bandwidth jam-free network it certainely could be done, as you'd always know what coins got sacrificed by the defenders.
22:49 < petertodd> amiller: yes, but that's slow
22:49 < amiller> no it isn't?
22:49 < amiller> it's immediate
22:49 < gmaxwell> petertodd: Also works if you first covert me into a computer program, then convert all mass in the solar system for me to run on, and then upload everyone else into me. I promise. It'll be great.
22:49 < petertodd> amiller: It'd take at least a month or two to defend bitcoin from a 51% attacker by buying hashing power - factories have leadtimes.
22:50 < amiller> you don't defend against a 51% attacker, you prevent a 51% attacker from existing
22:50 < gmaxwell> petertodd: transaction fees with checkpoint-in-txn are buying hashing power instantly. people constantly buying hashing power to get mined is the protection.
22:50 < gmaxwell> what amiller said.
22:51 < amiller> since you don't control the attacker, you have to go fundsraising and bulk up the size of the network
22:51 < amiller> by offering free candy and big prizes for participants
22:51 < petertodd> amiller: 51% attackers come in a few types: those who have the majority of hashing power capacity, those who can temporarily obtain more, and those who have enough to rewrite the whole chain.
22:51 < gmaxwell> I wish pos would work, but like amiller I suspect that its deeply impossible.  Sure you can make it work if you have jamfree communication between all parties. I don't think thats possible, however... because it would have to be infinite bandwidth.
22:52 < petertodd> amiller: We're best off if we can reduce the pow effort to the point where someone launches a 51% attack, they get stopped, and then the community responds by buying more physical hashing power.
22:52 < petertodd> amiller: Right now on the other hand we're flying blind and have no idea if we have enough - we're just hoping to god that an attack doesn't happen.
22:52 < amiller> you never have an idea if you have enough
22:52 < amiller> how much money should we spend on defense against aliens
22:52 < gmaxwell> ^ I certantly agree with that concern. We have no way to set the price, security is a lemon market.
22:52 < amiller> or on the military generally
22:53 < petertodd> amiller: Yes, and that's really inefficient! You want an attack to not be an end-the-world scenario, that is, you should be able to burn value to temporarily stop it.
22:53 < gmaxwell> worse, a viable strategy for an attacker is to try to convince you that you don't need so much security.
22:53 < petertodd> gmaxwell: that too
22:53 < amiller> any money spent on military that's sucecssful as a deterrent appears as a waste because the attacker didn't hsow up
22:54 < petertodd> There's probably nothing we can really do (fully decentralized) that can stop a "rewrite the whole chian" attacker, but against the "has the majority of hashing power" and "temporarily rents a majority" we can probably succeed.
22:54 < gmaxwell> petertodd: so interesting. lets say you have a relatively jam free network.  A bad chain shows up. You issue transactions that burn all your coin, checkpointed so they can only exist in the bad chain.  How do nodes know when they've seen enough of that to start ignoring that chain?
22:55 < petertodd> gmaxwell: Basically if burned coins == pow mined coins, the chain with the burned coins is considered to be the longest and wins.
22:55 < amiller> temporarily rents an infinite hashpower  is fine as long as it's temporary
22:55 < amiller> you can only rewind so many blocks then everything goes on as usua
22:55 < amiller> "has the majority of the hash power forever" is not an attack worth defending against!
22:56 < amiller> figure out the size of your attacker's military and then build 1+ more than that!
22:56 < petertodd> gmaxwell: Note how this doesn't suffer as much from the direct "nothing at stake" aspect of proof-of-stake, because you're not directly gaining from the sacrifice.
22:57 < amiller> if you want to cut costs by being optimistic that your attackers aren't going to be so powerful then great
22:57 < petertodd> amiller: if P=∞ and t=0 then we're safe, maybe :P
22:57 < amiller> lets just hope no one can afford 6 blocks, since that's what all the gold sells for (i think)
22:57 < petertodd> amiller: Yeah, as I say, so long as finding out we're wrong is something that can be fixed before the value of the coin plummets sufficiently that the whole system collapses we're good.
22:58 < amiller> sure just give the attacker what he wants
22:58 < gmaxwell> amiller: nah, the gold will notice a reversal dozens of blocks later, as I believe they check preshippment.
22:58 < amiller> then 24 hours or w/e?
22:58 < gmaxwell> amiller: but within 24 hours you'll hear that shit is busted.
22:59 < gmaxwell> and manually halt shipments.
22:59 < petertodd> amiller: well, that's an interesting thing, because the reversal attack can be handled with replace-by-fee scorched earth: wallets don't want the chain to go backwards, so they can respond by saying "well, if we have this chain, I'm happy to burn the money I received to increase the apparent work done by the "valid" chain"
22:59 < gmaxwell> petertodd: keep in mind the threat of people shorting the assets.
22:59 < petertodd> gmaxwell: yeah, lots of second order effects
22:59 < amiller> petertodd, if everyone burns 10% of their income
22:59 < amiller> petertodd, then no one has lost anything
22:59 < amiller> this doesn't work with fiat money
23:00 < amiller> (by fiat money i mean bitcoin, money not a commodity, the whole fiat=state thing is a misnomer, but sorry)
23:00 < gmaxwell> presumably only those fucked by the fork would burn money.
23:00 < petertodd> gmaxwell: I suspect in reality we'll never get a system that won't result in a few hours to days of chaos, but societies recover from that kind of thing all the time.
23:00 < amiller> petertodd, what you're saying is you want a cheap defense
23:00 < amiller> it costs $100 to defend against a $100 attacker
23:00 < amiller> okay but how about we just spend $10 but then if a $100 attacker attacks, we'll just be safe anyway
23:01 < petertodd> gmaxwell: yeah, which is interesting, because if the community knows there are defenses, that itself helps keep the faith in the system high
23:01 < petertodd> amiller: No, the defense doesn't have to be cheap, it has to have a short leadtime.
23:01 < petertodd> amiller: If it was $100 for every $10 the attacker spent, it'd probably be ok too, but it has to be possible to respond quickly.
23:01 < amiller> i don't think it counts if you do it retroactively
23:01 < amiller> but hm.
23:02 < amiller> so you build a huge force field but you leave it unpowered
23:02 < amiller> if you detect a missile you raise the shields
23:02 < gmaxwell> amiller: petertodd is arguing that if you can defend instantly, you could put up to 100% of the money the attack would cost you into the defense.
23:02 < petertodd> amiller: Ha, yes kinda! The huge force-field is the huge number of coins sitting around in people's wallets basically.
23:02 < gmaxwell> amiller: and if everyone does that the attacker can basically never win if their winning is defined as a gain within the system.
23:02 < amiller> the coins aren't real value though
23:02 < amiller> if everyone spends them all then you still have the same vlaue
23:02 < amiller> nothing was spent
23:02 < gmaxwell> amiller: not everyone, the people getting ripped off.
23:02 < amiller> the suckers who decided to defend?
23:03 < petertodd> gmaxwell: yeah, part of my argument is also that you need the attackers to know this, and not really want to try
23:03 < petertodd> amiller: They're not suckers; they're people with transactions that would otherwise be reversed.
23:03 < gmaxwell> amiller: you pay me 5 btc. then reorg that transaction out. I say fuck you and convert that 5 BTC into POW on the old chain.
23:03 < amiller> that's a weird argument though
23:03 < amiller> you can't burn money you can't only give it to everyone else
23:03 < amiller> you can only*
23:04 < petertodd> amiller: Right, but by burning it, you're giving it to the people you actually want to: the other pre-existing participants in the system.
23:04 < gmaxwell> if miners were not hardware, what peter todd suggests could just work via fees.
23:04 < gmaxwell> pre-existing participants in the chain you want to survive.
23:04 < petertodd> gmaxwell: Yes, if we had replicators we'd implement my scheme in hardware. :)
23:05 < gmaxwell> yea, if the miners were free but only took power when used, then it would work.  You'd just have huge latent hashpower that turns on when there is an attack.
23:06 < amiller> that sounds good
23:06 < petertodd> Exactly! And we can even learn how the dynamics of this stuff work with proof-of-sacrifice blockchains, like the zookeyv system I proposed a few months ago.
23:06 < gmaxwell> petertodd: here is your POS:  nodes pick the most profitable to mine chain.
23:06 < petertodd> gmaxwell: my POS?
23:06 < gmaxwell> you can convert coins to proof by just making the chain you like more profitable.
23:07 < amiller> so pos is exactly bribing the miners anyway :o
23:07 < gmaxwell> amiller: there is a subtle difference!!!
23:07 < petertodd> amiller: which would work, expect that miners have fixed capacity
23:07 < petertodd> amiller: *except
23:07 < gmaxwell> amiller: say 60% hashpower is evil and stays on the less profitable chain. The network still ignores them.
23:07 < gmaxwell> Because "fuck you, our consensus is the most profitable chain"
23:08 < petertodd> gmaxwell: well remember that "profitable" can also mean "my business is profitable because my transaction went through and I got paid"
23:08 < amiller> so no one picks the longest proof of work they only pick the most profitable chain?
23:08 < gmaxwell> petertodd: and you can conver one to the other by spending to fees.
23:08 < petertodd> gmaxwell: we can have this entire discussion if there is no block subsidy
23:08 < petertodd> gmaxwell: yup
23:08 < gmaxwell> amiller: longest POW would, I guess be the tiebreaker for differences in short term profitablity?  I haven't fully thought this out.
23:09 < petertodd> and in the zookeyv system, the consensus key-value thing, profitable is soley "my DNS records are what I want them to be"
23:09 < amiller> maybe longest pow is nothing but an expensive focal point?
23:09 < petertodd> *solely
23:09 < gmaxwell> amiller: "profitable" includes the notion that it's likely to be the winner. So you can use other symmetry breakers like most pow work as part of your profitable figure.
23:10 < gmaxwell> The devil is how they balance.
23:10 < amiller> symmetry breakers is silly to make expensive thouhg
23:10 < amiller> if that's the only explanation for the role of pow then that's not compelilng
23:10 < warren> <petertodd> [15:08:17] maaku: With MMR TXO commitments we can stop hassling every idiot who bloats the UTXO set, and for that matter, they aren't idiots anymore...
23:10 < warren> petertodd: so does this mean you give up on keepbitcoinfree?
23:10 < petertodd> gmaxwell: yeah, in zookeyv if it's implemented as a strict DAG there can be the problem that there's no incentive to build on anything but your own records
23:11 < petertodd> warren: keepbitcoinfree isn't just about UTXO's
23:11 < gmaxwell> none of the MMR stuff solves bandwidth.
23:11 < petertodd> warren: Though in general I suspect you *can* create consensus systems that allow for arbitrary numbers of transactions, but they look radically different than bitcoin.
23:11 < amiller> bandwidth is payers problem though
23:12 < amiller> spend your utxo sooner so it costs less
23:12 < petertodd> amiller: bandwidth can prevent you from detecting fraud...
23:12 < amiller> oh you're assuming probabilistic validation or something?
23:12 < petertodd> amiller: yes, there's just no other way than sharding, and that's got ugly issues - I'm sure I can come up with a proof that any such system always suffers from the risk of data deletion
23:13 < petertodd> amiller: and the only way to prevent that is force mining - whatever form it takes - to require some kind of proof-of-stake-ish consensus to make sure that if the txout owners chose to they would be able to keep up with updates to their little shard of the txout set
23:14 < petertodd> s/force/for/
23:15 < maaku> ?
23:15 < maaku> are you assuming scaling beyond the limit of a single pipe being able to carry block updates?
23:15 < petertodd> maaku: yes
23:15 < petertodd> maaku: beyond any individual internet connection in the world in fact
23:16 < amiller> grubmel, i can't figure out what it is you can you achieve by actually *burning* value *for everyone* instead of just disbursing it at random to everyone else in the system
23:16 < petertodd> amiller: destroying a coin == disbursing it to everyone else
23:16 < petertodd> amiller: so why not make things simple?
23:16 < maaku> is that even worth considering?
23:16 < amiller> yes and pow = burning it for everyone
23:17 < amiller> they're different and the difference may be important
23:17 < petertodd> amiller: point is we need an artifical form of proof-of-work, and that's the best we can get that operates in limited-bandwidth jam-free networks
23:17 < amiller> no it's not artificial
23:17 < amiller> it's fake
23:17 < amiller> disbursing to everyone != actually destroying something
23:17 < maaku> 1Gbps is what, 600k tps?
23:18 < petertodd> amiller: who cares what exactly it is? what's important is that it gives us a way of coming to consensus about what is the best chain
23:18 < amiller> that's not it
23:18 < amiller> they both give you a way of coming to consensus if everyone or enough people follow the protocol exactly
23:18 < amiller> what it doesn't explain is how the difference affects the incentives to come to consensus rather than doing something else
23:19 < amiller> you can forgive a proof of stake
23:19 < petertodd> maaku: a ideal system should be able to operate with individual nodes having nothing more than a tin can and string, so lets see how close we can get to that
23:19 < amiller> if everyone decides to you could just distribute the money right back to the person who staked it in there
23:19 < amiller> and there would be no system loss, no friction
23:19 < amiller> you can't forgive the burning of energy
23:20 < maaku> i'm as wary as the next guy to saying '640k is enough for anybody', but really i don't know a single application that would require *public* consensus over that many transactions
23:20 < petertodd> amiller: look, it's really simple: I want a way of saying "this chain is the best chain" without having access to mining power
23:20 < petertodd> amiller: That's it!
23:20 < amiller> but you want it in a rational system with anonymous players!
23:20 < amiller> or else i suggest just having one guy with a private key that signs it
23:21 < maaku> ok, maybe i'm missing something again, but how do you have full validation (which miners have to do), without access to the blocks?
23:21 < petertodd> amiller: yes, which makes it hard, and the best I can think of is being able to create a little bit of data that says "if this chain is the best chain, I'm happy to give up 1 million FOO TOKENS from the foo-system ledger"
23:21 < amiller> petertodd, if you're a dictator you can just raise everyo'nes taxes by 1 foo each
23:21 < amiller> and recoup your costs
23:21 < amiller> and actually no one hurt
23:22 < amiller> you can convince them all it was good for them to give you that power
23:22 < petertodd> amiller: Now you add up all the other little bits of data saying similar things, and you say "well, block 12345 has a lot of people willing to give up foo tokens if it's the best, so it's the best!"
23:22 < petertodd> amiller: huh?
23:23 < petertodd> maaku: you have full validation if there is 100% coverage of the data by validators; you don't need every individual validator to validate the whole data set fully
23:23 < petertodd> maaku: but you do need to make it possible for any one of those partial validators to prove the fraud they found cheaply
23:23 < amiller> it's not necessary for every full validator to be capable of validating anyone's transaction without their help
23:23 < amiller> full validators don't need to store backup copies of your private key for you, nor do they need to remember all the bits needed to prove your transaction is valid
23:24 < amiller> 10 different people can each submit their indivudal transaction validity proofs and anyone can validate the block consisting of those
23:24 < petertodd> amiller: thing is there's no such thing as a proof that something is valid, only a proof that something is invalid (modulo SCIP)
23:24 < petertodd> *compact proof
23:28 < amiller> what you should have to do is bribe miners not to burn work
23:28 < petertodd> amiller: huh?
23:28 < amiller> it hurts everyone, in a sense, when miners burn
23:28 < amiller> you have a weak/social/long term incentive to pay them *not* to mine
23:28 < petertodd> You can't bribe someone whos goal is to destroy the currency for whatever reason
23:29 < petertodd> Why is there an incentive forthem not to mine?
23:29 < amiller> there *is* an incentive for them to mine, but if you have coins, and you have stake, then you can pay them not to
23:29 < petertodd> How can I do that?
23:30 < amiller> by paying them to fight amongst themselves perhaps
23:30 < amiller> paying for forks
23:31 < amiller> 'defunding' the miners
23:32 < amiller> paying miners not to mine is the pure public good
23:32 < petertodd> how can you pay them to fight? at any given time modulo network latencies the miners can always mine on the best chain, and best has a clear consensus meaning
23:32 < amiller> because it didn't affect them, they get the monetary reward they would have had
23:33 < petertodd> remember when you burn coins in liu of work, *your* a 51% attacker on the chain you are re-orging
23:33 < petertodd> there's no priviledged position here
23:34 < amiller> it won't happen for very long anyway, the point is *you* lose the money you burned, fewer mining occured, but the miners got the same income they would have anyway
23:34 < petertodd> and it's all irrelevant, because as always part of being a profitable miner is mining on the chain that you think has the most support, and that means the next block that will be mined
23:35 < amiller> that may not be the only way to pay miners
23:36 < amiller> er, to pay miners not to mine
23:36 < amiller> the point is, there's your cheap proof of stake, i'm making an observation about what it can mean to burn a coin
23:37 < amiller> just sending it out isn't necessarily burning it because if it's useful to do so, everyone else might to it too, and then it had no effect anyway
23:39 < petertodd> burning coins in liu of work, as I'm advocating above, isn't proof-of-stake, it's transferrable-proof-of-work
23:41 < amiller> maybe there should be like a difficulty measure
23:41 < amiller> in terms of burned coins and work
23:41 < amiller> such that you can arbitrage
23:41 < amiller> if the cost per burned coin in proof of stake is different than what you could pay for mining power on the spot
23:41 < petertodd> I'm really not seeing why this should be any more complex than "If this chain wins, I'm happy to have x less BTC"
23:43 < amiller> look at it this way, if that's true, what's the most effective way to spend x btc to get that chain won?
23:43 < amiller> if you can do it by renting mining power then you can spend it on mining power
23:43 < amiller> if you can do it by paying a particular person somehow then you could do that
23:43 < amiller> if you can accomplish it the best by deleting it
23:43 < amiller> then you could do that, but it seems less plausible that you can't use it to your influence in some better way
23:44 < petertodd> sigh... the issue is we have effective long term ways - buy hashing power - but we don't have effective short-term ways
23:44 < gmaxwell> sweet. I just out cryptoed DJB.
23:45 < petertodd> the challenge is to come up with a way that's effective in the short-term, yet also works in the context of limited bandwidth jam-free networks
23:45 < petertodd> gmaxwell: ?
23:45 < gmaxwell> (well I suppose I should save the bragging for when he response conceding defeat)
23:45 < amiller> petertodd, how is paying for rented hash power not an effective way
23:46 < petertodd> amiller: because it's impossible to increase the supply without waiting!
23:46 < amiller> you can just take it from someone else
23:46 < amiller> you're assumign the attacker eclipses the world economy i think
23:46 < petertodd> amiller: no you can't! there is a limited amount in this world
23:46 < amiller> so you're talking about an attacker that has moved markets
23:47 < petertodd> amiller: markets aren't effient enough to say "hey, I want a few petahash in an hour"
23:47 < petertodd> reality just doesn't work that way
23:47 < petertodd> the whole point of this is to paper over the fact that the real world is ugly and slow
23:48 < gmaxwell> petertodd: DJB created http://safecurves.cr.yp.to/    see the rigidity page. I'm trying to convince him that the choice of generator must be documented too.
23:48 < petertodd> gmaxwell: ha, good job
23:48 < amiller> petertodd, then smash pots or something
23:49 < gmaxwell> he was trying to insist that there is nothing interesting that you can do with generator control in any cryptographic protocol. :P
23:49 < amiller> the point is if you just burn your money without burning something objective it doesn't have the same effect
23:49 < amiller> i'm trying to figure out how to articulate why that matters because what i think you're doing is ignoring the distinction or have already decided it doesn't matter
23:50 < gmaxwell> petertodd: so I sent him http://0bin.net/paste/Aqayl-V7cyFWqv5E#ju+Q69udt8UIOVxaMYV9AFSJLkr/V2FhT2Lke1S0wQU=
23:51 < amiller> tjat
23:51 < amiller> that's so cool gmaxwell
23:52 < petertodd> amiller: start from the end-goal: we want to come to a consensus that reflects the desires of the economic majority, and work backwards
23:52 < amiller> i don't think that makes any sense
23:52 < gmaxwell> amiller: yea, well I don't think it's so cool. It means that the curve in bitcoin could be somewhat backdoored, because we can't explain G.
23:53 < petertodd> gmaxwell: good job
23:53 < gmaxwell> We can explain all other parameters, but not G.  I'm trying to save DJB's future curves from the same weakness.
23:54 < petertodd> amiller: again: so someone launches a 51% attack, stopping all transactions and/or rewriting some part of the blockchain, how do we divise a system where the response can be made fast enough that people don't just give up on the system before actual hashing power can be obtained?
23:54 < petertodd> amiller: hardware has leadtimes of months - there is *nothing* we can do about that, especially since we're using proof-of-work systems that are ASIC friendly
23:55 < petertodd> amiller: even if the proof-of-work system was 100% best mined by fully commodity hardware, it'd still take days to weeks to obtain it in a mad rush - there just isn't all that much computing power available for rent in a decentralized way
23:55 < petertodd> (the attacker might have already rented it all!)
23:55 < amiller> then outbid the attacker
23:55 < amiller> the attacker has limited funds
23:56 < amiller> or else the attacker has already one
23:56 < amiller> won*
23:56 < petertodd> amiller: "outbid" how? the real world doesn't always let you outbid
23:56 < petertodd> amiller: No amount of money is going to get Amazon EC2 to kick off their existing customers you know.
23:57 < amiller> i don't see why you are assuming it's sufficient to choose the chain based on something that shares some-but-not-all of the properties of proof of work
23:57 < amiller> how about in a pinch you just have gavin sign the blocks?
23:57 < petertodd> amiller: And I mean that: if you had sufficient money to make it worth their while, it'd take too long for them to verify that you were for real.
23:57 < amiller> i'm saying that burning coins doesn't have the same effect as burning power
23:57 < petertodd> amiller: heck, agreeing to just have gavin sign the blocks would probably take long enough that you'd be better off buying hashing power...
23:58 < amiller> agree in advance?
23:58 < amiller> and override it if he fires without cause
23:58 < petertodd> amiller: Then you have a system that's vulnerable to gavin...
23:58 < amiller> so what is the system vulnerable to
23:58 < amiller> that burns coins
23:58 < amiller> instead of work?
23:58 < amiller> you are implicitly assuming that there's no difference or that the difference isn't important
23:58 < amiller> i'm trying to understand what that difference is
23:58 < petertodd> amiller: Even worse, Gavin is vulnerable to the system - legally he'll be gone after for having the ability to control the system.
23:59 < amiller> i agree with both your explanation of the problem to be solved, and your reason why the gavin approach is vulnerable to something undesirable, so now lets try to get to the bottom of what vulnerability the burning coins might have over proof of work
--- Log closed Fri Oct 18 00:00:04 2013