From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 519623EE for ; Mon, 17 Aug 2015 14:58:43 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from BLU004-OMC4S6.hotmail.com (blu004-omc4s6.hotmail.com [65.55.111.145]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7B1FA1ED for ; Mon, 17 Aug 2015 14:58:42 +0000 (UTC) Received: from BLU437-SMTP6 ([65.55.111.135]) by BLU004-OMC4S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 17 Aug 2015 07:58:41 -0700 X-TMN: [07TVmiz3gRaCe67CUNxQB5S1ylETb3xB] X-Originating-Email: [slashdevnull@hotmail.com] Message-ID: User-Agent: Microsoft-MacOutlook/14.4.9.150325 Date: Mon, 17 Aug 2015 22:58:22 +0800 From: GC To: Adam Back , Eric Lombrozo Thread-Topic: [bitcoin-dev] Annoucing Not-BitcoinXT References: <20150817100918.BD1F343128@smtp.hushmail.com> <1439815244.89850.YahooMailBasic@web173102.mail.ir2.yahoo.com> <20150817133438.DDD4243128@smtp.hushmail.com> <64C86292-6671-4729-8A77-63C081797F62@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 17 Aug 2015 14:58:40.0851 (UTC) FILETIME=[343D6A30:01D0D8FD] X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Annoucing Not-BitcoinXT X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 14:58:43 -0000 Adam, While greatly appreciating your prior efforts in crypto-ccy R&D and current efforts for Blockstream, its not a plus for your reputation to be using emotive terms like =B3attack=B2, =B3fork war" and throwing so much FUD into the developer email channel directly after Eric=B9s email. We would appreciate seeing your well-argued thoughts, not FUD and flaming. There are multitudes of trolls in all forums already. On 17/8/15 10:36 pm, "Adam Back via bitcoin-dev" wrote: >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 > wrote: >> NxtChg, >> >> In the entire history of Bitcoin we=B9ve never attempted anything even >>closely resembling a hard fork like what=B9s being proposed here. >> >> Many of us have wanted to push our own hard-forking changes to the >>protocol=8Aand have been frustrated because of the inability to do so. >> >> This inability is not due to any malice on anyone=B9s part=8Ait is a >>feature of Satoshi=B9s protocol. For better or worse, it is *very hard* to >>change the rules=8Aand 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=B9ve managed to have a few soft forks in the past=8Aand for the most >>part these changes have been pretty uncontroversial=8Aor at least, they >>have not had nearly the level of political divisiveness that this block >>size issue is having. And even then, we=B9ve 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=B9s being >>proposed - we=B9ve 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=8Aand we can argue the >>merits of this or that to death=8Abut the fact remains that we have NEVER >>attempted any hard forking change=8Anot 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=8Ait could be any controversial change, >>really. >> >> Would you want to send your test pilots on their first flight=8Athe first >>time an aircraft is ever flown=8Adirectly into combat without having >>tested the plane? This is what attempting a hard fork mechanism that=B9s >>NEVER been done before in such a politically divisive environment >>basically amounts to=8Abut it=B9s even worse. We=B9re basically risking the >>entire air force (not just one plane) over an argument regarding how >>many seats a plane should have that we=B9ve never flown before. >> >> We=B9re talking billlions of dollars=B9 worth of other people=B9s money that >>is on the line here. Don=B9t 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=B9t even >>care about the merits regarding bigger blocks vs. smaller blocks at this >>point, to be quite honest - that=B9s such a petty thing compared to what >>I=B9m talking about here. If we attempt a novel hard-forking mechanism >>that=B9s 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=8Aand can easily lead to a war, >>tanking the value of everyone=B9s 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=B9t even come close to touching big payment >>processors like Visa. It=B9s hard to imagine a protocol improvement that=B9s >>worth the risk. >> >> I urge you to at least try to see the bigger picture here=8Aand 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=B9s right. >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev