MIME-Version: 1.0
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"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees
Precedence: list

--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">&lt;<a h=
ref=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>&gt;</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&#39;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&#39;ve corrected the constants below):<br><br>(txVers=
ion &amp; 0xe0000000 !=3D 0x200000000) || (<u>(blkVersion &amp;=20
0xe0000000 =3D 0x200000000)</u> &amp;&amp; (blkVersion &amp; 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--