MIME-Version: 1.0
In-Reply-To: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
Date: Wed, 22 Jul 2015 12:52:20 -0400
Message-ID: <CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11425d0623a208051b799817
Subject: [bitcoin-dev] Bitcoin Core and hard forks
Precedence: list

--001a11425d0623a208051b799817
Content-Type: text/plain; charset=UTF-8

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.

===

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.

But I am not in any position to force this view. I only hope that people
don't think a fear of economic change is reason to give up consensus.

-- 
Pieter

--001a11425d0623a208051b799817
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Hello all,</p>
<p dir=3D"ltr">I&#39;d like to talk a bit about my view on the relation bet=
ween the Bitcoin Core project, and the consensus rules of Bitcoin.</p>
<p dir=3D"ltr">I believe it is the responsibility of the maintainers/develo=
pers of Bitcoin Core to create software which helps guarantee the security =
and operation of the Bitcoin network.</p>
<p dir=3D"ltr">In addition to normal software maintenance, bug fixes and pe=
rformance improvements, this includes DoS protection mechanism deemed neces=
sary to keep the network operational. Sometimes, such (per-node configurabl=
e) policies have had economic impact, for example the dust rule.</p>
<p dir=3D"ltr">This also includes participating in discussions about consen=
sus changes, but not the responsibility to decide on them - only to impleme=
nt them when agreed upon. It would be irresponsible and dangerous to the ne=
twork and thus the users of the software to risk forks, or to take a leadin=
g 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.</p>
<p dir=3D"ltr">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 Bitcoi=
n 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 t=
aking that decision, not less.</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">=3D=3D=3D</p>
<p dir=3D"ltr">My personal opinion is that we - as a community - should ind=
eed let a fee market develop, and rather sooner than later, and that &quot;=
kicking the can down the road&quot; is an incredibly dangerous precedent: i=
f 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 wi=
th 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 b=
ecause a fear of change.</p>
<p dir=3D"ltr">But I am not in any position to force this view. I only hope=
 that people don&#39;t think a fear of economic change is reason to give up=
 consensus.</p>
<p dir=3D"ltr">-- <br>
Pieter</p>

--001a11425d0623a208051b799817--