3 ms·

How can a bug in the implementation be a security risk? This gets a little complicated. "Bitcoin" is a commodity, a protocol (series of promises), a protocol

by patio11 14y ago

How can a bug in the implementation be a security risk? This gets a little complicated. "Bitcoin" is a commodity, a protocol (series of promises), a protocol (computer code to implement that series of promises), a particular distributed ledger, a network (of computers implementing the computer code implementing the series of promises with regards to one consensus distributed ledger), etc etc. Consider bitcoin the series of promises. One such promise is under what circumstances opcode 32 causes a transaction to be marked as invalid. (Don't bother looking it up -- you'll have to go down a rabbit hole for a while.) It is critically important that all code implementing opcode 32 comes to the same conclusion regarding every transaction in history and every transaction in the future. Consider an edge case for opcode 32, occurring in a transaction that I'll call T, two years ago. T is, as of right now, accepted as valid in the history that bitcoin (as you understand that term) accepts as correct. If a malfunctioning bitcoin client were to reject T, they would reject large portions of history after T, because they'd be predicated on an invalid series of transactions. Following me so far? So the more interesting case isn't when there is a difference of opinions in the past, it is when there is a predictable difference of opinions in the future. In this case, one set of clients starts building a transaction ledger B, and one starts building a transaction ledger B'. They are different transaction ledgers. People subscribing to either ledger, which they think of as The One True Bitcoin Ledger, will be mighty pissed when other people in The One True Bitcoin Economy tell them that their unforgeable, unloseable, ungovernable units of crypocurrency are actually worthless bits. This is called a blockchain fork. Bitcoiners are terrified of it happening again. (Yes, it has already happened at least once. Long story. "No harm, no foul, he wasn't trying to crash our entire economy so we dodged a bullet." is pretty much the consensus among Bitcoiners who actually understand what happened there.)

mechanical_fish 14y ago
So, when this happens again, and then is discovered, who decides which partition of the tree is the "fork" and which is the main branch? I presume it happens by consensus? But... where does consensus come from, in the general case? Does it operate like much open-source governance, via a mix of public and private meetings on IRC between the maintainers of the biggest clients? When that "community" decides to invalidate the mobster's Bitcoins, is there an appeals process, and do the judges have bodyguards? How does one get a seat at the Bitcoin developer summit in the first place? Do the contributors of the most code have the most influence? Which in practice usually translates to "friends and allies of the project founder" and "rich individuals and companies who pay developers to contribute to the project in order to influence its direction?"
- nullc 14y ago
  Short forks happen all the time, it's a natural consequence of the finite speed of light. So long as any divergence is detected and resolved within the window of typical forks (e.g. <6 blocks) is mostly a non-issue. The natural thing to accept is the history acceptable to most distinct makes of software (least common denominator) which would be the automatically successful one with no intervention at all if not for the extreme consolidation of hashing power on a couple overly large pools.
- wmf 14y ago
  If the fork is bitcoind vs. something else, bitcoind will always win because it is the reference implementation. When it's bitcoind 0.7 vs. bitcoind 0.8 it's handled on a case-by-case basis.
  - nullc 14y ago
    In that particular case it was weird because something like 80% of the public network nodes / users / services were on <0.8 but most of the hash-power was on 0.8.0 simply because the two largest pools were already on 0.8. (0.8's performance improvements could increase miner's income due to needing less time to process and switch to new blocks)
  - rmc 14y ago
    Unless everyone/lots of people have moved to the alternative and support that version.

by patio11 14y ago

mechanical_fish 14y ago

So, when this happens again, and then is discovered, who decides which partition of the tree is the "fork" and which is the main branch? I presume it happens by consensus? But... where does consensus come from, in the general case? Does it operate like much open-source governance, via a mix of public and private meetings on IRC between the maintainers of the biggest clients? When that "community" decides to invalidate the mobster's Bitcoins, is there an appeals process, and do the judges have bodyguards? How does one get a seat at the Bitcoin developer summit in the first place? Do the contributors of the most code have the most influence? Which in practice usually translates to "friends and allies of the project founder" and "rich individuals and companies who pay developers to contribute to the project in order to influence its direction?"

nullc 14y ago
Short forks happen all the time, it's a natural consequence of the finite speed of light. So long as any divergence is detected and resolved within the window of typical forks (e.g. <6 blocks) is mostly a non-issue. The natural thing to accept is the history acceptable to most distinct makes of software (least common denominator) which would be the automatically successful one with no intervention at all if not for the extreme consolidation of hashing power on a couple overly large pools.
wmf 14y ago
If the fork is bitcoind vs. something else, bitcoind will always win because it is the reference implementation. When it's bitcoind 0.7 vs. bitcoind 0.8 it's handled on a case-by-case basis.
- nullc 14y ago
  In that particular case it was weird because something like 80% of the public network nodes / users / services were on <0.8 but most of the hash-power was on 0.8.0 simply because the two largest pools were already on 0.8. (0.8's performance improvements could increase miner's income due to needing less time to process and switch to new blocks)
- rmc 14y ago
  Unless everyone/lots of people have moved to the alternative and support that version.