[Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2137 bytes --]

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Stephen Morse]

[-- Attachment #1: Type: text/plain, Size: 3293 bytes --]

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@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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 4444 bytes --]

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 4442 bytes --]

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@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@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@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 6003 bytes --]

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Stephen Morse]

[-- Attachment #1: Type: text/plain, Size: 5098 bytes --]

I see, so OP_SEQUENCEVERIFY will have a value pushed on the stack right
before, and then check that the input spending the prevout has nSequence
corresponds to at least the sequence specified by the stack value. Good
idea! Keeps the script code from depending on external chain specific data,
which is nice.

Hopefully we can repurpose one of the OP_NOPs for CHECKLOCKTIMEVERIFY and
one for OP_CHECKSEQUENCEVERIFY. Very complementary.

Best,
Stephen


On Tue, Jun 2, 2015 at 12:16 AM, Mark Friedenbach <mark@friedenbach.org>
wrote:

> 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@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@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@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 6942 bytes --]

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 6485 bytes --]

I am glad to see the transaction version number increase.  The commit
doesn't update the default transaction version though.  The node would
still produce version 1 transactions.

Does the reference client already produce transactions with final sequence
numbers?  If so, then they will be valid version 2 transactions.  If it
sets the sequence to all zeros, then it won't trigger the new code either.
I think simply bumping the default version number to 2 would be safe.

For the timestamp locktime, median block time would be better than raw
block time.  Median time is the median timestamp of the previous 11
blocks.  This reduces the incentive to mess with the timestamp.  Median
time is earlier than block time, but since things are relative, it should
balance out.

Miners have around 2 hours worth of flexibility when setting the
timestamps, so it may not be that big a deal.



On Tue, Jun 2, 2015 at 5:34 AM, Stephen Morse <stephencalebmorse@gmail.com>
wrote:

> I see, so OP_SEQUENCEVERIFY will have a value pushed on the stack right
> before, and then check that the input spending the prevout has nSequence
> corresponds to at least the sequence specified by the stack value. Good
> idea! Keeps the script code from depending on external chain specific data,
> which is nice.
>
> Hopefully we can repurpose one of the OP_NOPs for CHECKLOCKTIMEVERIFY and
> one for OP_CHECKSEQUENCEVERIFY. Very complementary.
>
> Best,
> Stephen
>
>
> On Tue, Jun 2, 2015 at 12:16 AM, Mark Friedenbach <mark@friedenbach.org>
> wrote:
>
>> 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@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@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@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 8820 bytes --]

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Stephen]

[-- Attachment #1: Type: text/plain, Size: 5246 bytes --]

Do you think it would be useful to have an inverted version of both CSV and CLTV? To verify if an output is spent before a specific time. CLTV and CSV could be implemented by taking two stack arguments, an integer for the comparison and TRUE/FALSE. 

Now that I think about this more, the problem is that, for example, just having a lock time of less than some value doesn't actually mean it has to be spent before that script value, so this might not work. Likely any implementations of such a feature would have to provide the script execution environment with access to information that it doesn't have now, which is what we are trying to avoid. 

Best,
Stephen



> On Jun 2, 2015, at 12:16 AM, Mark Friedenbach <mark@friedenbach.org> wrote:
> 
> 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@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@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@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

[-- Attachment #2: Type: text/html, Size: 7065 bytes --]

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Adam Back]

That would also introduce the anomaly of a script that was once valid
becoming later invalid, when nothing varies other than time.  That is
not super compatible with the current model of reprocessing
transactions in later blocks if the block they were first in gets
reorged.

(Not a huge flexibility loss as you can implement "not after" by
making it the previous holders responsibility to spend a "not before"
back to themselves.)

Adam

On 2 June 2015 at 13:52, Stephen <stephencalebmorse@gmail.com> wrote:
> Do you think it would be useful to have an inverted version of both CSV and
> CLTV? To verify if an output is spent before a specific time. CLTV and CSV
> could be implemented by taking two stack arguments, an integer for the
> comparison and TRUE/FALSE.
>
> Now that I think about this more, the problem is that, for example, just
> having a lock time of less than some value doesn't actually mean it has to
> be spent before that script value, so this might not work. Likely any
> implementations of such a feature would have to provide the script execution
> environment with access to information that it doesn't have now, which is
> what we are trying to avoid.
>
> Best,
> Stephen
>
>
>
> On Jun 2, 2015, at 12:16 AM, Mark Friedenbach <mark@friedenbach.org> wrote:
>
> 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@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@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@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Stephen Morse]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

