Drak, I mostly agree with your assessment...except for your last claim.
Not that I wouldn't like to find a way to avoid politics, but like I've argued before, it is inevitable that sooner or later any consensus protocol that seeks dynamism will encounter politics. The block size discussion, while ultimately necessary, for now is in the best case merely serving as an example of the kind of political issues we *really* need to be finding some solution for...and in the worst case is a distraction and evasion. Some protocol updates will be merely technical optimizations or feature enhancements that are fairly uncontroversial...but some will inevitably be highly controversial with real-world economic consequences, winners and losers. We lack a process for deciding these issues. No matter how sophistocated we make the protocol, somethings will inevitably require external input to make these issues decidable...it is a Goedelian implication. This external input could be some sort of vote (of which hashing power is a particular kind) or perhaps something else. There's something to be said for building the dynamics of hard forks *into* our model rather than avoiding it at all costs. However, forks are the easy part. The difficulty is in merging different branches. Perhaps we should learn a thing or two from git. Perhaps the question we should be asking is not "how do we avoid hard forks" but "how can we design the network to allow for merging?" - Eric Lombrozo
------------------------------------------------------------------------------
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
