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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8768BE78
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 21:36:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com
[209.85.213.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 322CBED
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 21:36:10 +0000 (UTC)
Received: by mail-ig0-f174.google.com with SMTP id to4so85190229igc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 13:36:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=s3So3Y08u3IYSowDzrcdtxlaDVf2/CO0e3ovG18gZ+4=;
b=BmeD47hPlO5NOxatNqv5B+rQ8n9/uWtZcxBzsxteZq2KgfwJb4dt46vanYcf/exjre
0x9KZ1HVWjKaI7fkdzWfUvrXKpLsBV5/TNyd56Wp0B6ysMiL4Agaiel3pSRgtcnozYel
/slsFXdONIJdS4xqEx7tQ1RbEfWGsDdm4OTqZ5hdPwDrlv88LlNzLDC0ejmJ3QPmHIbP
VWVgJXys0Ve0xC8HGL1X6orAiC+FFyiYXA0+5URvoBWmgcJkEYE/QsV6WKMowSB0otPx
DIUl/EG31sUU072FuUvGB+alc5KO6LhbFz82QD7FxL/wzSi2gEuEm2VW7bTdSQf2GZWM
es/g==
MIME-Version: 1.0
X-Received: by 10.107.165.197 with SMTP id o188mr21193442ioe.132.1450301769666;
Wed, 16 Dec 2015 13:36:09 -0800 (PST)
Received: by 10.36.80.6 with HTTP; Wed, 16 Dec 2015 13:36:09 -0800 (PST)
In-Reply-To: <CADm_WcYZq3nzfYMXfzkZsTCsgmzy4L_nYpa5Kax8uF_ajuUTiQ@mail.gmail.com>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
<CAPg+sBhUso0ddfYQMgwF7yX9_VoqP9CZN5h45t3eQi4v3m6f6A@mail.gmail.com>
<CADm_WcYZq3nzfYMXfzkZsTCsgmzy4L_nYpa5Kax8uF_ajuUTiQ@mail.gmail.com>
Date: Wed, 16 Dec 2015 22:36:09 +0100
Message-ID: <CAPg+sBiVVcNNHuV9e1SaPoDSMEwjZHL7tQiszxbE2SQYp1Ongw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Jeff Garzik <jgarzik@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.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: Wed, 16 Dec 2015 21:36:10 -0000
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.
Maybe I haven't explained this properly, so consider this example:
A miner receives sets of 200 byte transactions with all identical
fees. Non-witness ones (whose virtual size is thus 200 bytes) and a
witness one (where 120 of the 200 bytes are witness data, so its
virtual size is 80 + 120*0.25 = 110 bytes).
The consensus rules would limit 1) the base size to 1000000 bytes 2)
the virtual size to 1000000 bytes. However, as the virtual size is
defined as the sum of the base size plus a non-negative number,
satisfying (2) always implies satisfying (1).
Thus, the miners' best strategy is to accept the witness transactions,
as it allows 1000000/110=9090 transactions rather than
1000000/200=5000.
In fact, the optimal fee maximizing strategy is always to maximize fee
per virtual size.
--
Pieter
|
