📅 Original date posted:2015-08-08
📝 Original message:BIP68 rules and some of the BIP62 rules are applied only if the tx
version is >=2 and >=3 respectively. Therefore, it is not possible to
create a tx which follows BIP62 but not BIP68. If we introduce v4 tx
later, BIP62 and BIP68 will all become mandatory.
Some rules, e.g. "scriptPubKey evaluation will be required to result in
a single non-zero value" in BIP62, will cause trouble when we try to
introduce a new script system with softfork.
I suggest to divide the tx version field into 2 parts: the higher 4 bits
and lower 28 bits.
BIP62 is active for a tx if its highest bits are 0000, and the second
lowest bit is 1.
BIP68 is active for a tx if its highest bits are 0000, and the third
lowest bit is 1.
So it will be easier for us to re-purpose the nSequence, or to take
advantage of malleability in the future. If this is adopted, the
nSequence high bit requirement in BIP68 becomes unnecessary as we could
easily switch it off.
The low bits will allow 28 independent BIPs and should be ample for many
years. When they are exhausted, we can switch the high bits to a
different number (1-15) and redefine the meaning of low bits. By that
time, some of the 28 BIPs might have become obsoleted or could be
merged.
(I'm not sure if there are other draft BIPs with similar interpretation
of tx version but the comments above should also apply to them)
jl2012 at xbt.hk [ARCHIVE] /
npub1kc…wjfw4
2023-06-07 17:34:27
in reply to nevent1q…tyhe
Author Public Key
npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4Published at
2023-06-07 17:34:27Event JSON
{
"id": "643dc482186a582bfb5f169e32583be02b7ebd2517a52f37689429dd44f988c5",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686159267,
"kind": 1,
"tags": [
[
"e",
"545f9cb275bd0523e28f0e46aa7989560271fccbb188b55ff808a8b26afb5784",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-08-08\n📝 Original message:BIP68 rules and some of the BIP62 rules are applied only if the tx \nversion is \u003e=2 and \u003e=3 respectively. Therefore, it is not possible to \ncreate a tx which follows BIP62 but not BIP68. If we introduce v4 tx \nlater, BIP62 and BIP68 will all become mandatory.\n\nSome rules, e.g. \"scriptPubKey evaluation will be required to result in \na single non-zero value\" in BIP62, will cause trouble when we try to \nintroduce a new script system with softfork.\n\nI suggest to divide the tx version field into 2 parts: the higher 4 bits \nand lower 28 bits.\n\nBIP62 is active for a tx if its highest bits are 0000, and the second \nlowest bit is 1.\n\nBIP68 is active for a tx if its highest bits are 0000, and the third \nlowest bit is 1.\n\nSo it will be easier for us to re-purpose the nSequence, or to take \nadvantage of malleability in the future. If this is adopted, the \nnSequence high bit requirement in BIP68 becomes unnecessary as we could \neasily switch it off.\n\nThe low bits will allow 28 independent BIPs and should be ample for many \nyears. When they are exhausted, we can switch the high bits to a \ndifferent number (1-15) and redefine the meaning of low bits. By that \ntime, some of the 28 BIPs might have become obsoleted or could be \nmerged.\n\n(I'm not sure if there are other draft BIPs with similar interpretation \nof tx version but the comments above should also apply to them)",
"sig": "9814fb291ee346ef836d32f0677b560aca829c63115880d0244e21cc0e928d276a8088ddbb7911a25a7ee9697904534083a642366677795d839e7a45fe2be794"
}