📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 7:10 AM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> We can use nVersion & 0x8 to signal support, while keeping the consensus
> rule as nVersion >= 4, right? That way we don't waste a bit after this all
> clears up.
>
What happens if XT gets 40% and this BIP gets 55%? That gives 95% that
accept the upgrade. Version 3 and lower blocks need to be rejected after
that.
By advertising 0x7 for the last 3 bits, XT is effectively claiming to
support the check locktime verify BIPs but they don't have the code.
This sequence could be used, without a specific version-bits proposal.
Until height = N + 5000, if 950 of the last 1000 blocks have the 0x8 bit
set, then reject blocks with version numbers less than 8.
At height N, if the above rule is active, then the BIP is permanent.
It applies to any block with bit 0x8 set, once the 75% threshold is met.
>From height N + 5000 to N + 10000, reject blocks which have bit 0x8 set.
N could be set 1 year from now, or so.
This gives a period of time after lock that bit 8 is kept and then a period
where is is guaranteed to be zero.
This gives software that is only watching the bit time to be upgraded and
similarly time where the bit is set to zero before it can be reused.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/92a565c7/attachment.html>;
Tier Nolan [ARCHIVE] /
npub1g6…sl5wd
2023-06-07 15:48:31
in reply to nevent1q…pqd7
Author Public Key
npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:48:31Event JSON
{
"id": "b645b1aeae4d0e87f73bcbf1a4317bd7d96bd293a39710d976033f4c4fbc24a9",
"pubkey": "46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e",
"created_at": 1686152911,
"kind": 1,
"tags": [
[
"e",
"33b40cb3a6ef196ed3b584cc0c215cff95814683d4b226bd9e9b25b98d4c9443",
"",
"root"
],
[
"e",
"6fc3cead1532b0c0f0c61426682102d1b9048a370063da45eda58331751367fa",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2015-08-19\n📝 Original message:On Wed, Aug 19, 2015 at 7:10 AM, Mark Friedenbach via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e We can use nVersion \u0026 0x8 to signal support, while keeping the consensus\n\u003e rule as nVersion \u003e= 4, right? That way we don't waste a bit after this all\n\u003e clears up.\n\u003e\nWhat happens if XT gets 40% and this BIP gets 55%? That gives 95% that\naccept the upgrade. Version 3 and lower blocks need to be rejected after\nthat.\n\nBy advertising 0x7 for the last 3 bits, XT is effectively claiming to\nsupport the check locktime verify BIPs but they don't have the code.\n\nThis sequence could be used, without a specific version-bits proposal.\n\nUntil height = N + 5000, if 950 of the last 1000 blocks have the 0x8 bit\nset, then reject blocks with version numbers less than 8.\n\nAt height N, if the above rule is active, then the BIP is permanent.\n\nIt applies to any block with bit 0x8 set, once the 75% threshold is met.\n\n\u003eFrom height N + 5000 to N + 10000, reject blocks which have bit 0x8 set.\n\nN could be set 1 year from now, or so.\n\n\nThis gives a period of time after lock that bit 8 is kept and then a period\nwhere is is guaranteed to be zero.\n\nThis gives software that is only watching the bit time to be upgraded and\nsimilarly time where the bit is set to zero before it can be reused.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/92a565c7/attachment.html\u003e",
"sig": "c60b4e525b6fd3821dfc15c3ef2c98d9b49691a60cc621ebc407ac1a2e0c2220831e6af47ce57bab2e013657cdd753bfa294b8b23c436cd6e0b88980f29e859e"
}