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
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1DC50486
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 May 2017 04:24:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com
[209.85.213.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DEDB212A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 May 2017 04:24:02 +0000 (UTC)
Received: by mail-vk0-f45.google.com with SMTP id x71so27052021vkd.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 May 2017 21:24:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-io.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=NAI0jPjgeoVsLRfWhYkl4E7G8yomnMhOPRP09DZUfJM=;
b=WBDZ+cmLS9BzMf8OsmZzdSx0Ki7pyKpOqgQGWsFE088vlk1qUFBRFZTGGQhiSAAaWX
Id0E+moduH7Z3yyL+1YiFpevg+bzLqunAPKKqZ4/iwMMlVnTxByetaKpQH+c1HoYaxeQ
UyUEliZjRzzBJf9j7Dd1DnYeg0Lcn3PPA57dxWWloUDc0P/Cp0fItam3dodl1p+UhtYq
c47BpA1moLbK4EApMf9t332uQT29QO2gPLteQmWTOsECN/knLBKR6FbrIMmJ+2X7VSeZ
Wwnv0vuRVIL/rvefSJOOajlUtRtBQxUBDODzXm20dRoi3J6c9mYav/8JXmqR5q9Nmw/y
PsLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=NAI0jPjgeoVsLRfWhYkl4E7G8yomnMhOPRP09DZUfJM=;
b=byluiOcZ1jyuC35hibl1w5cTAhWN8bflcS3k7zGNO2W//AsD1MHtlg+PbFbLfGcTml
ED01Xn6jkdTOjrzen/HUqiFpyDu35GA55frDoVKlxg+nDc+j11tY02TDjMEwl3cC+G7N
RsTD3Ri9RhMap04hRIFLG4/0SyOvPF2fTcN2SVs0Ly7AIQn/Mt4ATANNXm0Bb9jd3BxG
Imdz7+2m27XXY8j9Jea1ccb1MsbjY32U9hXKrqJ2tpd6Mttm3lX1A2zv7Y+L+HYv5Qoy
kS0P7KKfcvAgXFE/23ZQeLeEngzsVa4V2rJOflBCvcFjjNaMCxcaVpg2zje5RXVyBYCR
WTeA==
X-Gm-Message-State: AODbwcBb/4ce2oiejlpXCMGkWVQDreqF0/YDH0DyXSfAWQjuarOk3l3r
jAjfGn3FbUIDZykKpEvjPN8+kqn9jP+m
X-Received: by 10.31.65.73 with SMTP id o70mr3635411vka.85.1494649441897; Fri,
12 May 2017 21:24:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.81.48 with HTTP; Fri, 12 May 2017 21:23:41 -0700 (PDT)
In-Reply-To: <201705121922.57445.luke@dashjr.org>
References: <201705121922.57445.luke@dashjr.org>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sat, 13 May 2017 00:23:41 -0400
Message-ID: <CAMZUoKnzV9faJ+mBTTzTre05Ejwnx3tC4ozbiPoPUfS+7GLMTQ@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary="001a114db5fc0c65b2054f60314e"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, 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 Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees
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: Sat, 13 May 2017 04:24:04 -0000
--001a114db5fc0c65b2054f60314e
Content-Type: text/plain; charset="UTF-8"
I recall chatting about this idea recently and my conclusion was the same
as Peter Todd's conclusion: this will just encourage miners to false signal
readiness with undermines both BIP 9 and BIP 8.
I felt that rather than using script system for this construction, it would
be better to use the transaction version number instead by soft-forking in
a rule that says when the most significant bits of a transaction version
are 001 then the transaction can only be included in blocks whose lower 29
version bits are set at the same position as the lower 29 version bits set
in the transaction version.
That is to say, if we have block version blkVersion and transaction version
txVersion, we soft fork in a rule that requires that
(txVersion & 0xe0000000 != 0x020000000) || ((blkVersion & 0xe0000000 =
0x020000000) && (blkVersion & txVersion = txVersion))
While I think that making use of the transaction version number is superior
to adding an opcode, because it doesn't interfere with caching of script
validity and because it doesn't use any more transaction space by making
use of the otherwise useless transaction version number, I still think it
is a bad proposal.
On Fri, May 12, 2017 at 3:22 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I've written a new BIP draft for OP_CHECKBLOCKVERSION to allow the
> community
> to put economic pressure on miners to deploy softforks without the extreme
> of
> a UASF.
>
> https://github.com/luke-jr/bips/blob/bip-cbv/bip-cbv.mediawiki
>
> Due to the potential for miners to maliciously block this softfork, it is
> suggested that we deploy it using BIP 8 to ensure it eventually activates
> even
> if encountering hostility.
>
> This is intended to be an alternative to BIP 8 in the long term.
> It is NOT intended to make BIP 148 obsolete, given the timeframes involved.
>
> An implementation is available (based on top of BIP 115's implementation):
>
> https://github.com/luke-jr/bitcoin/compare/cbah...luke-
> jr:checkblockversion
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a114db5fc0c65b2054f60314e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>I recall chatting about this idea rece=
ntly and my conclusion was the same as Peter Todd's conclusion: this wi=
ll just encourage miners to false signal readiness with undermines both BIP=
9 and BIP 8.<br><br></div>I felt that rather than using script system for =
this construction, it would be better to use the transaction version number=
instead by soft-forking in a rule that says when the most significant bits=
of a transaction version are 001 then the transaction can only be included=
in blocks whose lower 29 version bits are set at the same position as the =
lower 29 version bits set in the transaction version.<br><br></div>That is =
to say, if we have block version blkVersion and transaction version txVersi=
on, we soft fork in a rule that requires that<br><br></div>(txVersion &=
0xe0000000 !=3D 0x020000000) || ((blkVersion & 0xe0000000 =3D 0x020000=
000) && (blkVersion & txVersion =3D txVersion))<br><br></div>Wh=
ile I think that making use of the transaction version number is superior t=
o adding an opcode, because it doesn't interfere with caching of script=
validity and because it doesn't use any more transaction space by maki=
ng use of the otherwise useless transaction version number, I still think i=
t is a bad proposal.<br></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On Fri, May 12, 2017 at 3:22 PM, Luke Dashjr via bitcoin-dev <=
span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">I've written a new BIP draft fo=
r OP_CHECKBLOCKVERSION to allow the community<br>
to put economic pressure on miners to deploy softforks without the extreme =
of<br>
a UASF.<br>
<br>
=C2=A0 =C2=A0 <a href=3D"https://github.com/luke-jr/bips/blob/bip-cbv/bip-c=
bv.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/luke-=
jr/<wbr>bips/blob/bip-cbv/bip-cbv.<wbr>mediawiki</a><br>
<br>
Due to the potential for miners to maliciously block this softfork, it is<b=
r>
suggested that we deploy it using BIP 8 to ensure it eventually activates e=
ven<br>
if encountering hostility.<br>
<br>
This is intended to be an alternative to BIP 8 in the long term.<br>
It is NOT intended to make BIP 148 obsolete, given the timeframes involved.=
<br>
<br>
An implementation is available (based on top of BIP 115's implementatio=
n):<br>
<br>
=C2=A0 =C2=A0<a href=3D"https://github.com/luke-jr/bitcoin/compare/cbah...l=
uke-jr:checkblockversion" rel=3D"noreferrer" target=3D"_blank">https://gith=
ub.com/luke-jr/<wbr>bitcoin/compare/cbah...luke-<wbr>jr:checkblockversion</=
a><br>
<br>
Luke<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div><br></div>
--001a114db5fc0c65b2054f60314e--
|