>
> That would also introduce the anomaly of a script that was once valid
> becoming later invalid, when nothing varies other than time.  That is
> not super compatible with the current model of reprocessing
> transactions in later blocks if the block they were first in gets
> reorged.
>

Very good point.


>
> (Not a huge flexibility loss as you can implement "not after" by
> making it the previous holders responsibility to spend a "not before"
> back to themselves.)
>

Do you mean something like the below?

scriptPubKey:
  IF
    {A's pub} CHECKSIGVERIFY
  ELSE
    {curr_height + 100} CLTV {B's pub} CHECKSIGVERIFY

This ensures that Alice has to spend the output in the next 100 blocks or
risk it being taken from her (she just has to put an OP_TRUE on the end of
her scriptSig). So, it seems we can forget about an inverted CLTV/CSV,
great!

Best,
Stephen

[-- Attachment #2: Type: text/html, Size: 1839 bytes --]

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 7033 bytes --]

Oh it is far worse than that. There is nothing preventing those coins from
being spent somewhere else, so actually an expiry would enable coin theft
in a reorg -- you make your spends expire right after they hit the chain
the first time, and then if there is a reorg the spend and subsequent
transactions are invalidated. This is an exploitable means of theft.

For this reason it is very important to male sure that once a transaction
makes it on the chain, it cannot be invalidated by means of a reorg.
On Jun 2, 2015 6:11 AM, "Adam Back" <adam@cypherspace.org> wrote:

> That would also introduce the anomaly of a script that was once valid
> becoming later invalid, when nothing varies other than time.  That is
> not super compatible with the current model of reprocessing
> transactions in later blocks if the block they were first in gets
> reorged.
>
> (Not a huge flexibility loss as you can implement "not after" by
> making it the previous holders responsibility to spend a "not before"
> back to themselves.)
>
> Adam
>
> On 2 June 2015 at 13:52, Stephen <stephencalebmorse@gmail.com> wrote:
> > Do you think it would be useful to have an inverted version of both CSV
> and
> > CLTV? To verify if an output is spent before a specific time. CLTV and
> CSV
> > could be implemented by taking two stack arguments, an integer for the
> > comparison and TRUE/FALSE.
> >
> > Now that I think about this more, the problem is that, for example, just
> > having a lock time of less than some value doesn't actually mean it has
> to
> > be spent before that script value, so this might not work. Likely any
> > implementations of such a feature would have to provide the script
> execution
> > environment with access to information that it doesn't have now, which is
> > what we are trying to avoid.
> >
> > Best,
> > Stephen
> >
> >
> >
> > On Jun 2, 2015, at 12:16 AM, Mark Friedenbach <mark@friedenbach.org>
> wrote:
> >
> > 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@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@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@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>

[-- Attachment #2: Type: text/html, Size: 9294 bytes --]

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 2220 bytes --]

Given that we have had more than two weeks of public discussion, code is
available and reviewed, and several community identified issues resolved, I
would like to formally request a BIP number be assigned for this work. Will
the BIP editor be so kind as to do so to allow the BIP consensus process to
proceed?

Thank you,
Mark Friedenbach

On Mon, Jun 1, 2015 at 6:49 PM, Mark Friedenbach <mark@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
>

[-- Attachment #2: Type: text/html, Size: 2935 bytes --]

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Gregory Maxwell]

On Wed, Jun 17, 2015 at 1:00 AM, Mark Friedenbach <mark@friedenbach.org> wrote:
> Given that we have had more than two weeks of public discussion, code is
> available and reviewed, and several community identified issues resolved, I
> would like to formally request a BIP number be assigned for this work. Will
> the BIP editor be so kind as to do so to allow the BIP consensus process to
> proceed?

BIP 68, unless you have objections.