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
159
160
161
162
163
164
165
166
167
168
169
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3981C504
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Jul 2017 23:22:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com
[209.85.213.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7C8C7193
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Jul 2017 23:22:39 +0000 (UTC)
Received: by mail-vk0-f51.google.com with SMTP id r125so25374701vkf.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 07 Jul 2017 16:22:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=tp22mJ8G2dKcRd9WZO1lGQzBPJvNDZwwmRNRotFdfKM=;
b=G7anE+FNinIyBdCiSqvMUCUVIl2OANtWmzNRTKalLOejNrV40PJgXTAsITCz8A3CUQ
Id93r7y0xRBBgNpby03CFJ/CqJEaJh2VRWOTnkH0Z9eqcXx6f4W/+g7hBKVCbjip/rBx
62L98CBhC7ZImKDNteEXIOdcI+kT34fg/bbF1ZiZ+u2h2JeHmaERvECRIhrXe0wHHa7w
RMu1xADsEn1SKkS8Ulj04L2gsXAUsz3T8sgDAaavepdK7644/MvOigD4NxlgaNr42t+r
AHHm1M034lLOVyNVO63/rrOMF8fRuJVF0/KwTRHlF9Zfc5hgStfMJCOdM7a5r6WEU+Wh
t1zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=tp22mJ8G2dKcRd9WZO1lGQzBPJvNDZwwmRNRotFdfKM=;
b=LK+LvFLuI7OR4KC+pnvRLZnC9qnH5UlONH5uIkq+LL7Z8RWDaXgyOZ6XEVS7wRF7kI
IYl+iW8462fiCeiN2m6S3EoaPqoyvAlZ3gLDPZkX/LJGUH4bjpPQQ+5HpyABUIV5tStn
atR0gStGXh0dqisUKv1L3KaiU4Mb6PxnkcDl4j9TkLu3xUpBCMi0M1NaWpO3mVpQ27AR
k52wEXp+Ool/+5GFE0mshyiG1H6MriQRIbx8CYPa4fQ2ME2UWjBlWBHyKg9kvRr2ocNv
vYsbgAicUTksetv1u73lXxJp+xC74Z85/tR1YkfaMokuGhm1+ZbflZiGpIZ8JB2fK5iZ
P6rg==
X-Gm-Message-State: AIVw110v1PKgDteRxRhSo/d/zmK1a7hdAJU1yWnLpf7/nul0PQ0aL4Lt
P95lNaELngp9DzAQH1UstyxGGDWj8w==
X-Received: by 10.31.158.77 with SMTP id h74mr1802264vke.84.1499469758521;
Fri, 07 Jul 2017 16:22:38 -0700 (PDT)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.40.2 with HTTP; Fri, 7 Jul 2017 16:22:38 -0700 (PDT)
In-Reply-To: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Fri, 7 Jul 2017 23:22:38 +0000
X-Google-Sender-Auth: _qMbH2AXy9eOdjC8yR88XQAjVNI
Message-ID: <CAAS2fgRAdKFu8JqbmtAES3NkX2BK27LucSf=heZ2xyz30BKetw@mail.gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Segwit2x BIP
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Fri, 07 Jul 2017 23:22:40 -0000
On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello,
>
> Here is a BIP that matches the reference code that the Segwit2x group has
> built and published a week ago.
I'm happy to see that someone has begun writing a specification. But I
am appalled to see one just being written now for change it's authors
expect to be irreversibly applied to the network in less than 30 days.
The timeline of this proposal is recklessly short to such an extreme
level that we have never, to the best of my knowledge, seen a prior
proposal so hasty. Nowhere does this specification provide
justification or assurance that this is at all safe. The time line of
it violates the most minimal of responsible engineering practices, by
being shorter than even a fast development and release candidate
timeframe. This proposal carries an extreme risk for parties to lose
money due to transaction reversals at two distinct points in time and
provides no proposed countermeasures to avoid these losses.
The proposal adds another gratuitous limit to the system: A maximum
transaction size where none existed before, yet this limit is almost
certainly too small to prevent actual DOS attacks while it is also
technically larger than any transaction that can be included today
(the largest possible transaction today is 1mb minus the block
overheads). The maximum resource usage for maliciously crafted 1MB
transaction is enormous and permitting two of them greatly exacerbates
the existing vulnerability.
> Assuming the current transaction pattern is replicated in a 2 MB plain-sized block that is 100% filled with transactions, then the witness-serialized block would occupy 3.6 MB
But in a worst case the result would be 8MB, which this document fails
to mention.
> This is considered safe by many users, companies, miners and academics [2].
The claim that the document's [2] says that these increases are "safe"
is incorrect and is a matter which has been previously corrected by
the authors of the document:
https://www.reddit.com/r/btc/comments/626ud7/coauthor_of_the_paper_that_blockstream_core_keep/dflrshg/
.
The cited paper does an approximate best case analysis considering
only a couple of risk factors (in particular, block relay time, but
ignoring durability to dos attacks, robustness against state
intervention, and initial synchronization time) and concluded that 4MB
was the largest they could argue was safe. The paper goes on to then
argue that even if you crank Bitcoin's parameters to the maximum in
those dimensions that it doesn't result in a truly meaningful increase
in scalablity-- in effect, it's a weak argument against your proposal
and ones like it.
> Deploy a modified BIP91 to activate Segwit. The only modification is that the signal "segsignal" is replaced by "segwit2x".
This means that BIP-91 and your proposal are indistinguishable on the
network, because the string "segsignal" is merely a variable name used
in the software.
> If segwit2x (BIP91 signal) activates at block N,
The proposal is unable to distinguish itself from BIP-91. Does this
mean if segwit2x or BIP91 activates ?
> This reduces the fee pressure on users and companies creating on-chain transactions, matching market expectations and preventing further market disruption
Considering that we just spent the whole weekend with the mempool
having ~1 block or less worth of transactions most of the time, it
seems highly likely that just activating segwit will substantially
disrupt the fee market; to say nothing for the further doubling that
isn't even tempered by new wallet adoptions. There seems to be no
consideration given to avoiding this disruption and preventing further
emergency events when the new capacity is eventually used and software
is again left unprepared for having to pay market fees.
> and buy time for more comprehensive solutions to be developed and tested
In effect, the document admits that it isn't a solution that
meaningfully improves the scale or scalablity but rather it's just a
bailout to temporarily lower/negate transaction fees. It doesn't seem
to make any argument (or even acknowledge) that the risks and
disruption are worth its benefit, and it exacerbates those risks by
being the product of a closed process and having a timeline shorter
than basically any software update for production software (much less
the timeframe for any consensus update previously). Kudos for being
frank here, but it's not exactly selling itself.
It seems to me that the document doesn't really even make an effort to
justify the bailout at all and don't explain how it will result in
anything except an endless series of additional fee bailouts.
Moreover, it doesn't discuss any remediation against the replay
exposure that the proposed hardfork is sure to create. ( I can
guarantee to you, I will not adopt this hardfork; especially given
that is has been made completely clear that the terms of it were set
in its closed door meetings and the input of non-supporters was not
welcome. )
|
