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: Fri, 18 Dec 2015 08:56:58 +0100 [thread overview]
Message-ID: <CAPg+sBjbATqf8DXGF7obw9a=371zQ_S0EgTapnUmukAVenTneQ@mail.gmail.com> (raw)
In-Reply-To: <CADm_WcbrMyk-=OnQ-3UvnF_8brhn+X2NqRPbo5xUXsbcZpc0=Q@mail.gmail.com>
On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik <jgarzik@gmail•com> wrote:
>> 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.
I don't see any plan, but will you say the same thing when the subsidy
dwindles, and mining income seems to become uncertain? It will equally
be an economic change, which equally well will have been predictable,
and it will equally well be treatable with a hardfork to increase the
subsidy.
Yes, I'm aware the argument above is a straw man, because there was
clear expectation that the subsidy would go down asymptotically, and
much less an expectation that the blocksize would remain fixed
forever.
But I am not against a block size increase hard fork. My talk on
segregated witness even included proposed pursuing a hard fork at a
slightly later stage.
But what you're arguing for is that - despite being completely
expected - blocks grew fuller, and people didn't adapt to block size
pressure and a fee market, so the Core committee now needs to kick the
can down the road, because we can't accept the risk of economic
change. That sounds very much like a bailout to me.
Again. I am not against growth, but increasing in response to fear of
economic change is the wrong approach. Economic change is inevitable.
> 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.
That is an assumption. I expect demand for transactions at a given
feerate to stop growing at a certain contention level (and we've
reached some level of contention already, with mempools not being
cleared for significant amounts of time already).
> SW mitigates this
> - only after several months
That is assuming a hard fork consensus forming, deployment,
activation, ... goes faster than a softfork.
> - only assuming robust adoption rates by up-layer ecosystem software, and
That's not required. Everyone who individually switches to new
transactions gets to do 1.75x more transactions for the same price
(and at the same time gets safer contracts, better script
upgradability, and more security models at their disposal), completely
independent of whether anyone else in the ecosystem does the same.
> - only assuming transaction volume growth is flat or sub-linear
The only question is how many transactions for what price. Contention
always happens at a specific feerate level anyway.
> 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.
Both SW and a short bump (which is apparently not what BIP102 does
anymore?) increase capacity available per price, and yes, they are
completely orthogonal.
My only disagreement is the motivation (avoiding economic change, as
opposed to aiming for safe growth) and the claim that a capacity
increase hardfork is easier and safe(r) to roll out quickly than
sortfork SW.
Apart from that, we clearly need to do both at some point.
--
Pieter
next prev parent reply other threads:[~2015-12-18 7:56 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
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 [this message]
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+sBjbATqf8DXGF7obw9a=371zQ_S0EgTapnUmukAVenTneQ@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