Thank you Eric for saying what needs to be said. Starting a fork war is just not constructive and there are multiple proposals being evaluated here.
I think that one thing that is not being so much focussed on is Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core SPV nodes that did not opt-in. It exposes those SPV nodes to loss in the likely event that Bitcoin-XT results in a network-split. The recent proposal here to run noXT (patch to falsely claim to mine on XT while actually rejecting it's blocks) could add enough uncertainty about the activation that Bitcoin-XT would probably have to be aborted. Adam On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > NxtChg, > > In the entire history of Bitcoin we’ve never attempted anything even closely > resembling a hard fork like what’s being proposed here. > > Many of us have wanted to push our own hard-forking changes to the > protocol…and have been frustrated because of the inability to do so. > > This inability is not due to any malice on anyone’s part…it is a feature of > Satoshi’s protocol. For better or worse, it is *very hard* to change the > rules…and this is exactly what imbues Bitcoin with one of its most powerful > attributes: very well-defined settlement guarantees that cannot be suddenly > altered nor reversed by anyone. > > We’ve managed to have a few soft forks in the past…and for the most part > these changes have been pretty uncontroversial…or at least, they have not had > nearly the level of political divisiveness that this block size issue is > having. And even then, we’ve encountered a number of problems with these > deployments that have at times required goodwill cooperation between > developers and mining pool operators to fix. > > Again, we have NEVER attempted anything even remotely like what’s being > proposed - we’ve never done any sort of hard fork before like this. If even > fairly uncontroversial soft forks have caused problems, can you imagine the > kinds of potential problems that a hard fork over some highly polarizing > issue might raise? Do you really think people are going to want to > cooperate?!? > > I can understand that some people would like bigger blocks. Other people > might want feature X, others feature Y…and we can argue the merits of this or > that to death…but the fact remains that we have NEVER attempted any hard > forking change…not even with a simple, totally uncontroversial no-brainer > improvement that would not risk any sort of ill-will that could hamper > remedies were it not to go as smoothly as we like. *THIS* is the fundamental > problem - the whole bigger block thing is a minor issue by comparison…it > could be any controversial change, really. > > Would you want to send your test pilots on their first flight…the first time > an aircraft is ever flown…directly into combat without having tested the > plane? This is what attempting a hard fork mechanism that’s NEVER been done > before in such a politically divisive environment basically amounts to…but > it’s even worse. We’re basically risking the entire air force (not just one > plane) over an argument regarding how many seats a plane should have that > we’ve never flown before. > > We’re talking billlions of dollars’ worth of other people’s money that is on > the line here. Don’t we owe it to them to at least test out the system on a > far less controversial, far less divisive change first to make sure we can > even deploy it without things breaking? I don’t even care about the merits > regarding bigger blocks vs. smaller blocks at this point, to be quite honest > - that’s such a petty thing compared to what I’m talking about here. If we > attempt a novel hard-forking mechanism that’s NEVER been attempted before > (and which as many have pointed out is potentially fraught with serious > problems) on such a politically divisive, polarizing issue, the result is > each side will refuse to cooperate with the other out of spite…and can easily > lead to a war, tanking the value of everyone’s assets on both chains. All so > we can process 8 times the number of transactions we currently do? Even if it > were 100 times, we wouldn’t even come close to touching big payment > processors like Visa. It’s hard to imagine a protocol improvement that’s > worth the risk. > > I urge you to at least try to see the bigger picture here…and to understand > that nobody is trying to stop anyone from doing anything out of some desire > for maintaining control - NONE of us are able to deploy hard forks right now > without facing these problems. And different people obviously have different > priorities and preferences as to which of these changes would be best to do > first. This whole XT thing is essentially giving *one* proposal special > treatment above those that others have proposed. Many of us have only held > back from doing this out of our belief that goodwill amongst network > participants is more important than trying to push some pet feature some of > us want. > > Please stop this negativity - we ALL want the best for Bitcoin and are doing > our best, given what we understand and know, to do what’s right. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
