From: Anthony Towns <aj@erisian•com.au>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin
Date: Thu, 17 Dec 2015 13:52:22 +1000 [thread overview]
Message-ID: <20151217035222.GA7713@sapphire.erisian.com.au> (raw)
In-Reply-To: <CAPg+sBiVVcNNHuV9e1SaPoDSMEwjZHL7tQiszxbE2SQYp1Ongw@mail.gmail.com>
On Wed, Dec 16, 2015 at 10:36:09PM +0100, Pieter Wuille via bitcoin-dev wrote:
> On Wed, Dec 16, 2015 at 10:27 PM, Jeff Garzik <jgarzik@gmail•com> wrote:
> >> 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.
> > It is correct. There are two separate sets of economic actors and levels of
> > contention for each set of space.
> > That is true regardless of the proposed miner selection algorithm.
You're right that the miner selection algorithm doesn't force it to be
the way Pieter describe. But your claim is still incorrect. :)
> Maybe I haven't explained this properly, so consider this example:
Alternatively:
With Pieter's segwit proposal (as it stands), there are two
consensus-limited resources: number of signature ops in the base block
must be no more than 20k, and the virtual block size must be no more
than 1MB (where virtual block size = base block size plus a quarter of
the witness data size).
Nodes and miners have other constraints -- bandwidth, storage, CPU, etc,
such that they might not want to max out these limits for whatever reason,
but those limits aren't enforced by consensus, so can be adjusted as
technology improves just by individual miner policy.
> In fact, the optimal fee maximizing strategy is always to maximize fee
> per virtual size.
(modulo sigop constraints, same as today for fee per base block size)
That's on the "supply" side (ie, miners are forced to be a single group
of economic actors with alighned constraints due to consensus rules).
On the demand side, there might be people who are able to trade off
witness data for base data at different ratios. For most, it's just 1:1
up to a limit as they move scriptsig to witness data, and obviously if
you have to trade 1B of base data for more than 4B of witness data it's
uneconomic. But since the ratio is fixed, there's no bartering to be
done, it's just the same simple calculation for everyone -- does 1B of
base convert to <4B of witness? then do it; otherwise, don't. But once
they've selected a tradeoff, all they can do is choose an absolute fee
value for their transaction, and then you're just back to having some
people who are willing to pay higher fees per virtual block size, and
others who are only willing to pay lower fees.
Cheers,
aj
prev parent reply other threads:[~2015-12-17 3:52 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
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 [this message]
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=20151217035222.GA7713@sapphire.erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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