[bitcoin-dev] Block size: It's economics & user preparation & moral hazard

Jeff Garzik jgarzik at gmail.com
Fri Dec 18 05:11:48 UTC 2015

On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wuille at gmail.com>

> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev at 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.

Diverging from the satoshi block size change plan[1] and current economics
would seem to require a high level of months-ahead communication to users.

> 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.

Segregated Witness does not kick the can, it solves none of the problems
#1, #3 - #8 explicitly defined and listed in email #1.

1)  A plan of "SW + no hard fork" is gambling with ECE risk, gambling there
will be no Fee Event, because the core block size is still heavily
contended -- 100% contended at time out SW rollout.

2) We are only 100% certain that bitcoin works in the
blocks-not-full-on-avg state, where there is a healthy buffer between the
hard limit and the average block size.

There is remains major ECE risk due to the core block size freeze, possibly
pushing the system into a new, untried economic state and causing major
market and actor disruption.  Users of the Service can still drift randomly
and unpredictably into a Fee Event.

SW mitigates this
- only after several months
- only assuming robust adoption rates by up-layer ecosystem software, and
- only assuming transaction volume growth is flat or sub-linear

Those conditions *must* go as planned to fulfill "SW kicked the can" -- a
lot of if's.

As stated, SW is orthogonal to the drift-into-uncharted-waters problem
outlined in email #1, which a short term bump does address.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/df9746ce/attachment.html>

More information about the bitcoin-dev mailing list