From: Pieter Wuille <pieter.wuille@gmail•com>
To: Jeff Garzik <jgarzik@gmail•com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard
Date: Wed, 16 Dec 2015 19:34:32 +0100 [thread overview]
Message-ID: <CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com> (raw)
In-Reply-To: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> 2) If block size stays at 1M, the Bitcoin Core developer team should sign a
> collective note stating their desire to transition to a new economic policy,
> that of "healthy fee market" and strongly urge users to examine their fee
> policies, wallet software, transaction volumes and other possible User
> impacting outcomes.
You present this as if the Bitcoin Core development team is in charge
of deciding the network consensus rules, and is responsible for making
changes to it in order to satisfy economic demand. If that is the
case, Bitcoin has failed, in my opinion.
What the Bitcoin Core team should do, in my opinion, is merge any
consensus change that is uncontroversial. We can certainly -
individually or not - propose solutions, and express opinions, but as
far as maintainers of the software goes our responsibility is keeping
the system running, and risking either a fork or establishing
ourselves as the de-facto central bank that can make any change to the
system would greatly undermine the system's value.
Hard forking changes require that ultimately every participant in the
system adopts the new rules. I find it immoral and dangerous to merge
such a change without extremely widespread agreement. I am personally
fine with a short-term small block size bump to kick the can down the
road if that is what the ecosystem desires, but I can only agree with
merging it in Core if I'm convinced that there is no strong opposition
to it from others.
Soft forks on the other hand only require a majority of miners to
accept them, and everyone else can upgrade at their leisure or not at
all. Yes, old full nodes after a soft fork are not able to fully
validate the rules new miners enforce anymore, but they do still
verify the rules that their operators opted to enforce. Furthermore,
they can't be prevented. For that reason, I've proposed, and am
working hard, on an approach that includes Segregated Witness as a
first step. It shows the ecosystem that something is being done, it
kicks the can down the road, it solves/issues half a dozen other
issues at the same time, and it does not require the degree of
certainty needed for a hardfork.
--
Pieter
next prev parent reply other threads:[~2015-12-16 18:34 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 14:53 Jeff Garzik
2015-12-16 18:34 ` Pieter Wuille [this message]
2015-12-16 21:08 ` Jeff Garzik
2015-12-16 21:11 ` Pieter Wuille
2015-12-17 2:06 ` Jameson Lopp
2015-12-17 16:58 ` Tier Nolan
2015-12-17 19:44 ` Peter Todd
2015-12-18 5:23 ` Jorge Timón
2015-12-18 9:44 ` Tier Nolan
2015-12-16 21:24 ` Jorge Timón
2015-12-16 21:36 ` Jeff Garzik
2015-12-18 5:11 ` Jeff Garzik
2015-12-18 7:56 ` Pieter Wuille
2015-12-18 10:13 ` sickpig
2015-12-18 15:48 ` Pieter Wuille
2015-12-19 19:04 ` Dave Scotese
[not found] ` <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com>
2015-12-26 16:44 ` Pieter Wuille
2015-12-26 17:20 ` Jorge Timón
2015-12-26 22:55 ` Jonathan Toomim
2015-12-26 23:01 ` Pieter Wuille
2015-12-26 23:07 ` Jonathan Toomim
2015-12-26 23:16 ` Pieter Wuille
2015-12-27 0:03 ` Jonathan Toomim
2015-12-26 23:15 ` Justus Ranvier
2015-12-27 0:13 ` Bryan Bishop
2015-12-27 0:33 ` Justus Ranvier
2015-12-18 13:56 ` Jeff Garzik
2015-12-23 6:26 ` Aaron Voisine
2015-12-16 18:36 ` jl2012
2015-12-16 22:27 ` Jeff Garzik
2015-12-17 6:12 ` Dave Scotese
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='CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jgarzik@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