3 ms·

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 b

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 13y 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 13y 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 13y 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 13y ago
  Unless everyone/lots of people have moved to the alternative and support that version.

nullc 13y 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 13y 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 13y 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 13y ago
Unless everyone/lots of people have moved to the alternative and support that version.