š
Original date posted:2015-08-27
š Original message:On Thu, Aug 27, 2015 at 11:08:32PM +0100, Btc Drak wrote:
> This BIP was assigned number 113.
>
> I have updated the text accordingly and added credits to Gregory Maxwell.
>
> Please see the changes in the pull request:
> https://github.com/bitcoin/bips/pull/182
On Thu, Aug 27, 2015 at 11:11:10PM +0100, Btc Drak via bitcoin-dev wrote:
> I have changed BIPS 112 and 113 to reflect this amended deployment
> strategy. I'm beginning to think the issues created by Bitcoin XT are
> so serious it probably deserves converting OPs text into an
> informational BIP.
I thought we had decided that the masking thing doesn't work as
intended?
To recap, XT nodes are producing blocks with nVersion=0b001...111
You're suggesting that we apply a mask of ~0b001...111 then trigger the
soft-fork on nVersion >= 0b0...100 == 4, with miners producing blocks with
nVersion=0b0...1000
That will work, but it still uses up a version bit. The reason why is
blocks with nVersion=0b001...000 - the intended deployment of the
nVersion bits proposal - will be rejected by the nVersion >= 4 rule,
hard-forking them off the network. In short, we have in fact "burnt" a
version bit unnecessarily.
If you're going to accept hard-forking some people off the network, why
not just go with my stateless nVersion bits w/ time-expiration proposal
instead? The only case where it leads to a hard-fork is if a soft-fork
has been rejected by the time the upgrade deadline is reached. It's easy
to set this multiple years into the future, so I think in practice it
won't be a major issue for non-controversial soft-forks.
Equally, spending the time to implement the original stateful nVersion
bits proposal is possible as well, though higher risk due to the extra
complexity of tracking soft-fork state.
--
'peter'[:-1]@petertodd.org
000000000000000008ba8215b2b644e33a98a762fd40710bc5e8c7f1b0e78375
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/c2490721/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 17:36:37
in reply to nevent1qā¦k5vm
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Seen on
wss://relay.noswhere.comPublished at
2023-06-07 17:36:37Event JSON
{
"id": "d57d5eb02597ccad2871107b4e594218bc376f493126260c41c72c5eff5e9662",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686159397,
"kind": 1,
"tags": [
[
"e",
"4dc7637f90cd472989d1d8af7bce6d5b9d510763360f0f4bae7d9639c7cb2548",
"",
"root"
],
[
"e",
"222596bbd7207160d02e9b19cb1788ce53a7d2153b0624526fb3419364877998",
"",
"reply"
],
[
"p",
"fdf31024ca0537ed828d895ddc8525f8af023f0dc935a8327a8a496d0d7a9f83"
]
],
"content": "š
Original date posted:2015-08-27\nš Original message:On Thu, Aug 27, 2015 at 11:08:32PM +0100, Btc Drak wrote:\n\u003e This BIP was assigned number 113.\n\u003e \n\u003e I have updated the text accordingly and added credits to Gregory Maxwell.\n\u003e \n\u003e Please see the changes in the pull request:\n\u003e https://github.com/bitcoin/bips/pull/182\n\nOn Thu, Aug 27, 2015 at 11:11:10PM +0100, Btc Drak via bitcoin-dev wrote:\n\u003e I have changed BIPS 112 and 113 to reflect this amended deployment\n\u003e strategy. I'm beginning to think the issues created by Bitcoin XT are\n\u003e so serious it probably deserves converting OPs text into an\n\u003e informational BIP.\n\nI thought we had decided that the masking thing doesn't work as\nintended?\n\nTo recap, XT nodes are producing blocks with nVersion=0b001...111\n\nYou're suggesting that we apply a mask of ~0b001...111 then trigger the\nsoft-fork on nVersion \u003e= 0b0...100 == 4, with miners producing blocks with\nnVersion=0b0...1000\n\nThat will work, but it still uses up a version bit. The reason why is\nblocks with nVersion=0b001...000 - the intended deployment of the\nnVersion bits proposal - will be rejected by the nVersion \u003e= 4 rule,\nhard-forking them off the network. In short, we have in fact \"burnt\" a\nversion bit unnecessarily.\n\nIf you're going to accept hard-forking some people off the network, why\nnot just go with my stateless nVersion bits w/ time-expiration proposal\ninstead? The only case where it leads to a hard-fork is if a soft-fork\nhas been rejected by the time the upgrade deadline is reached. It's easy\nto set this multiple years into the future, so I think in practice it\nwon't be a major issue for non-controversial soft-forks.\n\nEqually, spending the time to implement the original stateful nVersion\nbits proposal is possible as well, though higher risk due to the extra\ncomplexity of tracking soft-fork state.\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000008ba8215b2b644e33a98a762fd40710bc5e8c7f1b0e78375\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/c2490721/attachment.sig\u003e",
"sig": "454acc51905293284fd59bb24c93efdbfae0668ed41258e95e9e444b1bc2f020ca911e4e8888468c859a61cf6621c04f34851ca410ad7aa07f340b6cf1f071ee"
}