From: Peter Todd <pete@petertodd•org>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Date: Mon, 27 Jul 2015 08:08:29 -0400 [thread overview]
Message-ID: <20150727120829.GA27361@savin.petertodd.org> (raw)
In-Reply-To: <CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7529 bytes --]
On Wed, Jul 22, 2015 at 12:52:20PM -0400, Pieter Wuille via bitcoin-dev wrote:
> Hello all,
>
> I'd like to talk a bit about my view on the relation between the Bitcoin
> Core project, and the consensus rules of Bitcoin.
>
> I believe it is the responsibility of the maintainers/developers of Bitcoin
> Core to create software which helps guarantee the security and operation of
> the Bitcoin network.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
> ===
>
> 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.
--
'peter'[:-1]@petertodd.org
000000000000000014e0038d4c6614025cf655cc976fcd11ee4c4f7861136b9f
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-07-27 12:08 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
2015-07-22 16:52 ` Pieter Wuille
2015-07-22 17:18 ` Ross Nicoll
2015-07-22 17:32 ` Milly Bitcoin
2015-07-22 18:45 ` Bryan Cheng
2015-07-22 17:33 ` Jeff Garzik
2015-07-22 18:01 ` Jeff Garzik
2015-07-22 18:03 ` Alex Morcos
2015-07-22 18:24 ` Jeff Garzik
2015-07-23 12:17 ` Jorge Timón
2015-07-23 16:17 ` Tom Harding
2015-07-23 16:28 ` Gavin Andresen
2015-07-23 16:50 ` cipher anthem
2015-07-23 17:14 ` Robert Learney
2015-07-23 18:21 ` Eric Lombrozo
2015-07-23 18:47 ` Jorge Timón
2015-07-23 17:43 ` Eric Lombrozo
2015-07-23 18:10 ` Jameson Lopp
2015-07-23 19:14 ` Eric Lombrozo
2015-07-23 19:35 ` Gavin Andresen
2015-07-23 19:39 ` Eric Lombrozo
2015-07-23 19:51 ` Eric Lombrozo
2015-07-23 19:52 ` Jameson Lopp
2015-07-23 20:26 ` Jorge Timón
2015-07-23 20:52 ` Eric Lombrozo
2015-07-23 23:42 ` Benedict Chan
[not found] ` <42BF7FEB-320F-43BE-B3D9-1D76CB8B9975@gmai>
2015-07-23 23:57 ` Eric Lombrozo
2015-07-24 0:04 ` Eric Lombrozo
2015-07-24 0:20 ` Simon Liu
2015-07-24 0:22 ` Jean-Paul Kogelman
2015-07-24 0:32 ` Eric Lombrozo
2015-07-24 0:38 ` Eric Lombrozo
2015-07-24 0:45 ` Jean-Paul Kogelman
2015-07-24 0:49 ` Jean-Paul Kogelman
2015-07-24 0:53 ` Peter Todd
2015-07-24 1:03 ` Jean-Paul Kogelman
2015-07-24 1:08 ` Eric Lombrozo
2015-07-24 1:25 ` Jean-Paul Kogelman
2015-07-24 1:28 ` Eric Lombrozo
2015-07-24 1:37 ` Eric Lombrozo
2015-07-24 1:42 ` Jean-Paul Kogelman
2015-07-24 1:55 ` Eric Lombrozo
2015-07-24 2:12 ` [bitcoin-dev] Bitcoin, Perceptions, and Expectations Raystonn .
2015-07-24 8:48 ` Jonas Schnelli
2015-07-24 9:42 ` Jorge Timón
2015-07-24 14:37 ` Vincent Truong
2015-07-25 2:18 ` gb
2015-07-25 11:22 ` Slurms MacKenzie
2015-07-25 15:04 ` Thomas Kerin
2015-07-24 0:56 ` [bitcoin-dev] Bitcoin Core and hard forks Eric Lombrozo
2015-07-24 1:05 ` Jean-Paul Kogelman
2015-07-23 18:12 ` Slurms MacKenzie
2015-07-23 18:57 ` Mike Hearn
2015-07-23 17:51 ` Jorge Timón
2015-07-24 6:30 ` Tom Harding
2015-07-24 9:24 ` Jorge Timón
2015-07-24 22:50 ` Tom Harding
2015-07-28 11:29 ` Jorge Timón
2015-07-28 11:32 ` Jorge Timón
2015-07-28 16:44 ` Tom Harding
2015-07-28 17:33 ` Jorge Timón
2015-07-22 19:17 ` Eric Lombrozo
2015-07-22 21:43 ` Mike Hearn
2015-07-22 21:56 ` Eric Lombrozo
2015-07-22 22:01 ` Mike Hearn
2015-07-22 22:09 ` Eric Lombrozo
2015-07-23 1:53 ` Eric Lombrozo
2015-07-22 22:30 ` Jeff Garzik
2015-07-23 0:27 ` Tom Harding
2015-07-23 0:37 ` Eric Lombrozo
2015-07-23 4:40 ` Edmund Edgar
2015-07-27 12:08 ` Peter Todd [this message]
2015-07-27 12:44 ` Milly Bitcoin
2015-07-22 22:40 Raystonn
2015-07-22 23:42 ` Cory Fields
2015-07-22 23:53 ` Eric Lombrozo
2015-07-23 0:05 ` Cory Fields
2015-07-23 0:13 ` Eric Lombrozo
2015-07-23 0:34 ` Cory Fields
2015-07-23 0:43 ` Eric Lombrozo
2015-07-23 7:24 ` Ross Nicoll
2015-07-23 0:49 ` Eric Voskuil
2015-07-23 18:12 ` Jorge Timón
[not found] <BA7ACCE1-81B2-4AC1-B6DD-7A856FD27D52@gmail.com>
2015-07-23 8:24 ` Gareth Williams
2015-07-27 17:05 Alice Larson
2015-07-27 17:22 ` Eric Voskuil
2015-07-28 4:55 ` Wladimir J. van der Laan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150727120829.GA27361@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox