jl2012 at xbt.hk [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-24 📝 Original message:Your proposal also ...

📅 Original date posted:2015-08-24
📝 Original message: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.