path: root/d1/447d39f8fc7c741765379f5ce3f9824809091d

Return-Path: <odinn.cyberguerrilla@riseup.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2232767
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <odinn.cyberguerrilla@riseup.net>
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 <adam@cypherspace.org>, Eric Lombrozo <elombrozo@gmail.com>
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>
	<CALqxMTHfzWr24qELKyYMQ5fy48C1Q-SExCL49w-VMCq2JOdRoQ@mail.gmail.com>
In-Reply-To: <CALqxMTHfzWr24qELKyYMQ5fy48C1Q-SExCL49w-VMCq2JOdRoQ@mail.gmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 
> <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
> 

- -- 
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-----