> On Aug 17, 2015, at 8:03 AM, Levin Keller <p...@levinkeller.de> wrote: > > Dear Eric, > > thank you for sharing your thoughts. > > It obviously boils down to political beliefs, not so much technical > arguments. I understand that you are in favor of a "guided decentralization" > and you are most happily invited to follow this path. I don't want to be on > it. I want total decentralisation of bitcoin and many other parts of the > current system.
I specifically asked you to stop misrepresenting - I’m NOT in favor of guided decentralization, I never said anything like that. *THIS* is the problem…you’re reading intentions into others that simply are NOT there. If you don’t really understand something, ask. I want complete decentralization - but for practical reasons, which should be obvious, we cannot start at this point. Bitcoin came into existence because Satoshi wrote a whitepaper and implemented the idea - and it was his rules. There was no voting, no committee, no proof-of-work, no nothing…it was a complete dictatorship in the beginning. > > So in the end the hard fork might be perfect, because people like you will > not waste so much more energy and time fighting people like me (and others) > who are following different dogmata because we are using different coins and > talking about different code. Interestingly enough in the end we will > probably have a winner - determined by the price - so I am looking forward to > the outcome. It is just the time so make some bets, which I embrace. > > Another interesting thing is, that you actually fear problems arising from > this. What do you have to loose? Just stick with the old bitcoin version and > weather this storm. Bitcoin is not going to vanish or break from this. It is > just forking. One fork will come stronger out of this. You just have to > choose a side and live with it, if you loose it all. But that is the story of > bitcoin since the beginning. If you ask me, you fear the choice, not the > change. > Again, misrepresentation - “you fear the choice, not the change” - why should anyone ask *you* what I fear? Why don’t you ask *me*? > Cheers > > Levin > > Adam Back via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> schrieb am Mo., 17. Aug. 2015 > um 16:37 Uhr: > 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 > <mailto: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 > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
