Gregory Maxwell via bitcoin-dev 於 2015-08-23 21:01 寫到:
Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the discussion has any thought been given to represent one block with more than one increment? This would leave additional space for future signaling, or allow, for example, higher resolution numbers for a sharechain commitement. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
I think this comment is more related to BIP68 instead of OP_CSV? Without further complicating the BIP68, I believe the best way to leave room for improvement is to spend a bit in tx nVersion to indicate the activation of BIP68. I have raised this issue before with http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html However, it seems Mark isn't in favor of my proposal
The idea is not to permanently change the meaning of nSequence. Actually, BIP68 is "only enforced if the most significant bit of the sequence number field is set." So BIP68 is optional, anyway. All I suggest is to move the flag from nSequence to nVersion. However, this will leave much bigger room for using nSequence for other purpose in the future.
AFAIK, nSequence is the only user definable and signed element in TxIn. There could be more interesting use of this field and we should not change its meaning permanently. (e.g. if nSequence had 8 bytes instead of 4 bytes, it could be used to indicate the value of the input to fix this problem: https://bitcointalk.org/index.php?topic=181734.0 )
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
