1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0723FEEB
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 03:52:30 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DCBFA89
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 03:52:28 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian))
id 1a9PcA-0007R1-5F for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 13:52:27 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Thu, 17 Dec 2015 13:52:22 +1000
Date: Thu, 17 Dec 2015 13:52:22 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20151217035222.GA7713@sapphire.erisian.com.au>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
<CAPg+sBhUso0ddfYQMgwF7yX9_VoqP9CZN5h45t3eQi4v3m6f6A@mail.gmail.com>
<CADm_WcYZq3nzfYMXfzkZsTCsgmzy4L_nYpa5Kax8uF_ajuUTiQ@mail.gmail.com>
<CAPg+sBiVVcNNHuV9e1SaPoDSMEwjZHL7tQiszxbE2SQYp1Ongw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPg+sBiVVcNNHuV9e1SaPoDSMEwjZHL7tQiszxbE2SQYp1Ongw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD,
UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling
Bitcoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 03:52:30 -0000
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
|
