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

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

[Mark Friedenbach]

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

Sequence numbers appear to have been originally intended as a mechanism for
transaction replacement within the context of multi-party transaction
construction, e.g. a micropayment channel. The idea is that a participant
can sign successive versions of a transaction, each time incrementing the
sequence field by some amount. Relay nodes perform transaction replacement
according to some policy rule making use of the sequence numbers, e.g.
requiring sequence numbers in a replacement to be monotonically increasing.

As it happens, this cannot be made safe in the bitcoin protocol as deployed
today, as there is no enforcement of the rule that miners include the most
recent transaction in their blocks. As such, any protocol relying on a
transaction replacement policy can be defeated by miners choosing not to
follow that policy, which they may even be incentivised to do so (if older
transactions provide higher fee per byte, for example). Transaction
replacement is presently disabled in Bitcoin Core.

These shortcomings can be fixed in an elegant way by giving sequence
numbers new consensus-enforced semantics as a relative lock-time: if a
sequence number is non-final (MAX_INT), its bitwise inverse is interpreted
as either a relative height or time delta which is added to the height or
median time of the block containing the output being spent to form a
per-input lock-time. The lock-time of each input constructed in this manor,
plus the nLockTime of the transaction itself if any input is non-final must
be satisfied for a transaction to be valid.

For example, a transaction with an txin.nSequence set to 0xffffff9b [==
~(uint32_t)100] is prevented by consensus rule from being selected for
inclusion in a block until the 100th block following the one including the
parent transaction referenced by that input.

In this way one may construct, for example, a bidirectional micropayment
channel where each change of direction increments sequence numbers to make
the transaction become valid prior to any of the previously exchanged
transactions.

This also enables the discussed relative-form of CHECKLOCKTIMEVERIFY to be
implemented in the same way: by checking transaction data only and not
requiring contextual information like the block height or timestamp.

An example implementation of this concept, as a policy change to the
mempool processing of Bitcoin Core is available on github:

https://github.com/maaku/bitcoin/tree/sequencenumbers

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

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

[Peter Todd]

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

On Tue, May 26, 2015 at 06:50:29PM -0700, Mark Friedenbach wrote:
> Sequence numbers appear to have been originally intended as a mechanism for
> transaction replacement within the context of multi-party transaction
> construction, e.g. a micropayment channel. The idea is that a participant
> can sign successive versions of a transaction, each time incrementing the
> sequence field by some amount. Relay nodes perform transaction replacement
> according to some policy rule making use of the sequence numbers, e.g.
> requiring sequence numbers in a replacement to be monotonically increasing.

Can you provide a worked example of this in use? I think I see a major
flaw, but I'd like to see a worked example first.

Keep in mind that there's absolutely no reason to have pending
transactions in mempools until we actually expect them to be mined.
Equally this proposal is no more "consensus enforcement" than simply
increasing the fee (and possibly decreasing the absolute nLockTime) for
each replacement would be; increasing the fee for each mempool
replacement is a hard requirement as an anti-DoS anyway. (this was all
discussed on the mailing list two years ago when RBF was first proposed)

-- 
'peter'[:-1]@petertodd.org
00000000000000000ec0c3a90baa52289171046469fe4a21dc5a0dac4cb758a9

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[Gregory Maxwell]

On Wed, May 27, 2015 at 7:47 AM, Peter Todd <pete@petertodd.org> wrote:
> Equally this proposal is no more "consensus enforcement" than simply
> increasing the fee (and possibly decreasing the absolute nLockTime) for

You've misunderstood it, I think-- Functionally nlocktime but relative
to each txin's height.

But the construction gives the sequence numbers a rational meaning,
they count down the earliest position a transaction can be included.
(e.g. the highest possible sequence number can be included any time
the inputs are included) the next lower sequence number can only be
included one block later than the input its assigned to is included,
the next lower one block beyond that. All consensus enforced.   A
miner could opt to not include the higher sequence number (which is
the only one of the set which it _can_ include) it the hopes of
collecting more fees later on the next block, similar to how someone
could ignore an eligible locked transaction in the hopes that a future
double spend will be more profitable (and that it'll enjoy that
profit) but in both cases it must take nothing at all this block, and
risk being cut off by someone else (and, of course, nothing requires
users use sequence numbers only one apart...).

