path: root/06/228fa4240d561cd1983d29cf4174272f642cb8

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <odinn.cyberguerrilla@riseup.net>) id 1Z4dHM-0002Lh-9X
	for bitcoin-development@lists.sourceforge.net;
	Mon, 15 Jun 2015 22:54:56 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of riseup.net
	designates 198.252.153.129 as permitted sender)
	client-ip=198.252.153.129;
	envelope-from=odinn.cyberguerrilla@riseup.net;
	helo=mx1.riseup.net; 
Received: from mx1.riseup.net ([198.252.153.129])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1Z4dHK-0005l4-Mr
	for bitcoin-development@lists.sourceforge.net;
	Mon, 15 Jun 2015 22:54:56 +0000
Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120])
	(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 A562542564;
	Mon, 15 Jun 2015 22:54:48 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	(Authenticated sender: odinn.cyberguerrilla)
	with ESMTPSA id 2AF24400EE
Message-ID: <557F57B7.4050809@riseup.net>
Date: Mon, 15 Jun 2015 15:54:47 -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: Mike Hearn <mike@plan99.net>, Adam Back <adam@cypherspace.org>
References: <CALqxMTGBt7MNs5YWf8QzKe+4Fr-uKVimf8=VbytBANEDm=s50g@mail.gmail.com>
	<CANEZrP31AEson9DZ=ZU7d4t=DvmGodh1ja6EaZ6xQZ3bFEXeVA@mail.gmail.com>
In-Reply-To: <CANEZrP31AEson9DZ=ZU7d4t=DvmGodh1ja6EaZ6xQZ3bFEXeVA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
X-Virus-Scanned: clamav-milter 0.98.7 at mx1
X-Virus-Status: Clean
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.9 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [198.252.153.129 listed in list.dnswl.org]
	-0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
	0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
	lines
X-Headers-End: 1Z4dHK-0005l4-Mr
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork &
 non-consensus hard-fork
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2015 22:54:56 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike,

To sum it up, you are saying "bitcoin will break and many of our users
will leave therefore OMG WTF so we have to do what GAVIN AND ME want
to do to hardfork to XT which is the ONLY WAY, so GTFO!"

And so, no.  We don't have to accept that attitude.

There are other proposals that actually would work here.

Cameron Garnham's dynamic block size adjustment (needing soft fork
only) mentioned here http://www.twitlonger.com/show/n_1smkanp

Jeff Garzik's proposals (rewritten and published as a BIP)
http://bitcoin-development.narkive.com/f5FMeA4D/comments-on-bip-100

and more.

I also disagree with the notion that everybody's just ok with what
Mike and Gavin are doing.... specifically, this statement by Mike

> The consensus you seek does exist. All wallet developers (except=20
> Lawrence), all the major exchanges, all the major payment
> processors and many of the major mining pools want to see the limit
> lifted

was kind of twisting things, because it made it sound like everybody
supports Gavin's proposal to hard fork to XT, which these folks don't.

Example:

1)
http://cointelegraph.com/news/114481/chinese-exchanges-reject-gavin-andr
esens-20-mb-block-size-increase

2) https://twitter.com/GreenAddress/status/605037073725313024

This isn't to say they don't want to see a limit adjusted but not in
the way that Gavin (and you, Mike) are proposing - not through this
hard fork to XT.

So go roll out your code for whatever it is you are going to put into
XT and make a BIP, but stop saying that everyone supports it when
obviously they don't and you don't even have something yet and there
are already superior alternatives that don't involve Gavin's hard fork
and your blessed XT.


