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
170
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 94D92486
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 May 2017 16:27:49 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D7914161
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 May 2017 16:27:48 +0000 (UTC)
Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by
mx.zohomail.com with SMTPS id 1494347264716696.4950494769296;
Tue, 9 May 2017 09:27:44 -0700 (PDT)
From: Johnson Lau <jl2012@xbt.hk>
Message-Id: <F5DCF911-5FCB-4FA7-8D42-86422CF366E8@xbt.hk>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_BAC82F00-05E5-4D0A-9361-0EC61BDDA2F4"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 10 May 2017 00:27:40 +0800
In-Reply-To: <CAKzdR-rKQaiKF18j44HjxuHY5pcmPwsce5ab-+zGRDnxjhBQdw@mail.gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
References: <CAKzdR-qojNn8OtUTPbxa0JauK9nmo2ZGm4ihKuyzsz_FAgokDw@mail.gmail.com>
<CAMBsKS_j7Lso6fHoMPkrQ7UFwKfxOERAAqL=aUF83O4CqL+iFg@mail.gmail.com>
<CAKzdR-on-w9EF+2hLjchdyHB1gj7fi4QnybA=J4Cz7yyN3KKNA@mail.gmail.com>
<7B918396-5968-4908-83C8-0F77DA8DB037@xbt.hk>
<CAKzdR-rKQaiKF18j44HjxuHY5pcmPwsce5ab-+zGRDnxjhBQdw@mail.gmail.com>
X-Mailer: Apple Mail (2.3259)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE autolearn=ham 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] Some real-world results about the current Segwit
Discount
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: Tue, 09 May 2017 16:27:49 -0000
--Apple-Mail=_BAC82F00-05E5-4D0A-9361-0EC61BDDA2F4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
No, changing from 50% to 75% is a hardfork. (75 -> 50 is a softfork). =
Unless you make it pre-scheduled, or leave a special =E2=80=9Cbackdoor=E2=80=
=9D softfork to change the discount.
And that would certainly reduce the max tx/s with 50% discount, also =
reduce the incentive to spend witness UTXO.=20
> On 10 May 2017, at 00:19, Sergio Demian Lerner =
<sergio.d.lerner@gmail.com> wrote:
>=20
> Thanks Johnson and Hampus for the clarifications.=20
> However, I would rather do the opposite: soft-fork to 50% now, and =
soft-fork again to 75% discount later if needed, because it doesn't =
affect the max transactions/second.=20
>=20
> Segwit as it is today should be activated. However if it is not before =
November, then for the next Segwit attempt I would choose a more =
conservative 50% discount.
>=20
>=20
>=20
> On Tue, May 9, 2017 at 12:45 PM, Johnson Lau <jl2012@xbt.hk =
<mailto:jl2012@xbt.hk>> wrote:
>=20
> > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> >
> > So it seems the 75% discount has been chosen with the idea that in =
the future the current transaction pattern will shift towards multisigs. =
This is not a bad idea, as it's the only direction Bitcoin can scale =
without a HF.
> > But it's a bad idea if we end up doing, for example, a 2X blocksize =
increase HF in the future. In that case it's much better to use a 50% =
witness discount, and do not make scaling risky by making the worse case =
block size 8 Mbytes, when it could have been 2*2.7=3D5.4 Mbytes.
> >
>=20
> As we could change any parameter in a hardfork, I don=E2=80=99t think =
this has any relation with the current BIP141 proposal. We could just =
use 75% in a softfork, and change that to a different value (or =
completely redefine the definition of weight) with a hardfork later.
>=20
>=20
>=20
--Apple-Mail=_BAC82F00-05E5-4D0A-9361-0EC61BDDA2F4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">No, changing from 50% to 75% is a hardfork. =
(75 -> 50 is a softfork). Unless you make it pre-scheduled, or leave =
a special =E2=80=9Cbackdoor=E2=80=9D softfork to change the =
discount.</div><div class=3D""><br class=3D""></div><div class=3D"">And =
that would certainly reduce the max tx/s with 50% discount, also reduce =
the incentive to spend witness UTXO. </div><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
10 May 2017, at 00:19, Sergio Demian Lerner <<a =
href=3D"mailto:sergio.d.lerner@gmail.com" =
class=3D"">sergio.d.lerner@gmail.com</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D"">Thanks Johnson and Hampus for the clarifications. <div =
class=3D"">However, I would rather do the opposite: soft-fork to 50% =
now, and soft-fork again to 75% discount later if needed, because it =
doesn't affect the max transactions/second. <div class=3D""><br =
class=3D""></div><div class=3D"">Segwit as it is today should be =
activated. However if it is not before November, then for the next =
Segwit attempt I would choose a more conservative 50% =
discount.</div><div class=3D""><div class=3D""><br class=3D""></div><div =
class=3D""><div class=3D""><br =
class=3D""></div></div></div></div></div><div class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote">On Tue, May 9, 2017 at 12:45 PM, =
Johnson Lau <span dir=3D"ltr" class=3D""><<a =
href=3D"mailto:jl2012@xbt.hk" target=3D"_blank" =
class=3D"">jl2012@xbt.hk</a>></span> wrote:<br class=3D""><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span class=3D""><br class=3D"">
> On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev =
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a>> =
wrote:<br class=3D"">
><br class=3D"">
><br class=3D"">
> So it seems the 75% discount has been chosen with the idea that in =
the future the current transaction pattern will shift towards multisigs. =
This is not a bad idea, as it's the only direction Bitcoin can scale =
without a HF.<br class=3D"">
> But it's a bad idea if we end up doing, for example, a 2X blocksize =
increase HF in the future. In that case it's much better to use a 50% =
witness discount, and do not make scaling risky by making the worse case =
block size 8 Mbytes, when it could have been 2*2.7=3D5.4 Mbytes.<br =
class=3D"">
><br class=3D"">
<br class=3D"">
</span>As we could change any parameter in a hardfork, I don=E2=80=99t =
think this has any relation with the current BIP141 proposal. We could =
just use 75% in a softfork, and change that to a different value (or =
completely redefine the definition of weight) with a hardfork later.<br =
class=3D"">
<br class=3D"">
<br class=3D"">
</blockquote></div><br class=3D""></div>
</div></blockquote></div><div class=3D""><br =
class=3D""></div></body></html>=
--Apple-Mail=_BAC82F00-05E5-4D0A-9361-0EC61BDDA2F4--
|
