I think the "Kill King Bitcoin - Long Live the King" call is somewhat inevitable, and we should expect this to happen from time-to-time, now that the cat is out of the bag.
However, I fully agree with Adam that livenet is probably not the place to play this game, and I'm also not convinced that testnet is either. I often wondered if there is any appetite for a no-holds-barred, anything goes, bitcoin fork that would allow for the kind of valuable experimentation that Peter R is suggesting? This is a different concept than an alt-coin because it would be undoubtedly unstable until consensus is reached - and that is the whole idea. It hopefully would inform future decisions about what gets rolled into Core. One problem I see with doing this, is the lack of incentive. Chris On 1 September 2015 at 10:42, Adam Back via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Peter this seems to be a not well thought through course of action, > fun though it maybe informally or philosophically or to tweak various > peoples sensibilities. > > Bitcoin is a consensus system that does not work if there are > incompatible versions of consensus code competing on the network. > This is why work is underway on libconsensus so we can see diversity > of implementation without the risk of incompatibility arising by > software defect. It has proven quite hard to match independent > consensus implementations bit for bit against an adaptive adversary > looking for inconsistencies in interpretation. > > In terms of protocol updates it is more constructive therefore that > people with a technical interest analyse and validate others proposals > via testing, or make their own proposals so that we can arrive at a > well validated upgrade mechanism that everyone upgrades to in a > coordinated fashion. > > Previous intentional upgrades to bitcoin have been > backwards-compatible (via soft-fork which can be secured reasonably > using a miner vote trigger and temporary SPV security for those who > not yet upgraded) but the current topic of a throughput increase is > non-backwards-compatible (via a hard-fork), and the way to minimise > risk of such an upgrade is for everyone to try to upgrade well in > advance of an agreed upgrade schedule, and to be all upgrading to the > *same* consensus rule change. > > Encouraging nodes or miners to "vote" by running a range of different > consensus rules isnt really constructive I feel - it alarms people who > understand the risks, sets things on a path that have to be fixed > while in flight by obvious implication, and isnt collaborative - so it > risks being a politicising suggestion on what should be a purely > technical topic of choosing the best approach, where it is best to > strive to keep things non-emotive and professional and technically > focussed. Such calls are offending the technical sensibilities of > people who understand the risks. > > Anyway lets try to keep things constructive and focus on analysing > proposals. > > Adam > > On 31 August 2015 at 19:16, Peter R via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > I agree, s7r, that Bitcoin Core represents the most stable code base. To > > create multiple implementations, other groups would fork Bitcoin Core > > similar to what Bitcoin XT did. We could have: > > > > - Bitcoin-A (XT) > > - Bitcoin-B (Blockstream) > > - Bitcoin-C (promoting BIP100) > > - Bitcoin-D > > - etc. > > > > Innovation from any development group would be freely integrated by any > > other development group, if desired. Of course, each group would have a > > very strong incentive to remain fork-wise compatible with the other > > implementations. > > > > In fact, this just gave me a great idea! Since Wladimir has stated that > he > > will not integrate a forking change into Core without Core Dev > consensus, I > > suggest we work together to never reach consensus with Bitcoin Core. > This > > will provide impetus for new implementations to fork from Core (like XT > did) > > and implement whatever scaling solution they deem best. The users will > then > > select the winning solution simply based on the code they choose to run. > > The other implementations will then rush to make compatible changes in > order > > to keep their dwindling user bases. > > > > This is the decentralized spirit of Bitcoin in action. Creative > > destruction. Consensus formed simply by the code that gets run. > > > > Let's kill Bitcoin Core and allow the green shoots of a garden of new > > implementations to grow from its fertile ashes. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