It makes sequence numbers work exactly like you'd expect-- within the
bounds of whats possible in a decentralized system.  At the same time,
all it is ... is relative nlocktime.

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

[Tier Nolan]

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

This could cause legacy transactions to become unspendable.


A new transaction version number should be used to indicate the change of
the field from sequence number to relative lock time.

Legacy transactions should not have the rule applied to them.

On Wed, May 27, 2015 at 9:18 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Wed, May 27, 2015 at 7:47 AM, Peter Todd <pete@petertodd.org> wrote:
> > Equally this proposal is no more "consensus enforcement" than simply
> > increasing the fee (and possibly decreasing the absolute nLockTime) for
>
> You've misunderstood it, I think-- Functionally nlocktime but relative
> to each txin's height.
>
> But the construction gives the sequence numbers a rational meaning,
> they count down the earliest position a transaction can be included.
> (e.g. the highest possible sequence number can be included any time
> the inputs are included) the next lower sequence number can only be
> included one block later than the input its assigned to is included,
> the next lower one block beyond that. All consensus enforced.   A
> miner could opt to not include the higher sequence number (which is
> the only one of the set which it _can_ include) it the hopes of
> collecting more fees later on the next block, similar to how someone
> could ignore an eligible locked transaction in the hopes that a future
> double spend will be more profitable (and that it'll enjoy that
> profit) but in both cases it must take nothing at all this block, and
> risk being cut off by someone else (and, of course, nothing requires
> users use sequence numbers only one apart...).
>
> It makes sequence numbers work exactly like you'd expect-- within the
> bounds of whats possible in a decentralized system.  At the same time,
> all it is ... is relative nlocktime.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

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

[Peter Todd]

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

On Wed, May 27, 2015 at 08:18:52AM +0000, Gregory Maxwell wrote:
> On Wed, May 27, 2015 at 7:47 AM, Peter Todd <pete@petertodd.org> wrote:
> > Equally this proposal is no more "consensus enforcement" than simply
> > increasing the fee (and possibly decreasing the absolute nLockTime) for
> 
> You've misunderstood it, I think-- Functionally nlocktime but relative
> to each txin's height.
> 
> But the construction gives the sequence numbers a rational meaning,
> they count down the earliest position a transaction can be included.
> (e.g. the highest possible sequence number can be included any time
> the inputs are included) the next lower sequence number can only be
> included one block later than the input its assigned to is included,
> the next lower one block beyond that. All consensus enforced.   A
> miner could opt to not include the higher sequence number (which is
> the only one of the set which it _can_ include) it the hopes of
> collecting more fees later on the next block, similar to how someone
> could ignore an eligible locked transaction in the hopes that a future
> double spend will be more profitable (and that it'll enjoy that
> profit) but in both cases it must take nothing at all this block, and
> risk being cut off by someone else (and, of course, nothing requires
> users use sequence numbers only one apart...).

I understand that part.

I'm just saying it's not clear to me what's the functional difference in
practice between it and having both parties sign a decreasing absolute
nLockTime. For instance, you and I could setup a payment channel using
the following transaction t0:

    1.0 BTC: PT -> 1.0 BTC: PT && (GM || <expiry> CLTV)
    1.0 BTC: GM -> 1.0 BTC: GM && (PT || <expiry> CLTV)

After <expiry> both of us are guaranteed to get our funds back
regardless. I can then give you funds by signing my part of t1a:

    t0.vout[0] <PT sig> <blank> -> 0.5 BTC: PT
    t0.vout[1] <blank> <PT sig> -> 1.5 BTC: GM
    nLockTime = <expiry - 1>

You can then give me funds with t1b:

    t0.vout[0] <blank> <GM sig> -> 1.5 BTC: PT
    t0.vout[1] <GM sig> <blank> -> 0.5 BTC: GM
    nLockTime = <expiry - 2>

etc. etc. We can close the channel by signing a non-nLockTime'd tx at
any time. If you don't co-operate, I have to wait, and hope I get my tx
mined before you get yours.

What I'm not seeing is how the relative nLockTime that nSequence
provides fundamentally changes any of this.

-- 
'peter'[:-1]@petertodd.org
000000000000000001643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[Jorge Timón]

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

