📅 Original date posted:2015-08-19 📝 Original message:A lot of this detail and ...

Jeff Garzik [ARCHIVE] /

npub1kf0…3f58

2023-06-07 17:37:01

in reply to nevent1q…v3xg

📅 Original date posted:2015-08-19
📝 Original message:A lot of this detail and worry is eliminated by simply asking BIP 102
maintainers to change to a different bit that works best for everyone.
Existing nVersion garbage will get buried in sufficient time window to
prevent anything from triggering.

Just settle on a specific standard, reserve bits for feature upgrade forks,
and move on. There is already a rough standard proposed in sipa's gist.

On Wed, Aug 19, 2015 at 9:22 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> 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.
>
> _______________________________________________
> 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/20150819/d86e0c0c/attachment-0001.html>;

Author Public Key

npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58

Seen on

wss://relay.nostr.band

Show more details

Published at

2023-06-07 17:37:01

Kind type

1 Short Text Note

Event JSON

{ "id": "82288159a2b2b5d4f12ccc5dce8b7e50e17f94ab5fa6c4146e5c2436bfebcff5", "pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11", "created_at": 1686159421, "kind": 1, "tags": [ [ "e", "7b6db0ce13f47e3b2db7907716169da0107cc63b6d57e20477da59a8b07dbb21", "", "root" ], [ "e", "147519a5f4d050707d20ae0c31c256e8354e3e8db71bb365370d3828fa04c9cd", "", "reply" ], [ "p", "46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e" ] ], "content": "📅 Original date posted:2015-08-19\n📝 Original message:A lot of this detail and worry is eliminated by simply asking BIP 102\nmaintainers to change to a different bit that works best for everyone.\nExisting nVersion garbage will get buried in sufficient time window to\nprevent anything from triggering.\n\nJust settle on a specific standard, reserve bits for feature upgrade forks,\nand move on. There is already a rough standard proposed in sipa's gist.\n\n\n\n\n\nOn Wed, Aug 19, 2015 at 9:22 AM, Tier Nolan via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Wed, Aug 19, 2015 at 7:10 AM, Mark Friedenbach via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e We can use nVersion \u0026 0x8 to signal support, while keeping the consensus\n\u003e\u003e rule as nVersion \u003e= 4, right? That way we don't waste a bit after this all\n\u003e\u003e clears up.\n\u003e\u003e\n\u003e What happens if XT gets 40% and this BIP gets 55%? That gives 95% that\n\u003e accept the upgrade. Version 3 and lower blocks need to be rejected after\n\u003e that.\n\u003e\n\u003e By advertising 0x7 for the last 3 bits, XT is effectively claiming to\n\u003e support the check locktime verify BIPs but they don't have the code.\n\u003e\n\u003e This sequence could be used, without a specific version-bits proposal.\n\u003e\n\u003e Until height = N + 5000, if 950 of the last 1000 blocks have the 0x8 bit\n\u003e set, then reject blocks with version numbers less than 8.\n\u003e\n\u003e At height N, if the above rule is active, then the BIP is permanent.\n\u003e\n\u003e It applies to any block with bit 0x8 set, once the 75% threshold is met.\n\u003e\n\u003e From height N + 5000 to N + 10000, reject blocks which have bit 0x8 set.\n\u003e\n\u003e N could be set 1 year from now, or so.\n\u003e\n\u003e\n\u003e This gives a period of time after lock that bit 8 is kept and then a\n\u003e period where is is guaranteed to be zero.\n\u003e\n\u003e This gives software that is only watching the bit time to be upgraded and\n\u003e similarly time where the bit is set to zero before it can be reused.\n\u003e\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/d86e0c0c/attachment-0001.html\u003e", "sig": "312695d0bde975f79f63a48cc5212b71a022546e7b6ab2c8b71e62cbdb151de7a652a2a6d6a51d9955adccfcc576c996f99d50f69e6c08916918b48edabb3c54" }