On 06/15/2015 02:56 AM, Mike Hearn wrote:
> Hi Adam,
>=20
> Provisional answers below!
>=20
> - Are you releasing a BIP for that proposal for review?
>=20
>=20
> The work splits like this:
>=20
> * Gavin is writing the code and I think a BIP as well
>=20
> * I will review both and mostly delegate to Gavin's good taste
> around the details, unless there is some very strong disagreement.
> But that seems unlikely.
>=20
> * I have been handling gitian and the patch rebases, the code
> signing and so on, so far. I've also been doing some work to setup
> the basic infrastructure of the project (website etc).
>=20
>=20
> - If the reviewers all say NACK will you take on board their=20
> suggestions?
>=20
>=20
> Feedback will be read. There are no NACKS in Bitcoin XT. Patch
> requests aren't scored in any way. The final decision rests with
> the maintainer as in ~all open source projects.
>=20
>=20
>=20
> - On the idea of a non-consensus hard-fork at all, I think we can=20
> assume you will get a row of NACKs.  Can you explain your
> rationale for going ahead anyway?  The risks are well understood
> and enormous.
>=20
>=20
> Yes, I have been working on an article that explains how we got to
> this point from my perspective. It is quite long, but only because
> I want it to be readable for people who weren't following the
> debate.
>=20
> Anyway, I think I've laid out the gist of it over and over again,
> but to summarise:
>=20
> If Bitcoin runs out of capacity *it will break and many of our
> users will leave*. That is not an acceptable outcome for myself or
> the many other wallet, service and merchant developers who have
> worked for years to build an ecosystem around this protocol.
>=20
>=20
>=20
> - How do you propose to deal with the extra risks that come from=20
> non-consensus hard-forks?  Hard-forks themselves are quite risky,
> but non-consensus ones are extremely dangerous for consensus.
>=20
>=20
> The approach is the same for other forks. Voting via block versions
> and then when there's been >X% for Y time units the 1mb limit is=20
> lifted/replaced.
>=20
>=20
>=20
>=20
> - If you're going it alone as it were, are you proposing that you
> will personally maintain bitcoin-XT?  Or do you have a plan to
> later hand over maintenance to the bitcoin developers?
>=20
>=20
> Good question!  I have various thoughts on this, but let's wait and
> see what happens first. Perhaps the new chain won't get the
> majority on it.
>=20
> In the event that the >1mb chain does eventually win, I would
> expect Core to apply the patch and rejoin the consensus rather than
> lose all its users. That would take XT back to being a fairly small
> patchset to improve the network protocol.
>=20
>=20
>=20
> - Do you have contingency plans for what to do if the
> non-consensus hard-fork goes wrong and $3B is lost as a result?
>=20
>=20
> Where did you get the $3B figure from? The fork either doesn't
> happen, or it happens after quite a long period of people knowing
> it's going to happen - for example because their full node is
> printing "You need to upgrade" messages due to seeing the larger
> block version, or because they read the news, or because they heard
> about it via some other mechanisms.
>=20
> Let me flip the question around. Do you have a contingency plan if=20
> Bitcoin runs out of capacity and significant user disruption occurs
> that results in exodus, followed by fall in BTC price? The only one
> I've seen is "we can perform an emergency hard fork in a few
> weeks"!
>=20
>=20
>=20
> As you can probably tell I think a unilateral fork without
> wide-scale consensus from the technical and business communities is
> a deeply inadvisable.
>=20
>=20
> Gavin and I have been polling many key players in the ecosystem.
> The consensus you seek does exist. All wallet developers (except
> Lawrence), all the major exchanges, all the major payment
> processors and many of the major mining pools want to see the limit
> lifted (I haven't been talking to pools, Gavin has).
>=20
> This notion that the change has no consensus is based on you
> polling the people directly around you and people who like to spend
> all day on this mailing list. It's not an accurate reflection of
> the wider Bitcoin community and that is one of the leading reasons
> there is going to be a fork. A small number of people have been
> flatly ignoring LOTS of highly technical and passionate developers
> who have written vast amounts of code, built up the Bitcoin user
> base, designed hardware and software, and yes built companies.
>=20
> How do you think that makes Bitcoin Core look to the rest of the
> Bitcoin world? How much confidence does that give people?
>=20
>=20
>=20
> Of the overall process, I think you can agree we should not be
> making technical decisions with this level of complexity and
> consensus risk with financial implications of this magnitude under
> duress of haste?
>=20
>=20
> This debate will never end until a fork makes it irrelevant. There
> is no process for ending it, despite me begging Wladimir to make
> one.
>=20
> And there is no haste. We have been debating the block size limit
> for _years_. We have known it must be lifted for _years_. I kicked
> off this current round of debates after realising that Wladimir's
> release timeline wouldn't allow a block size limit to be released
> before the end of the year. The reason we're talking about it now
> and not next year is exactly to ensure there is plenty of time.
>=20
>=20
>=20
>=20
> I can sincerely assure you everyone does want to scale bitcoin and=20
> shares your long term objective on that
>=20
>=20
> I really wish you were right, and I definitely feel you are one of
> the more reasonable ones Adam. But the overwhelming impression I
> get from a few others here is that no, they don't want to scale
> Bitcoin. They already decided it's a technological dead end. They
> want to kick end users out in order to "incentivise" (force) the
> creation of some other alternative, claiming that it's still
> Bitcoin whilst ignoring basic details ... like the fact that no
> existing wallets or services would work.
>=20
> Scaling Bitcoin can only be achieved by letting it grow, and
> letting people tackle each bottleneck as it arises at the right
> times. Not by convincing ourselves that success is failure.
>=20
>=20
>=20
> ----------------------------------------------------------------------
- --------
>
>=20
>=20
>=20
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net=20
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20

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

iQEcBAEBAgAGBQJVf1e3AAoJEGxwq/inSG8C7NwIAIah+HzWKB+aydCgarJB1Tuv
4wK6ffaWP3pzT/D1jNPMoMwL6bp+hi/ixyrV2y9a841Oc/9vgf75ws1l8QH2YtEE
TM5cLnRtScXnbaHKAAQZyewURbmGKTUxhNLMIRlVMMq2uHwbUEqRrDaaBGhwC1HO
+v3u5zK13H1UMKBuUY7yANWvOamjs17FmwZ6MURYdX8qBFVqMoTorhPHTebDGusS
NxDm4uqphW7ylXISOm53v7i3/CPjW63YGB2fyk9J+BqxhOM7yAJSH0Ln/xtu/COa
uXudO+SbMco+x+cKrFLf/5ItxR65aOnWvWPKw0o55f96uSabngs/QozDhaU2BJk=3D
=3Dgof9
-----END PGP SIGNATURE-----