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 2232767 for ; Wed, 19 Aug 2015 03:49:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 426BF221 for ; Wed, 19 Aug 2015 03:49:08 +0000 (UTC) Received: from piha.riseup.net (unknown [10.0.1.162]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id DD59EC10A7; Tue, 18 Aug 2015 20:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1439956147; bh=fjjhrhrkmSqAxI+95Dk3bWBJbfmLUoE+kh00WXuQOEo=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=QzEaWTWurdfe4WKIL4F7jWOeITk/UFCsQXXJonuPrKFbR0TCSo1gcH9PG8GwLUDXM 7f4bYdUJ+h8w01G+QiS0d1wHQoi5kzQsNX3+2DTXn9L3NnW5gGJAG5rdWrzAMD7Oa/ yRjnRRX1wHtVGo2YYu9ki8R0//emv0lj0JioKiJI= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla) with ESMTPSA id 2751414173A Message-ID: <55D3FCB2.7070705@riseup.net> Date: Tue, 18 Aug 2015 20:49:06 -0700 From: odinn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Adam Back , Eric Lombrozo 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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net X-Virus-Status: Clean X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, UNPARSEABLE_RELAY 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: Wed, 19 Aug 2015 03:49:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Agreed. On 08/17/2015 07:36 AM, 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’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 > - -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJV0/yyAAoJEGxwq/inSG8CaicIALQU//jNkUVRb6uzYFtSNb/y cWViS5oaberLC2S0pQu2C4CciHSht347luM8kxlp3xL045SgIvvwXBzooH5HE+JE +NscfC58+2RyQWgPiWrwQ2JSFQgaRzi58fyE8rLSdsLKXjJkbkaol6w2atbpvHP8 Zbm6sAOybLurA+2N9ZtxWosEZEfjT54Sf14+YNQlr5ve3JbYBIbZ8PhWPXwc5P/5 FuwBb/JBszClasWGxmsexrpXfK6Kqy2rOVOWmmYNMjpHR8oYZWKC42HTOXw2lig1 lspqMEXBTv+ppSk1KU5ovwftongX3W0lM5DOj3FXE7frlgcBxeMMFBFBFGnT3ZU= =vCZH -----END PGP SIGNATURE-----