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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
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 321BEC8D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 20:59:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com
[209.85.213.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A2D80169
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 20:59:41 +0000 (UTC)
Received: by mail-ig0-f169.google.com with SMTP id jw2so6020717igc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 12:59:41 -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=648wifAd2Pw3wD8WmuUIVRrijxseXk7O1boQ/Cf47xA=;
b=VaDbS542reWIqghqBEM4qYCF/B4s4UoAQC5LKekr9+Uu11r1u0u49+c+aqguhh0R1r
kHg0mEFMKRBBJZYoh//oGonYMPWD/jV2Il5kbKUhdzzcq8TA/FpjBb7OZzUF4aLYq8Aj
4Nm/mfSdyquFA3JQfSQ6rsHqp6ROjv4zKETnJ0jbbs6YMLpR0SnjG6FI1uv530TN5Uf0
3kblNWECan5zUTY2I3VHtKfX6+zTWDo7Mwt6jxY2WXB4wCNsjzAWqUL/sw2aDuGMrHFL
7+rkEKkmZL9wXCrePJh1GnVU/ZpBdjJO1/ARfbyGvcCsxvn4qCBaPubYoI60rKSjLlff
uOWA==
MIME-Version: 1.0
X-Received: by 10.50.171.197 with SMTP id aw5mr12841142igc.21.1450299581151;
Wed, 16 Dec 2015 12:59:41 -0800 (PST)
Received: by 10.36.80.6 with HTTP; Wed, 16 Dec 2015 12:59:41 -0800 (PST)
In-Reply-To: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
Date: Wed, 16 Dec 2015 21:59:41 +0100
Message-ID: <CAPg+sBhUso0ddfYQMgwF7yX9_VoqP9CZN5h45t3eQi4v3m6f6A@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 20:59:42 -0000
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
|
