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)
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
