📅 Original date posted:2017-05-13
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170513/5ceec501/attachment-0001.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 18:01:09
in reply to nevent1q…jryp
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 18:01:09Event JSON
{
"id": "139e38315ba3ae64ebc9095f2fdb8d160cf18c0f2173777266e555ceac166585",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686160869,
"kind": 1,
"tags": [
[
"e",
"7d5264e6a38e4e9253a036abe54c433e808627678a11c5775ed232185ab4e5f9",
"",
"root"
],
[
"e",
"2c11f798ce33ff526a890b382f12af826231781e68ecd2d13c1d12fd43724119",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2017-05-13\n📝 Original message:I recall chatting about this idea recently and my conclusion was the same\nas Peter Todd's conclusion: this will just encourage miners to false signal\nreadiness with undermines both BIP 9 and BIP 8.\n\nI felt that rather than using script system for this construction, it would\nbe better to use the transaction version number instead by soft-forking in\na rule that says when the most significant bits of a transaction version\nare 001 then the transaction can only be included in blocks whose lower 29\nversion bits are set at the same position as the lower 29 version bits set\nin the transaction version.\n\nThat is to say, if we have block version blkVersion and transaction version\ntxVersion, we soft fork in a rule that requires that\n\n(txVersion \u0026 0xe0000000 != 0x020000000) || ((blkVersion \u0026 0xe0000000 =\n0x020000000) \u0026\u0026 (blkVersion \u0026 txVersion = txVersion))\n\nWhile I think that making use of the transaction version number is superior\nto adding an opcode, because it doesn't interfere with caching of script\nvalidity and because it doesn't use any more transaction space by making\nuse of the otherwise useless transaction version number, I still think it\nis a bad proposal.\n\nOn Fri, May 12, 2017 at 3:22 PM, Luke Dashjr via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I've written a new BIP draft for OP_CHECKBLOCKVERSION to allow the\n\u003e community\n\u003e to put economic pressure on miners to deploy softforks without the extreme\n\u003e of\n\u003e a UASF.\n\u003e\n\u003e https://github.com/luke-jr/bips/blob/bip-cbv/bip-cbv.mediawiki\n\u003e\n\u003e Due to the potential for miners to maliciously block this softfork, it is\n\u003e suggested that we deploy it using BIP 8 to ensure it eventually activates\n\u003e even\n\u003e if encountering hostility.\n\u003e\n\u003e This is intended to be an alternative to BIP 8 in the long term.\n\u003e It is NOT intended to make BIP 148 obsolete, given the timeframes involved.\n\u003e\n\u003e An implementation is available (based on top of BIP 115's implementation):\n\u003e\n\u003e https://github.com/luke-jr/bitcoin/compare/cbah...luke-\n\u003e jr:checkblockversion\n\u003e\n\u003e Luke\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170513/5ceec501/attachment-0001.html\u003e",
"sig": "c1063a4679e5739656330f0b425730b4ae01df69240965240bcc6622b7da34b9ba296696b48fbc21aeaf5d843a82bc879406528f409764a6788a7af5534cc0c7"
}