Date: Mon, 27 Jul 2015 08:08:29 -0400
From: Peter Todd <pete@petertodd.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20150727120829.GA27361@savin.petertodd.org>
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
	<CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA"
Content-Disposition: inline
In-Reply-To: <CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Precedence: list


--W/nzBZO5zC0uMSeA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 22, 2015 at 12:52:20PM -0400, Pieter Wuille via bitcoin-dev wro=
te:
> Hello all,
>=20
> I'd like to talk a bit about my view on the relation between the Bitcoin
> Core project, and the consensus rules of Bitcoin.
>=20
> I believe it is the responsibility of the maintainers/developers of Bitco=
in
> Core to create software which helps guarantee the security and operation =
of
> the Bitcoin network.
>=20
> In addition to normal software maintenance, bug fixes and performance
> improvements, this includes DoS protection mechanism deemed necessary to
> keep the network operational. Sometimes, such (per-node configurable)
> policies have had economic impact, for example the dust rule.
>=20
> This also includes participating in discussions about consensus changes,
> but not the responsibility to decide on them - only to implement them when
> agreed upon. It would be irresponsible and dangerous to the network and
> thus the users of the software to risk forks, or to take a leading role in
> pushing dramatic changes. Bitcoin Core developers obviously have the
> ability to make any changes to the codebase or its releases, but it is
> still up to the community to choose to run that code.
>=20
> Some people have called the prospect of limited block space and the
> development of a fee market a change in policy compared to the past. I
> respectfully disagree with that. Bitcoin Core is not running the Bitcoin
> economy, and its developers have no authority to set its rules. Change in
> economics is always happening, and should be expected. Worse, intervening
> in consensus changes would make the ecosystem more dependent on the group
> taking that decision, not less.
>=20
> So to point out what I consider obvious: if Bitcoin requires central
> control over its rules by a group of developers, it is completely
> uninteresting to me. Consensus changes should be done using consensus, and
> the default in case of controversy is no change.

It's worth reminding people that Bitcoin Core, Bitcoin XT, my own
Bitcoin RBF, Luke-Jr's Bitcoin distribution, etc. are all software
packages that implement the Bitcoin protocol. Like many protocols,
changing the Bitcoin protocol isn't easy, and requires a broad consensus
among many players for any change to proceed smoothly. Conversely,
changing non-protocol aspects of any of those software packages is easy,
and requires little to no coordination.

Of course, in practice the Bitcoin Core dev team does have a lot of
influence, to the point where soft-forks proposed by them are adopted
pretty much blindly by most users. This is essentially a meta-consensus:
the community is assuming what the Bitcoin Core team releases will be a
good idea to run as well as non-controversial without necessarily
investigating too closely. The Core dev team has a strong track record
of making good decisions with very few mistakes, while still adding new
features, fixing security bugs, and improving performance significantly.
That leads to a fairly strong meta-consensus of "Just run Bitcoin Core"

Of course, if the Core team was taking changes and making controversial
changes, I suspect that meta-consensus would quickly break down! So it's
not as strong as it looks - the Core team doesn't really have the
ability to push through controversial changes, and the Core team acts
accordingly.

If you don't agree with that "meta-consensus", running an alternative
Bitcoin protocol implementation such as Bitcoin XT is a logical way of
showing your support for a different way of coming to consensus on
protocol changes. It's not totally clear yet what that way actually is,
but it's certainly shaping up to have a lot less emphasis on broad
consensus among the technical community. (of course, the XT team to date
has much less experience with the Bitcoin protocol and codebase than the
combined Core team does)

The ugly thing is I think everyone in this process recognises the
meta-consensus nature of the debate already. Notice how Gavin Andresen's
initial blocksize posts were in the form of a non-technical blog, making
non-technical arguments to the public - not the Core dev team - in ways
not conducive to open response.  A rather annoying example is Jeff
Garzik's recent efforts: a fundementally broken troll pull-req raising
the blocksize to 2MB that simply can't be merged for reasons unrelated
to the blocksize, followed by very public and loud efforts to spin a
non-issue - closing a pull-req that had no real impact on blockchain
capacity - into a broader reddit furor over a "changed" policy on
scaling. As a PR effort to the public this was fairly effective: framing
the Core dev team's actions as a change and raising the blocksize as a
default action puts the team on the defensive. As a way of building
consensus among the Core dev team, Garzik's actions are very
counterproductive.

I personally have a fairly high tolerance to trolling, but I wouldn't be
surprised if other devs start getting tired of this stuff and just leave
Bitcoin development to focus on more productive stuff. To many it's
discouraging when the other side gets to "promise ponies" - we've got a
fundamentally uphill PR battle in arguing for the development of
scalability tech.

For the long term, I think it'd be useful for research to be done on how
to better manage these social issues. I suspect a lot of the problem -
at least for non-scalable blockchain designs - stems from how
centralization failures aren't gradual, and the ease of relying on trust
rather than verification. While we get a lot of warning of issues, the
warning isn't directly associated with losses at first, making the
problem hard to explain to the general public.

> =3D=3D=3D
>=20
> My personal opinion is that we - as a community - should indeed let a fee
> market develop, and rather sooner than later, and that "kicking the can
> down the road" is an incredibly dangerous precedent: if we are willing to
> go through the risk of a hard fork because of a fear of change of
> economics, then I believe that community is not ready to deal with change
> at all. And some change is inevitable, at any block size. Again, this does
> not mean the block size needs to be fixed forever, but its intent should =
be
> growing with the evolution of technology, not a panic reaction because a
> fear of change.

Agreed.

You know, those promoting the idea of a "one-time-only" blocksize
increase would do well to get the stakeholders affected to publicly
explain what exactly are their plans with regard to scalability in the
long run. If they don't have any, then it's a strong sign that said
stakeholders don't actually intend to have a "one-time-only" blocksize
increase. Remember that there's no guarantee that the technology
limiting the blocksize will improve as fast as desired, or even for that
matter, improve at all. (bandwidth is limited by politics far more than
it is limited by technology)

There's strong parallels to zeroconf safety, where as far as I can tell
the relevant stakeholders - pretty much all large payment providers -
have no plans at all to move to genuine decentralized zeroconf
technology. Rather they have backup plans to get into dangerous and
centralizing mining contracts if zeroconf security gets any worse,
something Coinbase even publicly admitted on this list.

--=20
'peter'[:-1]@petertodd.org
000000000000000014e0038d4c6614025cf655cc976fcd11ee4c4f7861136b9f

--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVth82XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMzgzMGJmMGFlMTBkYjAyODFlYTMwOGFlZjAyYjc3N2U1
MWFlZWY0ZjE2Y2NmNDcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfu8lgf+K4MkFAhsGmxd8kFwir6VZ2vl
FdRQsmHap5ChXzdS2ShmSS6T30w/T8WoaYAN2dDPEF5zhNzhkL/Dt2T3RiH9BWAV
9VUo7Cp5EpF0MtrLgyfsph0OqffAPkyRfET5monFQPR77ce15tiLBtTPfLbKOAJt
cNGtg1HHjgPo3bXy5Un1dvj48n8rIzQKpnTI5zrV2fnSx+t/zR8cFXHxwu6mFF8B
VmpI6To3DkjtDyFKRokIqFvIBM+HxoSeGEShJPDizvTytbGmxS59gEASrPKhME2S
le1xgXSpWT7xAVvHARlf0WoWFapWYsCfI3892sdzwIH83SJuuDpx/u+oh7I8RA==
=qwD0
-----END PGP SIGNATURE-----

--W/nzBZO5zC0uMSeA--