Created
November 5, 2013 18:47
-
-
Save amiller/7323965 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Hi Zooko, Albert, I took this opportunity to collect a bunch of my | |
thoughts from today and the past few weeks below. Apologies for the | |
ramble! | |
Despite the overhyped headline, this paper is important. It's part of | |
a (long past due) movement towards modeling "rational participation" | |
in Bitcoin. We are (surprisingly?) in a blind spot here as far as | |
theoretical foundations go (the 30+ years of research in distributed | |
systems, game theory, etc., have not looked at anything resembling | |
Bitcoin). We do not yet have a sound way to argue that "Bitcoin (or X | |
variant thereof) surely works," nor any impossibility results saying | |
"nothing resembling Bitcoin can ever work." | |
Main points: | |
- Bitcoin is clearly *intended* to be incentive-compatible and | |
encourage correct behavior. However the whitepaper only gives a proof | |
for the "51% honest" model, which is unrealistic/trivial (if we just | |
assume everyone's honest, there's no need for rewards in the first | |
place). Even in this easy model, Bitcoin is novel among byzantine | |
consensus protocols. Academics *should* have worked on this twenty | |
years ago, but missed it! | |
- Practically speaking, we still seem to have a while to figure this | |
stuff out before any systemic economic collapse will manifest. Even | |
the mining pools still run bitcoind, not RationalMiner software. For | |
the time being, majority honest is a reasonable approximation. | |
- Even if a 51% majority has limited ability to profit or attack, a | |
systematic trend towards enabling 51% attacks would be a design flaw | |
and existential threat. So we really need to find and fix things like | |
this. | |
This paper fits neatly into a class of papers/posts that point out a | |
particular way in which Bitcoin is not incentive-compatible (to call | |
it an *attack* is just cyberhype), yet a simple fix (typically just to | |
the messaging layer) is often at hand. | |
- Bitcoin and Red Balloons. There's no incentive for peers to relay | |
transactions. Solution: bribe your peer conditional on the transaction | |
getting accepted, now it's their problem too. | |
- This paper: If a mining pool is confident in its ability to detect | |
and out-propagate competing blocks, then it can profit by witholding | |
blocks until the last minute, making everyone else waste work. | |
Solution: relay faster so no peer can get this advantage, or use | |
random tie-breaking so this attack can't be pulled off consistently | |
(the following two examples are me plugging my own posts) | |
- https://gist.github.com/amiller/cf9af3fbc23a629d3084 An anomalously | |
large single transaction fee would encourage miners to fight over the | |
previous block, rather than building on each other's work. Solution: | |
remove the 100-block coinbase maturity rule, which actually prevents a | |
simple cooperative equilibrium where you take a cut of the huge fee | |
for yourself and leave the rest for the next miners to fight over. | |
- https://bitcointalk.org/index.php?topic=309073.0 Natural economies | |
of scale mean that "outsourced hosted mining" will be more cost | |
effective and might drive out other participants, leading to more | |
centralized control of resources, susceptible to coercion etc. | |
Solution: a modified puzzle using (efficient) zero-knowledge proofs | |
would make hosted mining (and mining pools, incidentally) impractical. | |
There are other similar "attacks" along the lines of "this may be a | |
problem when people eventually run RationalMiner rather than | |
HonestSatoshiReferenceClient", but for which the solutions are less | |
obvious... | |
- Feather forking: https://bitcointalk.org/index.php?topic=312668.0 a | |
small cartel of miners that want to enforce a transaction black-list | |
could easily make it so that rational participants indifferent to the | |
blacklist would rather appease the cartel than resist it. Possible | |
solution: Adam Back is thinking very hard about how to make miners | |
verify the correctness of transactions without learning anything else | |
about them. | |
- Kroll. et al: Following *any* of the rules is at best a *focal | |
point*, and slight rule tweaks like inflating the 21 million limit | |
(just by a little bit) are probably a lot more plausible and easier to | |
pull off than most people think. Possible solution: no idea | |
But we're still just scratching the surface of incentive-alignment | |
glitches like this. Bitcoin will overcome the problems with easy | |
fixes. I hope (but am skeptical) that if there's a bigger fix | |
required, we can work it out and adopt it without waiting until it's | |
too late and having to restart from scratch. | |
Above all, I wish we had a strong theoretical model we could use to | |
knock out entire classes of problems rather than pointing them out and | |
patching them one at a time. By analogy, the academic cryptography | |
community did such a great job of moving from ad hoc ciphers to | |
"provable security" that the mainstream security mantra is "don't roll | |
your own crypto" unless you've proved a theorem first. Maybe someday | |
they'll say the same thing about rolling your own incentive-consensus | |
protocols. But the work hasn't been done yet, and we're currently | |
still in the dark ages. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment