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] Segregated Witness in the context of Scaling Bitcoin
Date: Wed, 16 Dec 2015 21:59:41 +0100 [thread overview]
Message-ID: <CAPg+sBhUso0ddfYQMgwF7yX9_VoqP9CZN5h45t3eQi4v3m6f6A@mail.gmail.com> (raw)
In-Reply-To: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
On Wed, Dec 16, 2015 at 9:38 PM, Jeff Garzik via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> 4.3. Observations on new block economic model
>
> SW complicates block economics by creating two separate, supply limited
> resources.
Not correct. I propose defining the virtual_block_size as base_size +
witness_size * 0.25, and limiting virtual_block_size to 1M. This
creates a single variable to optimize for. If accepted, miners are
incentived to maximize fee per virtual_block_size instead of per size.
Wallet software can individually choose whether to upgrade or not.
Once they upgrade, they get to perform 1.75x as many transactions for
the same fee (assuming non-complex transactions), and this is
independent of whether anyone else upgrades.
> 5.1. Problem: Pace of roll-out will be slow - Whole Ecosystem must be
> considered.
>
> The current apparent proposal is to roll out Segregated Witness as a soft
> fork, and keep block size at 1M.
>
> The roll-out pace cannot simply be judged by soft fork speed - which is
> months at best. Analysis must the layers above: Updating bitcoin-core (JS)
> and bitcoinj (Java), and then the timelines to roll out those updates to
> apps, and then the timeline to update those apps to create extended
> transactions.
Agree, however everyone can upgrade whenever they want, and get the
reduced fees as soon as they do. This is contrary to a hard fork,
which forces every full node to upgrade at once (though indeed, light
clients are not necessarily forced to upgrade).
> 5.2. Problem: Hard fork to bigger block size Just Works(tm) with most
> software, unlike SW.
>
> A simple hard fork such as BIP 102 is automatically compatible with the vast
> range of today's ecosystem software.
>
> SW requires merchants to upgrade almost immediately, requires wallet and
> other peripheral software upgrades to make use of. Other updates are opt-in
> and occur more slowly. BIP 70 processors need some updates.
>
> The number of LOC that must change for BIP 102 is very small, and the
> problem domain well known, versus SW.
It multiplies all current DoS vectors by a factor equal to the
capacity increase factor. SW increases capacity while leaving several
worst-case effects constant.
> 5.4. Problem: More complex economic policy, new game theory, new bidding
> structure risks.
>
> Splitting blocks into two pieces, each with separate and distinct behaviors
> and resource values, creates two fee markets.
I believe you have misunderstood the proposal in that case.
> 5.5. Problem: Current SW mining algorithm needs improvement
>
> Current SW block template maker does a reasonable job, but makes some naive
> assumptions about the fee market across an entire extended block. This is a
> mismatch with the economic reality (just described).
Again, I think you misunderstood. The proposal includes a single new
formula for block size, and optimizes for it. In case the proposal is
accepted, the mining code is automatically as optimal as it was
before.
> 6. Conclusions and recommendations
>
> A "short term bump" hard fork block size increase addresses economic and
> ecosystem risks that SW does not.
>
> Bump + SW should proceed in parallel, independent tracks, as orthogonal
> issues.
I agree here. SW is not a replacement for a scale increase. However, I
think it can be adopted much more easily, as it doesn't require the
massively pervasive consensus that a hardfork requires to perform
safely.
> 7. Appendix - Other SW comments
>
> Hard forks provide much stronger validation, and ensure the network operates
> at a fully trustless level.
>
> SW hard fork is preferred, versus soft fork. Soft forking SW places a huge
> amount of trust on miners to validate transaction signatures, versus the
> rest of the network, as the network slowly upgrades to newer clients.
But old clients may not care about the new rules, and they still
validate the old ones they chose to enforce.
Furthermore, soft forks cannot be prevented: miners can always choose
to enforce stronger rules than the network demands from them.
--
Pieter
next prev parent reply other threads:[~2015-12-16 20:59 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 20:38 Jeff Garzik
2015-12-16 20:50 ` Matt Corallo
2015-12-16 21:51 ` Jameson Lopp
2015-12-16 22:29 ` Matt Corallo
2015-12-16 22:32 ` Matt Corallo
2015-12-17 2:21 ` Jeff Garzik
2015-12-17 2:44 ` Eric Lombrozo
2015-12-17 2:58 ` Jeff Garzik
2015-12-17 3:48 ` Adam Back
2015-12-17 5:32 ` jl2012
2015-12-17 7:54 ` Corey Haddad
2015-12-17 13:09 ` Jorge Timón
2015-12-17 15:51 ` sickpig
2015-12-17 17:55 ` Anthony Towns
2015-12-18 10:01 ` sickpig
2015-12-19 7:50 ` Mark Friedenbach
2015-12-19 23:03 ` Dave Scotese
2015-12-17 9:33 ` Mark Friedenbach
2015-12-17 10:00 ` jl2012
2015-12-17 10:57 ` Anthony Towns
2015-12-17 6:14 ` Marcel Jamin
2015-12-16 20:59 ` Pieter Wuille [this message]
2015-12-16 21:27 ` Jeff Garzik
2015-12-16 21:36 ` Pieter Wuille
2015-12-16 22:09 ` Jeff Garzik
2015-12-16 22:10 ` Jeff Garzik
2015-12-17 18:27 ` Jeff Garzik
2015-12-17 18:46 ` jl2012
2015-12-17 18:52 ` Jeff Garzik
2015-12-17 21:18 ` Eric Lombrozo
2015-12-17 21:31 ` Adam Back
2015-12-17 3:52 ` Anthony Towns
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+sBhUso0ddfYQMgwF7yX9_VoqP9CZN5h45t3eQi4v3m6f6A@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