Mark Friedenbach [ARCHIVE] on Nostr: š Original date posted:2015-06-02 š Original message:You are correct! I am ...
š
Original date posted:2015-06-02
š Original message:You are correct! I am maintaining a 'checksequenceverify' branch in my git
repository as well, an OP_RCLTV using sequence numbers:
https://github.com/maaku/bitcoin/tree/checksequenceverify
Most of the interesting use cases for relative lock-time require an RCLTV
opcode. What is interesting about this architecture is that it possible to
cleanly separate the relative lock-time (sequence numbers) from the RCLTV
opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like
CLTV, the CSV opcode only checks transaction data and requires no
contextual knowledge about block headers, a weakness of the other RCLTV
proposals that violate the clean separation between libscript and
libconsensus. In a similar way, this BIP proposal only touches the
transaction validation logic without any impact to script.
I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY
opcode and its enabling applications. But, well, one thing at a time.
On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <stephencalebmorse at gmail.com>
wrote:
> Hi Mark,
>
> Overall, I like this idea in every way except for one: unless I am missing
> something, we may still need an OP_RCLTV even with this being
> implemented.
>
> In use cases such as micropayment channels where the funds are locked up
> by multiple parties, the enforcement of the relative locktime can be done
> by the first-signing party. So, while your solution would probably work in
> cases like this, where multiple signing parties are involved, there may be
> other, seen or unforeseen, use cases that require putting the relative
> locktime right into the spending contract (the scriptPubKey itself). When
> there is only one signer, there's nothing that enforces using an nSequence
> and nVersion=2 that would prevent spending the output until a certain time.
>
> I hope this is received as constructive criticism, I do think this is an
> innovative idea. In my view, though, it seems to be less fully-featured
> than just repurposing an OP_NOP to create OP_RCLTV. The benefits are
> obviously that it saves transaction space by repurposing unused space, and
> would likely work for most cases where an OP_RCLTV would be needed.
>
> Best,
> Stephen
>
> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach <mark at friedenbach.org>
> wrote:
>
>> I have written a reference implementation and BIP draft for a soft-fork
>> change to the consensus-enforced behaviour of sequence numbers for the
>> purpose of supporting transaction replacement via per-input relative
>> lock-times. This proposal was previously discussed on the mailing list in
>> the following thread:
>>
>> http://sourceforge.net/p/bitcoin/mailman/message/34146752/
>>
>> In short summary, this proposal seeks to enable safe transaction
>> replacement by re-purposing the nSequence field of a transaction input to
>> be a consensus-enforced relative lock-time.
>>
>> The advantages of this approach is that it makes use of the full range of
>> the 32-bit sequence number which until now has rarely been used for
>> anything other than a boolean control over absolute nLockTime, and it does
>> so in a way that is semantically compatible with the originally envisioned
>> use of sequence numbers for fast mempool transaction replacement.
>>
>> The disadvantages are that external constraints often prevent the full
>> range of sequence numbers from being used when interpreted as a relative
>> lock-time, and re-purposing nSequence as a relative lock-time precludes its
>> use in other contexts. The latter point has been partially addressed by
>> having the relative lock-time semantics be enforced only if the
>> most-significant bit of nSequence is set. This preserves 31 bits for
>> alternative use when relative lock-times are not required.
>>
>> The BIP draft can be found at the following gist:
>>
>> https://gist.github.com/maaku/be15629fe64618b14f5a
>>
>> The reference implementation is available at the following git repository:
>>
>> https://github.com/maaku/bitcoin/tree/sequencenumbers
>>
>> I request that the BIP editor please assign a BIP number for this work.
>>
>> Sincerely,
>> Mark Friedenbach
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/b2e1f6dc/attachment.html>;
š Original message:You are correct! I am maintaining a 'checksequenceverify' branch in my git
repository as well, an OP_RCLTV using sequence numbers:
https://github.com/maaku/bitcoin/tree/checksequenceverify
Most of the interesting use cases for relative lock-time require an RCLTV
opcode. What is interesting about this architecture is that it possible to
cleanly separate the relative lock-time (sequence numbers) from the RCLTV
opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like
CLTV, the CSV opcode only checks transaction data and requires no
contextual knowledge about block headers, a weakness of the other RCLTV
proposals that violate the clean separation between libscript and
libconsensus. In a similar way, this BIP proposal only touches the
transaction validation logic without any impact to script.
I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY
opcode and its enabling applications. But, well, one thing at a time.
On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <stephencalebmorse at gmail.com>
wrote:
> Hi Mark,
>
> Overall, I like this idea in every way except for one: unless I am missing
> something, we may still need an OP_RCLTV even with this being
> implemented.
>
> In use cases such as micropayment channels where the funds are locked up
> by multiple parties, the enforcement of the relative locktime can be done
> by the first-signing party. So, while your solution would probably work in
> cases like this, where multiple signing parties are involved, there may be
> other, seen or unforeseen, use cases that require putting the relative
> locktime right into the spending contract (the scriptPubKey itself). When
> there is only one signer, there's nothing that enforces using an nSequence
> and nVersion=2 that would prevent spending the output until a certain time.
>
> I hope this is received as constructive criticism, I do think this is an
> innovative idea. In my view, though, it seems to be less fully-featured
> than just repurposing an OP_NOP to create OP_RCLTV. The benefits are
> obviously that it saves transaction space by repurposing unused space, and
> would likely work for most cases where an OP_RCLTV would be needed.
>
> Best,
> Stephen
>
> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach <mark at friedenbach.org>
> wrote:
>
>> I have written a reference implementation and BIP draft for a soft-fork
>> change to the consensus-enforced behaviour of sequence numbers for the
>> purpose of supporting transaction replacement via per-input relative
>> lock-times. This proposal was previously discussed on the mailing list in
>> the following thread:
>>
>> http://sourceforge.net/p/bitcoin/mailman/message/34146752/
>>
>> In short summary, this proposal seeks to enable safe transaction
>> replacement by re-purposing the nSequence field of a transaction input to
>> be a consensus-enforced relative lock-time.
>>
>> The advantages of this approach is that it makes use of the full range of
>> the 32-bit sequence number which until now has rarely been used for
>> anything other than a boolean control over absolute nLockTime, and it does
>> so in a way that is semantically compatible with the originally envisioned
>> use of sequence numbers for fast mempool transaction replacement.
>>
>> The disadvantages are that external constraints often prevent the full
>> range of sequence numbers from being used when interpreted as a relative
>> lock-time, and re-purposing nSequence as a relative lock-time precludes its
>> use in other contexts. The latter point has been partially addressed by
>> having the relative lock-time semantics be enforced only if the
>> most-significant bit of nSequence is set. This preserves 31 bits for
>> alternative use when relative lock-times are not required.
>>
>> The BIP draft can be found at the following gist:
>>
>> https://gist.github.com/maaku/be15629fe64618b14f5a
>>
>> The reference implementation is available at the following git repository:
>>
>> https://github.com/maaku/bitcoin/tree/sequencenumbers
>>
>> I request that the BIP editor please assign a BIP number for this work.
>>
>> Sincerely,
>> Mark Friedenbach
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/b2e1f6dc/attachment.html>;