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

--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&#39;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 &amp;=
 0xe0000000 !=3D 0x020000000) || ((blkVersion &amp; 0xe0000000 =3D 0x020000=
000) &amp;&amp; (blkVersion &amp; 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&#39;t interfere with caching of script=
 validity and because it doesn&#39;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">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</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&#39;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&#39;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--