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
|
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 E2FA7720
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 May 2017 17:11:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com
[209.85.213.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8F3A9B0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 May 2017 17:11:48 +0000 (UTC)
Received: by mail-vk0-f52.google.com with SMTP id x71so31174424vkd.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 May 2017 10:11:48 -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=vEGCnCXstDW9Wh6RS2hFfYS4gBoItGKOSIEQ0pM3dTo=;
b=w6vmzLBg9F993amQ7+f6kcROgYHdqrEF8J0ak0bw4tH4nGXsJ3TE50Fh4p6t8n0VXF
m+yRcNFyxlsjCsTPmzFPlR3232iiRTKRPh2+ckJHbhxiIzs1W00S3Nn1c0aUuQD/stBs
hPQywi2jCYqvbUX3dLc7sqz6XBoSurO1Y4EDfJDKmoZnR2KGk/33Cot9yKXIH+Z0KpKR
uAWOcah6FQmf3bJKO5pT1Y0pxQsb8MOGp0zDRWtswaHnPaHd+DZLtKqwJL0xty5YT+A8
gSGgRAdAimiwVTiabZBBII5K5Uk/4QW646wfNS4rxdNSBWwxs3YebiAQ0IJHF1MBCAzX
+0pg==
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=vEGCnCXstDW9Wh6RS2hFfYS4gBoItGKOSIEQ0pM3dTo=;
b=cyzUXFFDir9myPPAiJX4d4aVizaGYh6ZobjjJb91XZ8RH4J5IMzXrbSAUmcotf0znq
QdQPygPjyDUJZVfkURutL4TolIMj7pI6OU0S0XYGBchqmtH7ng0sUen2jy9C4QFGXd/x
EMIIP6kwCiISNTt4iaOWWawT9tuuIkzrV0CYKSm3KQdW3v7Srxq/J4l40JMOvRzjkkNf
RR5o+cq5ov3pqX1Zpgwh0CCKnG/gxi0cLWf9wO38Mb7Ko2kK6sZR1BnGc+j9htKpATG3
zYRI1tXpc07O8mA42ZcwH+KrgPrb16nwXi2lR7g2ljz7PFy0tdWudUukEEZ+wTs3Fl8o
+9HQ==
X-Gm-Message-State: AODbwcANIVvkViFnkX2SL65rR2ic2XOaSb2OyB2eR/oOpU6Lvg7MC3oa
mmUqx8gMuETqjRY1a/8m64T6K3Lbesu7H+9MBg==
X-Received: by 10.31.102.131 with SMTP id a125mr4700923vkc.6.1494695507722;
Sat, 13 May 2017 10:11:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.81.48 with HTTP; Sat, 13 May 2017 10:11:27 -0700 (PDT)
In-Reply-To: <201705130526.59467.luke@dashjr.org>
References: <201705121922.57445.luke@dashjr.org>
<CAMZUoKnzV9faJ+mBTTzTre05Ejwnx3tC4ozbiPoPUfS+7GLMTQ@mail.gmail.com>
<201705130526.59467.luke@dashjr.org>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sat, 13 May 2017 13:11:27 -0400
Message-ID: <CAMZUoKnjc4ezVm4FeMFA-+=g13E5ZwZCAoAjd_yL89v7qf1gEA@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary="001a114df358c91910054f6aea37"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, 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 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 17:11:50 -0000
--001a114df358c91910054f6aea37
Content-Type: text/plain; charset="UTF-8"
On Sat, May 13, 2017 at 1:26 AM, Luke Dashjr <luke@dashjr.org> wrote:
> Versionbits change/lose their meaning after the deployment timeout. For
> this
> reason, the timeout must be specified so the check is skipped when that
> occurs.
>
To add a timeout a user can optionally bundle a pair of similar
transactions. One with the transaction version bits set and a second with
a locktime set. The effect is the same.
Also, doing it the way you describe would fail to enforce that BIP9 is
> actually in use for the block version; you could simply add that as an
> additional condition, but it seems pretty hacky since you wouldn't be able
> to
> upgrade versionbits anymore...
>
My formal condition does include a check for the block version (I've
corrected the constants below):
(txVersion & 0xe0000000 != 0x200000000) || (*(blkVersion & 0xe0000000 =
0x200000000)* && (blkVersion & txVersion = txVersion))
Nothing here prevents upgrading versionbits AFAICT. Any txVersion that
does not begin with 0b001 is unconditionally acceptable and available for
further soft-forking.
--001a114df358c91910054f6aea37
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, May 13, 2017 at 1:26 AM, Luke Dashjr <span dir=3D"ltr"><<a h=
ref=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>></s=
pan> wrote:<span class=3D"gmail-"></span><br><span class=3D"gmail-"></span>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">
</span>Versionbits change/lose their meaning after the deployment timeout. =
For this<br>
reason, the timeout must be specified so the check is skipped when that<br>
occurs.<br></blockquote><div><br></div><div>To add a timeout a user can opt=
ionally bundle a pair of similar transactions.=C2=A0 One with the transacti=
on version bits set and a second with a locktime set.=C2=A0 The effect is t=
he same.<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">
Also, doing it the way you describe would fail to enforce that BIP9 is<br>
actually in use for the block version; you could simply add that as an<br>
additional condition, but it seems pretty hacky since you wouldn't be a=
ble to<br>
upgrade versionbits anymore...<span class=3D"gmail-"><br></span></blockquot=
e><div><br><div><br></div><div>My formal condition does include a check for=
the block version (I've corrected the constants below):<br><br>(txVers=
ion & 0xe0000000 !=3D 0x200000000) || (<u>(blkVersion &=20
0xe0000000 =3D 0x200000000)</u> && (blkVersion & txVersion =3D=
=20
txVersion))<br><br></div>Nothing here prevents upgrading versionbits AFAICT=
.=C2=A0 Any txVersion that does not begin with 0b001 is unconditionally acc=
eptable and available for further soft-forking.<br><br></div></div></div></=
div>
--001a114df358c91910054f6aea37--
|
