Mark Friedenbach [ARCHIVE] on Nostr: š Original date posted:2015-11-25 š Original message:Looks like I'm the long ...
š
Original date posted:2015-11-25
š Original message:Looks like I'm the long dissenting voice here? As the originator of the
name CHECKSEQUENCEVERIFY, perhaps I can explain why the name was
appropriately chosen and why the proposed alternatives don't stand up.
First, the names are purposefully chosen to illustrate what they do:
What does CHECKLOCKTIMEVERIFY do? It verifies the range of tx.nLockTime.
What does CHECKSEQUENCEVERIFY do? It verifies the range of txin.nSequence.
Second, the semantics are not limited to relative lock-time / maturity
only. They both leave open ranges with possible, but currently undefined
future consensus-enforced behavior. We don't know what sort of future
behavior these values might trigger, but the associated opcodes are generic
enough to handle them:
CHECKLOCKTIMEVERIFY will pass an nSequence between 1985 and 2009, even
though such constraints have no meaning in Bitcoin.
CHECKSEQUENCEVERIFY is explicitly written to permit a 5-byte push operand,
while checking only 17 of the available 39 bits of both the operand and the
nSequence. Indeed the most recent semantic change of CSV was justified in
part because it relaxes all constraints over the values of these bits
freeing them for other purposes in transaction validation and/or future
extensions of the opcode semantics.
Third, single-byte opcode space is limited. There are less than 10 such
opcodes left. Maybe space won't be so precious in a post-segwitness world,
but I don't want to presume that just yet.
As for the alternatives, they capture only the initial use case of
nSequence. My objection would relax if nSequence were renamed, but I think
that would be too disruptive and unnecessary. In any case, the imagined use
cases for CHECKSEQUENCEVERIFY has to do with sequencing execution pathways
of script, so it's not a stretch in meaning. Previously CHECKMATURITYVERIFY
was a hypothicated opcode that directly checked the minimum age of inputs
of a transaction. The indirect naming of CHECKSEQUENCEVERIFY on the other
hand is due to its indirect behavior. RELATIVELOCKTIMEVERIFY was also a
hypothicated opcode that would check a ficticious nRelativeLockTime field,
which does not exist. Again my objection would go away if we renamed
nSequence, but I actually think the nSequence name is better...
On Tue, Nov 24, 2015 at 2:30 AM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> BIP68 introduces relative lock-time semantics to part of the nSequence
> field leaving the majority of bits undefined for other future applications.
>
> BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifically
> limited to verifying transaction inputs according to BIP68's relative
> lock-time[1], yet the _name_ OP_CSV is much boarder than that. We spent
> months limiting the number of bits used in BIP68 so they would be available
> for future use cases, thus we have acknowledged there will be completely
> different usecases that take advantage of unused nSequence bits.
>
> For this reason I believe the BIP112 should be renamed specifically for
> it's usecase, which is verifying the time/maturity of transaction inputs
> relative to their inclusion in a block.
>
> Suggestions:-
>
> CHECKMATURITYVERIFY
> RELATIVELOCKTIMEVERIFY
> RCHECKLOCKTIMEVERIFY
> RCLTV
>
> We could of course softfork additional meaning into OP_CSV each time we
> add new sequence number usecases, but that would become obscure and
> confusing. We have already shown there is no shortage of opcodes so it
> makes no sense to cram everything into one generic opcode.
>
> TL;DR: let's give BIP112 opcode a name that reflects it's actual usecase
> rather than focusing on the bitcoin internals.
>
> [1]
> https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151125/25ab2f56/attachment-0001.html>;
š Original message:Looks like I'm the long dissenting voice here? As the originator of the
name CHECKSEQUENCEVERIFY, perhaps I can explain why the name was
appropriately chosen and why the proposed alternatives don't stand up.
First, the names are purposefully chosen to illustrate what they do:
What does CHECKLOCKTIMEVERIFY do? It verifies the range of tx.nLockTime.
What does CHECKSEQUENCEVERIFY do? It verifies the range of txin.nSequence.
Second, the semantics are not limited to relative lock-time / maturity
only. They both leave open ranges with possible, but currently undefined
future consensus-enforced behavior. We don't know what sort of future
behavior these values might trigger, but the associated opcodes are generic
enough to handle them:
CHECKLOCKTIMEVERIFY will pass an nSequence between 1985 and 2009, even
though such constraints have no meaning in Bitcoin.
CHECKSEQUENCEVERIFY is explicitly written to permit a 5-byte push operand,
while checking only 17 of the available 39 bits of both the operand and the
nSequence. Indeed the most recent semantic change of CSV was justified in
part because it relaxes all constraints over the values of these bits
freeing them for other purposes in transaction validation and/or future
extensions of the opcode semantics.
Third, single-byte opcode space is limited. There are less than 10 such
opcodes left. Maybe space won't be so precious in a post-segwitness world,
but I don't want to presume that just yet.
As for the alternatives, they capture only the initial use case of
nSequence. My objection would relax if nSequence were renamed, but I think
that would be too disruptive and unnecessary. In any case, the imagined use
cases for CHECKSEQUENCEVERIFY has to do with sequencing execution pathways
of script, so it's not a stretch in meaning. Previously CHECKMATURITYVERIFY
was a hypothicated opcode that directly checked the minimum age of inputs
of a transaction. The indirect naming of CHECKSEQUENCEVERIFY on the other
hand is due to its indirect behavior. RELATIVELOCKTIMEVERIFY was also a
hypothicated opcode that would check a ficticious nRelativeLockTime field,
which does not exist. Again my objection would go away if we renamed
nSequence, but I actually think the nSequence name is better...
On Tue, Nov 24, 2015 at 2:30 AM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> BIP68 introduces relative lock-time semantics to part of the nSequence
> field leaving the majority of bits undefined for other future applications.
>
> BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifically
> limited to verifying transaction inputs according to BIP68's relative
> lock-time[1], yet the _name_ OP_CSV is much boarder than that. We spent
> months limiting the number of bits used in BIP68 so they would be available
> for future use cases, thus we have acknowledged there will be completely
> different usecases that take advantage of unused nSequence bits.
>
> For this reason I believe the BIP112 should be renamed specifically for
> it's usecase, which is verifying the time/maturity of transaction inputs
> relative to their inclusion in a block.
>
> Suggestions:-
>
> CHECKMATURITYVERIFY
> RELATIVELOCKTIMEVERIFY
> RCHECKLOCKTIMEVERIFY
> RCLTV
>
> We could of course softfork additional meaning into OP_CSV each time we
> add new sequence number usecases, but that would become obscure and
> confusing. We have already shown there is no shortage of opcodes so it
> makes no sense to cram everything into one generic opcode.
>
> TL;DR: let's give BIP112 opcode a name that reflects it's actual usecase
> rather than focusing on the bitcoin internals.
>
> [1]
> https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151125/25ab2f56/attachment-0001.html>;