Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[jl2012@xbt.hk]

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.