Your proposal also permanently burns a sequence bit. It depends on how
we value a nSequence bit and a nVersion bit. I think there is a
trade-off here:
1. nSequence is signed by each TxIn individually, while all TxIns must
share the same nVersion
2. If nVersion is used to indicate the meaning of nSequence (as I
suggested):
Pros:
It saves a nSequence bit and allows more space for redefining the
nSequence
Cons:
It burns a nVersion bit.
All TxIns in a tx must share the same meaning for their nSequence
3. If nSequence is used to indicate the meaning of itself (as you
suggested):
Pros:
It saves a nVersion bit
Different TxIn may have different meaning with their nSequence
Cons:
It burns a nSequence bit, thus less space for extension
I don't think there is a perfect choice. However, I still prefer my
proposal because:
1. nSequence is signed by each TxIn individually and could be more
interesting than nVersion.
2. If nVersion is expected to be a monotonic number, 2 bytes = 65536
versions is enough for 65 millenniums if it ticks once per year. 4 bytes
is an overkill. Why don't we spend a bit if there is a good reason? Most
softforks (e.g. OP_CLTV, OP_CSV, BIP66) are not optional. These kind of
optional new functions would not be common and should never use up the
version bits. (or, could you suggest a better use of the tx version
bits?)
Mark Friedenbach 於 2015-08-23 22:54 寫到:
Sorry this was meant for the list:
There are only 32 bits in the version field. If you're going to spend
a bit for perpetuity to indicate whether or not a feature is active,
you'd better have a good reason to make that feature optional.
I haven't seen a compelling use case for having BIP 68 be optional in
that way. As you note, BIP 68 semantics is already optional by
toggling the most significant bit, and that doesn't permanently burn a
version bit.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