On May 27, 2015 12:58 PM, "Peter Todd" <pete@petertodd.org> wrote:

> What I'm not seeing is how the relative nLockTime that nSequence
> provides fundamentally changes any of this.

This allows the implementation of a rcltv that doesn't make script depend
on the current height, in a similar way that cltv uses the nLockTime (which
has been compared with the current height already when checking the script).
In fact, the implementation could be simpler if the goal of maintaining the
original nSequence semantics was ignored ( although not that simpler, but
you wouldn't need to use ~ (bitwise not).
I'm still not sure whether there should be 2 BIPs for this or just one.

> --
> 'peter'[:-1]@petertodd.org
> 000000000000000001643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6
>
>
------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

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

[Telephone Lemien]

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

Please remove me from the mailing list

2015-05-27 3:50 GMT+02:00 Mark Friedenbach <mark@friedenbach.org>:

> Sequence numbers appear to have been originally intended as a mechanism
> for transaction replacement within the context of multi-party transaction
> construction, e.g. a micropayment channel. The idea is that a participant
> can sign successive versions of a transaction, each time incrementing the
> sequence field by some amount. Relay nodes perform transaction replacement
> according to some policy rule making use of the sequence numbers, e.g.
> requiring sequence numbers in a replacement to be monotonically increasing.
>
> As it happens, this cannot be made safe in the bitcoin protocol as
> deployed today, as there is no enforcement of the rule that miners include
> the most recent transaction in their blocks. As such, any protocol relying
> on a transaction replacement policy can be defeated by miners choosing not
> to follow that policy, which they may even be incentivised to do so (if
> older transactions provide higher fee per byte, for example). Transaction
> replacement is presently disabled in Bitcoin Core.
>
> These shortcomings can be fixed in an elegant way by giving sequence
> numbers new consensus-enforced semantics as a relative lock-time: if a
> sequence number is non-final (MAX_INT), its bitwise inverse is interpreted
> as either a relative height or time delta which is added to the height or
> median time of the block containing the output being spent to form a
> per-input lock-time. The lock-time of each input constructed in this manor,
> plus the nLockTime of the transaction itself if any input is non-final must
> be satisfied for a transaction to be valid.
>
> For example, a transaction with an txin.nSequence set to 0xffffff9b [==
> ~(uint32_t)100] is prevented by consensus rule from being selected for
> inclusion in a block until the 100th block following the one including the
> parent transaction referenced by that input.
>
> In this way one may construct, for example, a bidirectional micropayment
> channel where each change of direction increments sequence numbers to make
> the transaction become valid prior to any of the previously exchanged
> transactions.
>
> This also enables the discussed relative-form of CHECKLOCKTIMEVERIFY to be
> implemented in the same way: by checking transaction data only and not
> requiring contextual information like the block height or timestamp.
>
> An example implementation of this concept, as a policy change to the
> mempool processing of Bitcoin Core is available on github:
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

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

[Mike Hearn]

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

>
> Sequence numbers appear to have been originally intended as a mechanism
> for transaction replacement within the context of multi-party transaction
> construction, e.g. a micropayment channel.
>

Yes indeed they were. Satoshis mechanism was more general than micropayment
channels and could do HFT between any set of parties.


> As it happens, this cannot be made safe in the bitcoin protocol as
> deployed today, as there is no enforcement of the rule that miners include
> the most recent transaction in their blocks.
>

Safe is relative - this is the same logic the original replace-by-fee
argument uses. There's no enforcement that miners use any particular
ordering of transactions.

As I believe out of all proposed protocols Satoshi's is still the most
powerful, I would suggest that any change to the semantics on nSequence be
gated by a high bit or something, so the original meaning remains available
if/when resource scheduling and update flood damping are implemented. That
way people can try it out and if miners are breaking things too frequently
by ignoring the chronological ordering people can abandon protocols that
rely on it, and if they aren't they can proceed and benefit from the
greater flexibility.

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

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

[Mark Friedenbach]

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

On Wed, May 27, 2015 at 3:11 AM, Mike Hearn <mike@plan99.net> wrote:

>
> As I believe out of all proposed protocols Satoshi's is still the most
> powerful, I would suggest that any change to the semantics on nSequence be
> gated by a high bit or something, so the original meaning remains available
> if/when resource scheduling and update flood damping are implemented. That
> way people can try it out and if miners are breaking things too frequently
> by ignoring the chronological ordering people can abandon protocols that
> rely on it, and if they aren't they can proceed and benefit from the
> greater flexibility.
>
>
Mike, this proposal was purposefully constructed to maintain as well as
possible the semantics of Satoshi's original construction. Higher sequence
numbers -- chronologically later transactions -- are able to hit the chain
earlier, and therefore it can be reasonably argued will be selected by
miners before the later transactions mature. Did I fail in some way to
capture that original intent?

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

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

[Mike Hearn]

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

>
> Mike, this proposal was purposefully constructed to maintain as well as
> possible the semantics of Satoshi's original construction. Higher sequence
> numbers -- chronologically later transactions -- are able to hit the chain
> earlier, and therefore it can be reasonably argued will be selected by
> miners before the later transactions mature. Did I fail in some way to
> capture that original intent?
>

Right, but the original protocol allowed for e.g. millions of revisions of
the transaction, hence for high frequency trading (that's actually how
Satoshi originally explained it to me - as a way to do HFT - back then the
channel concept didn't exist).

As you point out, with a careful construction of channels you should only
need to bump the sequence number when the channel reverses direction. If
your app only needs to do that rarely, it's a fine approach.And your
proposal does sounds better than sequence numbers being useless like at the
moment. I'm just wondering if we can get back to the original somehow or at
least leave a path open to it, as it seems to be a superset of all other
proposals, features-wise.

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

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

[Mark Friedenbach]

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

I have no problem with modifying the proposal to have the most significant
bit signal use of the nSequence field as a relative lock-time. That leaves
a full 31 bits for experimentation when relative lock-time is not in use. I
have adjusted the code appropriately:

https://github.com/maaku/bitcoin/tree/sequencenumbers

On Wed, May 27, 2015 at 10:39 AM, Mike Hearn <mike@plan99.net> wrote:

> Mike, this proposal was purposefully constructed to maintain as well as
>> possible the semantics of Satoshi's original construction. Higher sequence
>> numbers -- chronologically later transactions -- are able to hit the chain
>> earlier, and therefore it can be reasonably argued will be selected by
>> miners before the later transactions mature. Did I fail in some way to
>> capture that original intent?
>>
>
> Right, but the original protocol allowed for e.g. millions of revisions of
> the transaction, hence for high frequency trading (that's actually how
> Satoshi originally explained it to me - as a way to do HFT - back then the
> channel concept didn't exist).
>
> As you point out, with a careful construction of channels you should only
> need to bump the sequence number when the channel reverses direction. If
> your app only needs to do that rarely, it's a fine approach.And your
> proposal does sounds better than sequence numbers being useless like at the
> moment. I'm just wondering if we can get back to the original somehow or at
> least leave a path open to it, as it seems to be a superset of all other
> proposals, features-wise.
>

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

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

[Mike Hearn]

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

Cool, thanks.

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

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

[Tier Nolan]

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

Can you update it so that it only applies to transactions with version
number 3 and higher.  Changing the meaning of a field is exactly what the
version numbers are for.

You could even decode version 3 transactions like that.

Version 3 transactions have a sequence number of 0xFFFFFFFF and the
sequence number field is re-purposed for relative lock time.

This means that legacy transactions that have already been signed but have
a locktime in the future will still be able to enter the blockchain
(without having to wait significantly longer than expected).

On Thu, May 28, 2015 at 10:56 AM, Mark Friedenbach <mark@friedenbach.org>
wrote:

> I have no problem with modifying the proposal to have the most significant
> bit signal use of the nSequence field as a relative lock-time. That leaves
> a full 31 bits for experimentation when relative lock-time is not in use. I
> have adjusted the code appropriately:
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers
>
> On Wed, May 27, 2015 at 10:39 AM, Mike Hearn <mike@plan99.net> wrote:
>
>> Mike, this proposal was purposefully constructed to maintain as well as
>>> possible the semantics of Satoshi's original construction. Higher sequence
>>> numbers -- chronologically later transactions -- are able to hit the chain
>>> earlier, and therefore it can be reasonably argued will be selected by
>>> miners before the later transactions mature. Did I fail in some way to
>>> capture that original intent?
>>>
>>
>> Right, but the original protocol allowed for e.g. millions of revisions
>> of the transaction, hence for high frequency trading (that's actually how
>> Satoshi originally explained it to me - as a way to do HFT - back then the
>> channel concept didn't exist).
>>
>> As you point out, with a careful construction of channels you should only
>> need to bump the sequence number when the channel reverses direction. If
>> your app only needs to do that rarely, it's a fine approach.And your
>> proposal does sounds better than sequence numbers being useless like at the
>> moment. I'm just wondering if we can get back to the original somehow or at
>> least leave a path open to it, as it seems to be a superset of all other
>> proposals, features-wise.
>>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

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

[Peter Todd]

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

On Thu, May 28, 2015 at 11:30:18AM +0100, Tier Nolan wrote:
> Can you update it so that it only applies to transactions with version
> number 3 and higher.  Changing the meaning of a field is exactly what the
> version numbers are for.
> 
> You could even decode version 3 transactions like that.
> 
> Version 3 transactions have a sequence number of 0xFFFFFFFF and the
> sequence number field is re-purposed for relative lock time.
> 
> This means that legacy transactions that have already been signed but have
> a locktime in the future will still be able to enter the blockchain
> (without having to wait significantly longer than expected).

For that matter, we probably don't want to treat this as a *version*
change, but rather a *feature* flag. For instance, nSequence is
potentially useful for co-ordinating multiple signatures to ensure they
can only be used in certain combinations, a use-case not neccesarily
compatible with this idea of a relative lock. Similarly it's potentially
useful for dealing with malleability.

nSequence is currently the *only* thing in CTxIn's that the signature
signs that can be freely changed; I won't be surprised if we find other
uses for it.

Of course, all of the above is assuming this proposal is useful; that's
not clear to me yet and won't be without fleshed out examples.

-- 
'peter'[:-1]@petertodd.org
000000000000000008464a6a19387029fa99edace15996d06a6343a8345d6167

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[Tier Nolan]

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

On Thu, May 28, 2015 at 1:04 PM, Peter Todd <pete@petertodd.org> wrote:

> For that matter, we probably don't want to treat this as a *version*
> change, but rather a *feature* flag.


I think it is still a version change.  At the moment, the 4 bytes refer to
the sequence number and afterwards they mean something else.

For relative locktime verify, I think most use cases could be block count
based and don't need to be able to count very high.

I think the main benefit is that protocols can have one party trigger a
step while giving the other party guaranteed time to respond.


*Fast Channel Close*

This assumes that malleability is fixed.

Alice creates

TXA:
output (x) to [multisig A1 & B1]

Refund:
input TXA (signed by Alice)
Output [(A2 & relative_check_locktime(150)) OR (multisig A3 &  B2)]

Alice sends Refund to Bob

Bob signs it and sends it back to Alice

Alice verifies the signature, adds her own and sends it to Bob.

She broadcasts TXA (would wait until Bob confirms acceptance).

This means that both Alice and Bob have the refund transaction and can use
it to close the channel (assuming TXA is not mutated).

Alice can send money to Bob by creating a transaction which spends the
output of the refund transaction (splitting the output x-b for Alice and b
for Bob), signing it and sending it to Bob.

Alice can force Bob to close the channel by broadcasting the refund
transaction.  150 blocks later, she gets the channel deposit if he doesn't
act.

If she had sent some money to Bob, he has 150 blocks to sign the
transaction that pays him the most money and broadcast it.  Alice gets the
remainder of the deposit.

Alice cannot broadcast earlier version, since Bob doesn't send her the
signed versions.

This means that the channel doesn't need a defined end date.  Either party
can close the channel whenever they want.

TXA could be protected against malleability by adding a locktime path.
This would only be for use if the transaction is mutated.

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

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

[s7r]

On 5/28/2015 4:35 PM, Tier Nolan wrote:
> On Thu, May 28, 2015 at 1:04 PM, Peter Todd <pete@petertodd.org
> <mailto:pete@petertodd.org>> wrote:
> 
>     For that matter, we probably don't want to treat this as a *version*
>     change, but rather a *feature* flag. 
> 
> 
> I think it is still a version change.  At the moment, the 4 bytes refer
> to the sequence number and afterwards they mean something else.
> 
> For relative locktime verify, I think most use cases could be block
> count based and don't need to be able to count very high. 
> 
> I think the main benefit is that protocols can have one party trigger a
> step while giving the other party guaranteed time to respond.
> 
> *Fast Channel Close
> *
> 
> This assumes that malleability is fixed.
> 

Indeed. This is very important for refunds.

> Alice creates
> 
> TXA:
> output (x) to [multisig A1 & B1]
> 
> Refund:
> input TXA (signed by Alice)
> Output [(A2 & relative_check_locktime(150)) OR (multisig A3 &  B2)]
> 
> Alice sends Refund to Bob
> 
> Bob signs it and sends it back to Alice
> 
> Alice verifies the signature, adds her own and sends it to Bob.
> 
> She broadcasts TXA (would wait until Bob confirms acceptance).
> 
> This means that both Alice and Bob have the refund transaction and can
> use it to close the channel (assuming TXA is not mutated).
> 

In this scenario, if channel is closed, Alice is the only one who can
take the coins back after a relative locktime of 150 blocks. Bob is not
able to do this.

> Alice can send money to Bob by creating a transaction which spends the
> output of the refund transaction (splitting the output x-b for Alice and
> b for Bob), signing it and sending it to Bob.
> 
> Alice can force Bob to close the channel by broadcasting the refund
> transaction.  150 blocks later, she gets the channel deposit if he
> doesn't act.
> 

How is Bob protected in this scenario? If Alice sings a transaction
which spends the output of the refund transaction and gives it to Bob,
Bob can just add its signature and claim his slice of the output,
without necessarily shipping the goods or delivering the services to Alice.

> If she had sent some money to Bob, he has 150 blocks to sign the
> transaction that pays him the most money and broadcast it.  Alice gets
> the remainder of the deposit.
> 
Can you be more explicit here? It doesn't make sense for me.

> Alice cannot broadcast earlier version, since Bob doesn't send her the
> signed versions.
> 
> This means that the channel doesn't need a defined end date.  Either
> party can close the channel whenever they want.
> 
With some risks.

> TXA could be protected against malleability by adding a locktime path. 
> This would only be for use if the transaction is mutated.
> 
How do you apply a locktime path to a tx in the current network consensus?

> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

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

[Tier Nolan]

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

On Thu, May 28, 2015 at 5:22 PM, s7r <s7r@sky-ip.org> wrote:

> In this scenario, if channel is closed, Alice is the only one who can
> take the coins back after a relative locktime of 150 blocks. Bob is not
> able to do this.
>

Yes, Alice is assumed to be the one who funded the channel.  It is a single
direction channel (Alice to Bob).


> How is Bob protected in this scenario?


Assuming the deposit is 1 BTC.

When the channel is created, Alice can broadcast the refund transaction
immediately and the get her money back 150 blocks later.

The full scriptPubKey for the refund transaction would be

OP_IF
    <150> OP_RELATIVE_CHECKLOCKTIME_VERIFY OP_DROP <Alice's public key 2>
OP_CHECKSIGVERIFY
OP_ELSE
    OP_2 <Alice's public key 3> <Bob's public key 2> OP_2
OP_CHECKMULTISIGVERIFY
OP_ENDIF

This means that Alice can spend the output after 150 blocks but with both
signatures Bob and Alice can spend the output without the delay.

She can send money to Bob by spending the non-locked output of the refund
transaction (0.01BTC for Bob and 0.99BTC for Alice).

Bob has a transaction that pays him 0.01BTC and pays Alice 0.99BTC from the
refund transaction and is signed by Alice, but still requires his
signature.  Only Bob can make the transaction valid.

It can be spent as soon as the refund transaction is broadcast.

He has the refund transaction, so he can start the process whenever he
wishes.

Assume the channel runs for a while, and Alice sends 0.3BTC total.

Bob has a transaction which pays him 0.3BTC and Alice 0.7BTC.  He also has
some that pay him less than 0.3, but there is no point in him using those
ones.

Alice decides she wants to close the channel, so asks bob to sign his final
transaction and broadcast it and the refund transaction.

If Bob refuses to do that, then Alice can just broadcast the refund
transaction.

If Bob still refuses to broadcast his final transaction, then Alice gets
1BTC and he gets nothing, after 150 blocks.

This means he will send his final transaction before the 150 blocks have
passed.  This gets him 0.3 and Alice 0.7.

Bob can close the channel immediately and Alice can force it to be closed
within 150 blocks (~1 day).


> If Alice sings a transaction
> which spends the output of the refund transaction and gives it to Bob,
> Bob can just add its signature and claim his slice of the output,
> without necessarily shipping the goods or delivering the services to Alice.
>

Protection against that type of fraud isn't covered by channels.  They are
just to make sure money is handed over.


>  Can you be more explicit here? It doesn't make sense for me.
>

Does the explanation above help?

With some risks.
>

As long as Bob is online and sees the refund transaction being broadcast by
Alice, then there is no risk to him.

Alice can close the transaction whenever she wants, so there is no holdup
risk for her.


> How do you apply a locktime path to a tx in the current network consensus?
>

I mean with OP_CHECKLOCKTIMEVERIFY.

She could say that TXA pays to her in 6 months.

If TXA ends up mutated after being broadcast, then she would have to wait
the 6 months.  It's better than nothing and maybe Bob would sign the
mutated transaction.

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

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

[Mark Friedenbach]

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

Why 3? Do we have a version 2?

As for doing it in serialization, that would alter the txid making it a
hard fork change.
On May 28, 2015 03:30, "Tier Nolan" <tier.nolan@gmail.com> wrote:

> Can you update it so that it only applies to transactions with version
> number 3 and higher.  Changing the meaning of a field is exactly what the
> version numbers are for.
>
> You could even decode version 3 transactions like that.
>
> Version 3 transactions have a sequence number of 0xFFFFFFFF and the
> sequence number field is re-purposed for relative lock time.
>
> This means that legacy transactions that have already been signed but have
> a locktime in the future will still be able to enter the blockchain
> (without having to wait significantly longer than expected).
>
> On Thu, May 28, 2015 at 10:56 AM, Mark Friedenbach <mark@friedenbach.org>
> wrote:
>
>> I have no problem with modifying the proposal to have the most
>> significant bit signal use of the nSequence field as a relative lock-time.
>> That leaves a full 31 bits for experimentation when relative lock-time is
>> not in use. I have adjusted the code appropriately:
>>
>> https://github.com/maaku/bitcoin/tree/sequencenumbers
>>
>> On Wed, May 27, 2015 at 10:39 AM, Mike Hearn <mike@plan99.net> wrote:
>>
>>> Mike, this proposal was purposefully constructed to maintain as well as
>>>> possible the semantics of Satoshi's original construction. Higher sequence
>>>> numbers -- chronologically later transactions -- are able to hit the chain
>>>> earlier, and therefore it can be reasonably argued will be selected by
>>>> miners before the later transactions mature. Did I fail in some way to
>>>> capture that original intent?
>>>>
>>>
>>> Right, but the original protocol allowed for e.g. millions of revisions
>>> of the transaction, hence for high frequency trading (that's actually how
>>> Satoshi originally explained it to me - as a way to do HFT - back then the
>>> channel concept didn't exist).
>>>
>>> As you point out, with a careful construction of channels you should
>>> only need to bump the sequence number when the channel reverses direction.
>>> If your app only needs to do that rarely, it's a fine approach.And your
>>> proposal does sounds better than sequence numbers being useless like at the
>>> moment. I'm just wondering if we can get back to the original somehow or at
>>> least leave a path open to it, as it seems to be a superset of all other
>>> proposals, features-wise.
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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: 4692 bytes --]

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

[Tier Nolan]

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

On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:

> Why 3? Do we have a version 2?
>
I meant whatever the next version is, so you are right, it's version 2.

> As for doing it in serialization, that would alter the txid making it a
> hard fork change.
>
The change is backwards compatible (since there is no restrictions on
sequence numbers).   This makes it a soft fork.

That doesn't change the fact that you are changing what a field in the
transaction represents.

You could say that the sequence number is no longer encoded in the
serialization, it is assumed to be 0xFFFFFFFF for all version 2+
transactions and the relative locktime is a whole new field that is the
same size (and position).

I think keeping some of the bytes for other uses is a good idea.  The
entire top 2 bytes could be ignored when working out relative locktime
verify.  That leaves them fully free to be set to anything.

It could be that if the MSB of the bottom 2 bytes is set, then that
activates the rule and the top 2 bytes are ignored.

Are there any use-cases which need a RLTV of more than 8191 blocks delay
(that can't be covered by the absolute version)?

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

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

[Mark Friedenbach]

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

Oh ok you mean a semantic difference for the purpose of explaining. It
doesn't actually change the code.

Regarding saving more bits, there really isn't much room if you consider
time-based relative locktimes and long-lived channels on the order of a
year or more.

On Thu, May 28, 2015 at 8:18 AM, Tier Nolan <tier.nolan@gmail.com> wrote:

> On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach <mark@friedenbach.org>
> wrote:
>
>> Why 3? Do we have a version 2?
>>
> I meant whatever the next version is, so you are right, it's version 2.
>
>> As for doing it in serialization, that would alter the txid making it a
>> hard fork change.
>>
> The change is backwards compatible (since there is no restrictions on
> sequence numbers).   This makes it a soft fork.
>
> That doesn't change the fact that you are changing what a field in the
> transaction represents.
>
> You could say that the sequence number is no longer encoded in the
> serialization, it is assumed to be 0xFFFFFFFF for all version 2+
> transactions and the relative locktime is a whole new field that is the
> same size (and position).
>
> I think keeping some of the bytes for other uses is a good idea.  The
> entire top 2 bytes could be ignored when working out relative locktime
> verify.  That leaves them fully free to be set to anything.
>
> It could be that if the MSB of the bottom 2 bytes is set, then that
> activates the rule and the top 2 bytes are ignored.
>
> Are there any use-cases which need a RLTV of more than 8191 blocks delay
> (that can't be covered by the absolute version)?
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

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

[Tier Nolan]

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

What are the use cases for relative lock time verify?  I have 1 and I think
that is the kind of thing it is useful for.

I think that most cases are just to guarantee that the other party has a
chance to react.  This means that 8191 blocks should be more than enough
(and most would set it lower).

For long term, the absolute version is just as good.  That depends on use
cases.  "You can't take step 4 until 3 months after step 3 has completed"
doesn't seem useful.

On Thu, May 28, 2015 at 4:38 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:

> Oh ok you mean a semantic difference for the purpose of explaining. It
> doesn't actually change the code.
>
> Regarding saving more bits, there really isn't much room if you consider
> time-based relative locktimes and long-lived channels on the order of a
> year or more.
>
> On Thu, May 28, 2015 at 8:18 AM, Tier Nolan <tier.nolan@gmail.com> wrote:
>
>> On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach <mark@friedenbach.org>
>> wrote:
>>
>>> Why 3? Do we have a version 2?
>>>
>> I meant whatever the next version is, so you are right, it's version 2.
>>
>>> As for doing it in serialization, that would alter the txid making it a
>>> hard fork change.
>>>
>> The change is backwards compatible (since there is no restrictions on
>> sequence numbers).   This makes it a soft fork.
>>
>> That doesn't change the fact that you are changing what a field in the
>> transaction represents.
>>
>> You could say that the sequence number is no longer encoded in the
>> serialization, it is assumed to be 0xFFFFFFFF for all version 2+
>> transactions and the relative locktime is a whole new field that is the
>> same size (and position).
>>
>> I think keeping some of the bytes for other uses is a good idea.  The
>> entire top 2 bytes could be ignored when working out relative locktime
>> verify.  That leaves them fully free to be set to anything.
>>
>> It could be that if the MSB of the bottom 2 bytes is set, then that
>> activates the rule and the top 2 bytes are ignored.
>>
>> Are there any use-cases which need a RLTV of more than 8191 blocks delay
>> (that can't be covered by the absolute version)?
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

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

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

[Rusty Russell]

Tier Nolan <tier.nolan@gmail.com> writes:
> What are the use cases for relative lock time verify?  I have 1 and I think
> that is the kind of thing it is useful for.
>
> I think that most cases are just to guarantee that the other party has a
> chance to react.  This means that 8191 blocks should be more than enough
> (and most would set it lower).
>
> For long term, the absolute version is just as good.  That depends on use
> cases.  "You can't take step 4 until 3 months after step 3 has completed"
> doesn't seem useful.

Lightning channels want them exactly like this to revoke old
transactions, which could be ancient on long-lived channels.

Cheers,
Rusty.