[bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Btc Drak]

I have written the following draft BIP for a new opcode
CHECKSEQUENCEVERIFY by Mark Friedenbach, which introduces a form of
relative-locktime to Bitcoin's scripting language.

https://github.com/btcdrak/bips/blob/bip-checksequenceverify/bip-csv.mediawiki

<pre>
  BIP: XX
  Title: CHECKSEQUENCEVERIFY
  Authors: BtcDrak <btcdrak@gmail.com>
           Mark Friedenbach <mark@friedenbach.org>
  Status: Draft
  Type: Standards Track
  Created: 2015-08-10
</pre>

==Abstract==

This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin
scripting system that in combination with BIP 68 allows execution
pathways of a script to be restricted based on the age of the output
being spent.


==Summary==

CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed
it compares the top item on the stack to the inverse of the nSequence
field of the transaction input containing the scriptSig. If the
inverse of nSequence is less than the sequence threshold (1 << 31),
the transaction version is greater than or equal to 2, and the top
item on the stack is less than or equal to the inverted nSequence,
script evaluation continues as though a NOP was executed. Otherwise
the script fails immediately.

BIP 68's redefinition of nSequence prevents a non-final transaction
from being selected for inclusion in a block until the corresponding
input has reached the specified age, as measured in block heiht or
block time. By comparing the argument to CHECKSEQUENCEVERIFY against
the nSequence field, we indirectly verify a desired minimum age of the
the output being spent; until that relative age has been reached any
script execution pathway including the CHECKSEQUENCEVERIFY will fail
to validate, causing the transaction not to be selected for inclusion
in a block.


==Motivation==

BIP 68 repurposes the transaction nSequence field meaning by giving
sequence numbers new consensus-enforced semantics as a relative
lock-time. However, there is no way to build Bitcoin scripts to make
decisions based on this field.

By making the nSequence field accessible to script, it becomes
possible to construct code pathways that only become accessible some
minimum time after proof-of-publication. This enables a wide variety
of applications in phased protocols such as escrow, payment channels,
or bidirectional pegs.


==Specification==

Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.


    case OP_NOP3:
    {
        if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
            // not enabled; treat as a NOP3
            if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
                return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
            }
            break;
        }

        if (stack.size() < 1)
            return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);

        // Note that unlike CHECKLOCKTIMEVERIFY we do not need to
        // accept 5-byte bignums since any value greater than or
        // equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected
        // anyway. This limitation just happens to coincide with
        // CScriptNum's default 4-byte limit with an explicit sign
        // bit.
        //
        // This means there is a maximum relative lock time of 52
        // years, even though the nSequence field in transactions
        // themselves is uint32_t and could allow a relative lock
        // time of up to 120 years.
        const CScriptNum nInvSequence(stacktop(-1), fRequireMinimal);

        // In the rare event that the argument may be < 0 due to
        // some arithmetic being done first, you can always use
        // 0 MAX CHECKSEQUENCEVERIFY.
        if (nInvSequence < 0)
            return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);

        // Actually compare the specified inverse sequence number
        // with the input.
        if (!CheckSequence(nInvSequence))
            return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);

        break;
    }

    bool CheckSequence(const CScriptNum& nInvSequence) const
    {
        int64_t txToInvSequence;

        // Fail under all circumstances if the transaction's version
        // number is not set high enough to enable enforced sequence
        // number rules.
        if (txTo->nVersion < 2)
            return false;

        // Sequence number must be inverted to convert it into a
        // relative lock-time.
        txToInvSequence = (int64_t)~txTo->vin[nIn].nSequence;

        // Sequence numbers under SEQUENCE_THRESHOLD are not consensus
        // constrained.
        if (txToInvSequence >= SEQUENCE_THRESHOLD)
            return false;

        // There are two types of relative lock-time: lock-by-
        // blockheight and lock-by-blocktime, distinguished by
        // whether txToInvSequence < LOCKTIME_THRESHOLD.
        //
        // We want to compare apples to apples, so fail the script
        // unless the type of lock-time being tested is the same as
        // the lock-time in the transaction input.
        if (!(
            (txToInvSequence <  LOCKTIME_THRESHOLD && nInvSequence <
LOCKTIME_THRESHOLD) ||
            (txToInvSequence >= LOCKTIME_THRESHOLD && nInvSequence >=
LOCKTIME_THRESHOLD)
        ))
            return false;

        // Now that we know we're comparing apples-to-apples, the
        // comparison is a simple numeric one.
        if (nInvSequence > txInvToSequence)
            return false;

        return true;
    }

https://github.com/maaku/bitcoin/commit/33be476a60fcc2afbe6be0ca7b93a84209173eb2


==Example: Escrow with Timeout==

An escrow that times out automatically 30 days after being funded can be
established in the following way. Alice, Bob and Escrow create a 2-of-3
address with the following redeemscript.

    IF
        2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3
CHECKMULTISIGVERIFY
    ELSE
        <LOCKTIME_THRESHOLD + 30*24*60*60> CHECKSEQUENCEVERIFY DROP
        <Alice's pubkey> CHECKSIGVERIFY
    ENDIF

At any time funds can be spent using signatures from any two of Alice,
Bob or the Escrow.

After 30 days Alice can sign alone.

The clock does not start ticking until the payment to the escrow address
confirms.


==Reference Implementation==

A reference implementation is provided in the following git repository:

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


==Deployment==

We reuse the double-threshold switchover mechanism from BIPs 34 and
66, with the same thresholds, but for nVersion = 4. The new rules are
in effect for every block (at height H) with nVersion = 4 and at least
750 out of 1000 blocks preceding it (with heights H-1000..H-1) also
have nVersion = 4. Furthermore, when 950 out of the 1000 blocks
preceding a block do have nVersion = 4, nVersion = 3 blocks become
invalid, and all further blocks enforce the new rules.

It is recommended that this soft-fork deployment trigger include other
related proposals for improving Bitcoin's lock-time capabilities, including:

[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]:
OP_CHECKLOCKTIMEVERIFY,

[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]:
Consensus-enforced transaction replacement signalled via sequence numbers,

and [https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki BIP XX]:
Median-Past-Time-Lock.


==Credits==

Mark Friedenbach invented the application of sequence numbers to
achieve relative lock-time, and wrote the reference implementation of
CHECKSEQUENCEVERIFY.

The reference implementation and this BIP was based heavily on work
done by Peter Todd for the closely related BIP 65.

BtcDrak authored this BIP document.


==References==

BIP 68: Consensus-enforced transaction replacement signalled via
sequence numbers
https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki

BIP 65: OP_CHECKLOCKTIMEVERIFY
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

BIP XX: Median past block time for time-lock constraints
https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki

HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and
revocation hashes
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html


==Copyright==

This document is placed in the public domain.

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Mark Friedenbach]

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

As per the rules of BIP 1, I hereby request that the BIP editor please
assign an official number to this work. The idea has been discussed before
on the bitcoin-dev mailing list:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008452.html

And a reference implementation is available here:

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


On Thu, Aug 13, 2015 at 4:06 AM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have written the following draft BIP for a new opcode
> CHECKSEQUENCEVERIFY by Mark Friedenbach, which introduces a form of
> relative-locktime to Bitcoin's scripting language.
>
>
> https://github.com/btcdrak/bips/blob/bip-checksequenceverify/bip-csv.mediawiki
>
> <pre>
>   BIP: XX
>   Title: CHECKSEQUENCEVERIFY
>   Authors: BtcDrak <btcdrak@gmail.com>
>            Mark Friedenbach <mark@friedenbach.org>
>   Status: Draft
>   Type: Standards Track
>   Created: 2015-08-10
> </pre>
>
> ==Abstract==
>
> This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin
> scripting system that in combination with BIP 68 allows execution
> pathways of a script to be restricted based on the age of the output
> being spent.
>
>
> ==Summary==
>
> CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed
> it compares the top item on the stack to the inverse of the nSequence
> field of the transaction input containing the scriptSig. If the
> inverse of nSequence is less than the sequence threshold (1 << 31),
> the transaction version is greater than or equal to 2, and the top
> item on the stack is less than or equal to the inverted nSequence,
> script evaluation continues as though a NOP was executed. Otherwise
> the script fails immediately.
>
> BIP 68's redefinition of nSequence prevents a non-final transaction
> from being selected for inclusion in a block until the corresponding
> input has reached the specified age, as measured in block heiht or
> block time. By comparing the argument to CHECKSEQUENCEVERIFY against
> the nSequence field, we indirectly verify a desired minimum age of the
> the output being spent; until that relative age has been reached any
> script execution pathway including the CHECKSEQUENCEVERIFY will fail
> to validate, causing the transaction not to be selected for inclusion
> in a block.
>
>
> ==Motivation==
>
> BIP 68 repurposes the transaction nSequence field meaning by giving
> sequence numbers new consensus-enforced semantics as a relative
> lock-time. However, there is no way to build Bitcoin scripts to make
> decisions based on this field.
>
> By making the nSequence field accessible to script, it becomes
> possible to construct code pathways that only become accessible some
> minimum time after proof-of-publication. This enables a wide variety
> of applications in phased protocols such as escrow, payment channels,
> or bidirectional pegs.
>
>
> ==Specification==
>
> Refer to the reference implementation, reproduced below, for the precise
> semantics and detailed rationale for those semantics.
>
>
>     case OP_NOP3:
>     {
>         if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
>             // not enabled; treat as a NOP3
>             if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
>                 return set_error(serror,
> SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
>             }
>             break;
>         }
>
>         if (stack.size() < 1)
>             return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>
>         // Note that unlike CHECKLOCKTIMEVERIFY we do not need to
>         // accept 5-byte bignums since any value greater than or
>         // equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected
>         // anyway. This limitation just happens to coincide with
>         // CScriptNum's default 4-byte limit with an explicit sign
>         // bit.
>         //
>         // This means there is a maximum relative lock time of 52
>         // years, even though the nSequence field in transactions
>         // themselves is uint32_t and could allow a relative lock
>         // time of up to 120 years.
>         const CScriptNum nInvSequence(stacktop(-1), fRequireMinimal);
>
>         // In the rare event that the argument may be < 0 due to
>         // some arithmetic being done first, you can always use
>         // 0 MAX CHECKSEQUENCEVERIFY.
>         if (nInvSequence < 0)
>             return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);
>
>         // Actually compare the specified inverse sequence number
>         // with the input.
>         if (!CheckSequence(nInvSequence))
>             return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);
>
>         break;
>     }
>
>     bool CheckSequence(const CScriptNum& nInvSequence) const
>     {
>         int64_t txToInvSequence;
>
>         // Fail under all circumstances if the transaction's version
>         // number is not set high enough to enable enforced sequence
>         // number rules.
>         if (txTo->nVersion < 2)
>             return false;
>
>         // Sequence number must be inverted to convert it into a
>         // relative lock-time.
>         txToInvSequence = (int64_t)~txTo->vin[nIn].nSequence;
>
>         // Sequence numbers under SEQUENCE_THRESHOLD are not consensus
>         // constrained.
>         if (txToInvSequence >= SEQUENCE_THRESHOLD)
>             return false;
>
>         // There are two types of relative lock-time: lock-by-
>         // blockheight and lock-by-blocktime, distinguished by
>         // whether txToInvSequence < LOCKTIME_THRESHOLD.
>         //
>         // We want to compare apples to apples, so fail the script
>         // unless the type of lock-time being tested is the same as
>         // the lock-time in the transaction input.
>         if (!(
>             (txToInvSequence <  LOCKTIME_THRESHOLD && nInvSequence <
> LOCKTIME_THRESHOLD) ||
>             (txToInvSequence >= LOCKTIME_THRESHOLD && nInvSequence >=
> LOCKTIME_THRESHOLD)
>         ))
>             return false;
>
>         // Now that we know we're comparing apples-to-apples, the
>         // comparison is a simple numeric one.
>         if (nInvSequence > txInvToSequence)
>             return false;
>
>         return true;
>     }
>
>
> https://github.com/maaku/bitcoin/commit/33be476a60fcc2afbe6be0ca7b93a84209173eb2
>
>
> ==Example: Escrow with Timeout==
>
> An escrow that times out automatically 30 days after being funded can be
> established in the following way. Alice, Bob and Escrow create a 2-of-3
> address with the following redeemscript.
>
>     IF
>         2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3
> CHECKMULTISIGVERIFY
>     ELSE
>         <LOCKTIME_THRESHOLD + 30*24*60*60> CHECKSEQUENCEVERIFY DROP
>         <Alice's pubkey> CHECKSIGVERIFY
>     ENDIF
>
> At any time funds can be spent using signatures from any two of Alice,
> Bob or the Escrow.
>
> After 30 days Alice can sign alone.
>
> The clock does not start ticking until the payment to the escrow address
> confirms.
>
>
> ==Reference Implementation==
>
> A reference implementation is provided in the following git repository:
>
> https://github.com/maaku/bitcoin/tree/checksequenceverify
>
>
> ==Deployment==
>
> We reuse the double-threshold switchover mechanism from BIPs 34 and
> 66, with the same thresholds, but for nVersion = 4. The new rules are
> in effect for every block (at height H) with nVersion = 4 and at least
> 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also
> have nVersion = 4. Furthermore, when 950 out of the 1000 blocks
> preceding a block do have nVersion = 4, nVersion = 3 blocks become
> invalid, and all further blocks enforce the new rules.
>
> It is recommended that this soft-fork deployment trigger include other
> related proposals for improving Bitcoin's lock-time capabilities,
> including:
>
> [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]:
> OP_CHECKLOCKTIMEVERIFY,
>
> [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]:
> Consensus-enforced transaction replacement signalled via sequence numbers,
>
> and [https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki BIP
> XX]:
> Median-Past-Time-Lock.
>
>
> ==Credits==
>
> Mark Friedenbach invented the application of sequence numbers to
> achieve relative lock-time, and wrote the reference implementation of
> CHECKSEQUENCEVERIFY.
>
> The reference implementation and this BIP was based heavily on work
> done by Peter Todd for the closely related BIP 65.
>
> BtcDrak authored this BIP document.
>
>
> ==References==
>
> BIP 68: Consensus-enforced transaction replacement signalled via
> sequence numbers
> https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
>
> BIP 65: OP_CHECKLOCKTIMEVERIFY
> https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
>
> BIP XX: Median past block time for time-lock constraints
> https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki
>
> HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and
> revocation hashes
>
> http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html
>
>
> ==Copyright==
>
> This document is placed in the public domain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Gregory Maxwell]

On Thu, Aug 13, 2015 at 6:12 PM, Mark Friedenbach <mark@friedenbach.org> wrote:
> As per the rules of BIP 1, I hereby request that the BIP editor please
> assign an official number to this work. The idea has been discussed before
> on the bitcoin-dev mailing list:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008452.html
>
> And a reference implementation is available here:
>
> https://github.com/maaku/bitcoin/tree/checksequenceverify

I think it's important to allow some time for discussion with the
actual proposed text up; as understandings can shift significantly. :)
Btcdrak already asked me for numbers prior to posting text at all and
I asked him to post text...

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Joseph Poon]

Very cool! This will certainly help make Lightning Network testable on
the main-chain and permit channels to remain open indefinitely. I'm
looking forward to it.

On Thu, Aug 13, 2015 at 12:06:44PM +0100, Btc Drak via bitcoin-dev wrote:
>         // Note that unlike CHECKLOCKTIMEVERIFY we do not need to
>         // accept 5-byte bignums since any value greater than or
>         // equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected
>         // anyway. This limitation just happens to coincide with
>         // CScriptNum's default 4-byte limit with an explicit sign
>         // bit.

I haven't tested the details of this, but is there another bit available
for use in the future for the relative blockheight?

I strongly believe that Lightning needs mitigations for a systemic
supervillan attack which attemps to flood the network with transactions,
which can hypothetically be mitigated with something like a timestop
bit (as originally suggested by gmaxwell).

Summary: If a block is flagged as timestopped (whether automatically or
by vote or other mechanism), then an auxillary blockheigh is frozen and
does not increment. This auxillary blockheight is only used for
accounting in timestopped height computation (and isn't used for
anything else). So as the real blockheight increments, the auxillary
blockheight can sometimes stop and stay the same. If a transaction has a
timestop bit enabled, then the transaction's OP_CSV relative height is
dependent upon the auxillary height, not the real block height. This
allows for a large backlog of transactions which must occur before a
particular (relative) block height to enter into the blockchain.

I'm not sure if it's out of scope, but it could make sense to consider
the possibility for additional state(s) with relative height computation
today. Ideally, there'd be some kind of "version" byte which can be
recontextualized into something later, but I don't know how that could
cleanly fit into the data structure/code.

-- 
Joseph Poon

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Mark Friedenbach]

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

On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I haven't tested the details of this, but is there another bit available
> for use in the future for the relative blockheight?
>
> I strongly believe that Lightning needs mitigations for a systemic
> supervillan attack which attemps to flood the network with transactions,
> which can hypothetically be mitigated with something like a timestop
> bit (as originally suggested by gmaxwell).
>

This proposal includes no such provision.

Since we talked about it, I spent considerable time thinking about the
supposed risk and proposed mitigations. I'm frankly not convinced that it
is a risk of high enough credibility to worry about, or if it is that a
protocol-level complication is worth doing.

The scenario as I understand it is a hub turns evil and tries to cheat
every single one of its users out of their bonds. Normally a lightning user
is protected form such behavior because they have time to broadcast their
own transactions spending part or all of the balance as fees. Therefore
because of the threat of mutually assured destruction, the optimal outcome
is to be an honest participant.

But, the argument goes, the hub has many channels with many different
people closing at the same time. So if the hub tries to cheat all of them
at once by DoS'ing the network, it can do so and spend more in fees than
any one participant stands to lose. My issue with this is that users don't
act alone -- users can be assured that other users will react, and all of
them together have enough coins to burn to make the attack unprofitable.
The hub-cheats-many-users case really is the same as the
hub-cheats-one-user case if the users act out their role in unison, which
they don't have to coordinate to do.

Other than that, even if you are still concerned about that  scenario, I'm
not sure timestop is the appropriate solution. A timestop is a
protocol-level complication that is not trivial to implement, indeed I'm
not even sure there is a way to implement it at all -- how do you
differentiate in consensus code a DoS attack from regular old blocks
filling up? And if you could, why add further complication to the consensus
protocol?

A simpler solution to me seems to be outsourcing the response to an attack
to a third party, or otherwise engineering ways for users to
respond-by-default even if their wallet is offline, or otherwise assuring
sufficient coordination in the event of a bad hub.

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Matt Corallo]

On 08/14/15 00:47, Mark Friedenbach via bitcoin-dev wrote:
> On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
>     I haven't tested the details of this, but is there another bit available
>     for use in the future for the relative blockheight?
> 
>     I strongly believe that Lightning needs mitigations for a systemic
>     supervillan attack which attemps to flood the network with transactions,
>     which can hypothetically be mitigated with something like a timestop
>     bit (as originally suggested by gmaxwell).
> 
> 
> This proposal includes no such provision.
> 
> Since we talked about it, I spent considerable time thinking about the
> supposed risk and proposed mitigations. I'm frankly not convinced that
> it is a risk of high enough credibility to worry about, or if it is that
> a protocol-level complication is worth doing.
> 
> The scenario as I understand it is a hub turns evil and tries to cheat
> every single one of its users out of their bonds. Normally a lightning
> user is protected form such behavior because they have time to broadcast
> their own transactions spending part or all of the balance as fees.

My concern is how the hell do you automate this? Having a threat of
"well, everyone could update their software to a new version which will
destroy all coins right now" is kinda useless, and trying to come up
with a reasonable set of metrics as to how much and when you move from
just paying the fee to destroying coins is really hard, especially if
you assume the attacker is a miner with, say, enough hashrate (maybe
rented) to get one or three blocks in the next day (the timeout period).

> Therefore because of the threat of mutually assured destruction, the
> optimal outcome is to be an honest participant.
> 
> But, the argument goes, the hub has many channels with many different
> people closing at the same time. So if the hub tries to cheat all of
> them at once by DoS'ing the network, it can do so and spend more in fees
> than any one participant stands to lose. My issue with this is that
> users don't act alone -- users can be assured that other users will
> react, and all of them together have enough coins to burn to make the
> attack unprofitable.

Now users are coordinating quickly in an attack scenario?

> The hub-cheats-many-users case really is the same
> as the hub-cheats-one-user case if the users act out their role in
> unison, which they don't have to coordinate to do.
> 
> Other than that, even if you are still concerned about that  scenario,
> I'm not sure timestop is the appropriate solution. A timestop is a
> protocol-level complication that is not trivial to implement, indeed I'm
> not even sure there is a way to implement it at all -- how do you
> differentiate in consensus code a DoS attack from regular old blocks
> filling up? And if you could, why add further complication to the
> consensus protocol?

Yea, implementation is really tricky here. I do not at all think we
should be thinking about implementing this any time soon, and should
assume Lightning will have to stand reasonably on its own without it
first, and only if it gains a lot of traction will there be enough
motivation for making such a change at the Bitcoin protocol level for
Lightning.

> A simpler solution to me seems to be outsourcing the response to an
> attack to a third party

Doesnt that defeat the purpose of Lightning?

> or otherwise engineering ways for users to
> respond-by-default even if their wallet is offline, or otherwise
> assuring sufficient coordination in the event of a bad hub.

I'm not even sure if sufficient coordination is a sufficient solution.
If you assume a hub just shut down, and everyone is trying to flush to
the chain, with a backlog of a few days worth of transactions (with
timeouts of a day or so), and users are even paying huge fees (99% of
what they'd get back), if the former-hub is a miner, it can claim that
last 1% of many of the transactions that take longer than a day to confirm.

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Mark Friedenbach]

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

With the assumed malleability-fix CHECKSIG2 version of lightning, watching
for and responding to bad behavior is fully outsourceable. You can
synchronize channel state (signed refund transactions) with a third party
that watches for replay of old transactions on the mainnet, and starts the
refund process if it observes them, paying the fees necessary to get on the
chain.

With the CLTV/CSV-only form of the hash time-lock contracts that Rusty has
developed, this is indeed something the users' wallets would have to be
online to observe happening and respond to. I presume that we are
eventually going to get a CHECKSIG2 with some kind of malleability-immune
signing scheme in the long term, and that we are not interested in
introducing new consensus behavior to cover that short stopgap.

> I'm not even sure if sufficient coordination is a sufficient solution.

A regrettable choice of words. In this case it is game theoretic
cooperation, not coordination. The users need only expect that each other
would react the same way, being willing to burn money as fees that would
otherwise be stolen. They don't actually have to communicate with each
other in order to cooperate.

You are correct though that hubs-with-hashpower complicate this situation.
Although a hub with hashpower also creates risk in the timestop scenario
too...

On Fri, Aug 14, 2015 at 11:53 AM, Matt Corallo <lf-lists@mattcorallo.com>
wrote:

>
>
> On 08/14/15 00:47, Mark Friedenbach via bitcoin-dev wrote:
> > On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> >     I haven't tested the details of this, but is there another bit
> available
> >     for use in the future for the relative blockheight?
> >
> >     I strongly believe that Lightning needs mitigations for a systemic
> >     supervillan attack which attemps to flood the network with
> transactions,
> >     which can hypothetically be mitigated with something like a timestop
> >     bit (as originally suggested by gmaxwell).
> >
> >
> > This proposal includes no such provision.
> >
> > Since we talked about it, I spent considerable time thinking about the
> > supposed risk and proposed mitigations. I'm frankly not convinced that
> > it is a risk of high enough credibility to worry about, or if it is that
> > a protocol-level complication is worth doing.
> >
> > The scenario as I understand it is a hub turns evil and tries to cheat
> > every single one of its users out of their bonds. Normally a lightning
> > user is protected form such behavior because they have time to broadcast
> > their own transactions spending part or all of the balance as fees.
>
> My concern is how the hell do you automate this? Having a threat of
> "well, everyone could update their software to a new version which will
> destroy all coins right now" is kinda useless, and trying to come up
> with a reasonable set of metrics as to how much and when you move from
> just paying the fee to destroying coins is really hard, especially if
> you assume the attacker is a miner with, say, enough hashrate (maybe
> rented) to get one or three blocks in the next day (the timeout period).
>
> > Therefore because of the threat of mutually assured destruction, the
> > optimal outcome is to be an honest participant.
> >
> > But, the argument goes, the hub has many channels with many different
> > people closing at the same time. So if the hub tries to cheat all of
> > them at once by DoS'ing the network, it can do so and spend more in fees
> > than any one participant stands to lose. My issue with this is that
> > users don't act alone -- users can be assured that other users will
> > react, and all of them together have enough coins to burn to make the
> > attack unprofitable.
>
> Now users are coordinating quickly in an attack scenario?
>
> > The hub-cheats-many-users case really is the same
> > as the hub-cheats-one-user case if the users act out their role in
> > unison, which they don't have to coordinate to do.
> >
> > Other than that, even if you are still concerned about that  scenario,
> > I'm not sure timestop is the appropriate solution. A timestop is a
> > protocol-level complication that is not trivial to implement, indeed I'm
> > not even sure there is a way to implement it at all -- how do you
> > differentiate in consensus code a DoS attack from regular old blocks
> > filling up? And if you could, why add further complication to the
> > consensus protocol?
>
> Yea, implementation is really tricky here. I do not at all think we
> should be thinking about implementing this any time soon, and should
> assume Lightning will have to stand reasonably on its own without it
> first, and only if it gains a lot of traction will there be enough
> motivation for making such a change at the Bitcoin protocol level for
> Lightning.
>
> > A simpler solution to me seems to be outsourcing the response to an
> > attack to a third party
>
> Doesnt that defeat the purpose of Lightning?
>
> > or otherwise engineering ways for users to
> > respond-by-default even if their wallet is offline, or otherwise
> > assuring sufficient coordination in the event of a bad hub.
>
> I'm not even sure if sufficient coordination is a sufficient solution.
> If you assume a hub just shut down, and everyone is trying to flush to
> the chain, with a backlog of a few days worth of transactions (with
> timeouts of a day or so), and users are even paying huge fees (99% of
> what they'd get back), if the former-hub is a miner, it can claim that
> last 1% of many of the transactions that take longer than a day to confirm.
>

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Jorge Timón]

I extremely dislike the inversion to preserve the "previous nSequence
semantics". The "previous nSequence semantics" were
consensus-unenforceable but we can cover the same use cases (or the
realistic ones at least) with nMaturity. Let's face it and move on
without technical debt we don't need and may regret. If we do this
inversion we will likely carry it for very long if not forever.
As a side effect, I believe documentation can become much clearer
(maybe even shorter simultaneusly).

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Btc Drak]

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

Please note there is now a PR for this BIP[1] and also a pull request for
the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].

[1] https://github.com/bitcoin/bips/pull/179
[2] https://github.com/bitcoin/bitcoin/pull/6564

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Jorge Timón]

I repeated my nit on https://github.com/bitcoin/bips/pull/179


On Mon, Aug 17, 2015 at 9:58 PM, Btc Drak via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Please note there is now a PR for this BIP[1] and also a pull request for
> the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].
>
> [1] https://github.com/bitcoin/bips/pull/179
> [2] https://github.com/bitcoin/bitcoin/pull/6564
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Mark Friedenbach]

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

I am indifferent on this issue (the bit inversion), but so far only Jorge
has spoken up. I opted for this detail during implementation in order to
preserve existing semantics, even if those semantics are not commonly used.
This was the conservative choice, driven in part because I didn't want the
proposal to be held up by the other side saying "this is confusing because
it changes how sequence numbers work! it used to count up but now it counts
down!"

I can see both sides and as I said I'm indifferent, so I went with the
conservative choice of not messing with existing semantics. However if
there is strong preferences from _multiple_ people on this matter it is not
too late to change. If anyone feels strongly about this, please speak up.

On Wed, Aug 19, 2015 at 3:37 AM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I repeated my nit on https://github.com/bitcoin/bips/pull/179
>
>
> On Mon, Aug 17, 2015 at 9:58 PM, Btc Drak via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Please note there is now a PR for this BIP[1] and also a pull request for
> > the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].
> >
> > [1] https://github.com/bitcoin/bips/pull/179
> > [2] https://github.com/bitcoin/bitcoin/pull/6564
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Joseph Poon]

On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev wrote:
> If anyone feels strongly about this, please speak up.
> 
> On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> > I repeated my nit on https://github.com/bitcoin/bips/pull/179

I am also indifferent, but also dislike technical debt.

It should maybe be noted for those who wish to do/write-code-for mempool
transaction selection (irrespective of one's opinion on it) that lower
is better, since transactions with shorter relative locks are
transactions with "higher priority".

-- 
Joseph Poon

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Jorge Timón]

On Wed, Aug 19, 2015 at 11:27 PM, Joseph Poon <joseph@lightning.network> wrote:
> On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev wrote:
>> If anyone feels strongly about this, please speak up.
>>
>> On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> > I repeated my nit on https://github.com/bitcoin/bips/pull/179
>
> I am also indifferent, but also dislike technical debt.
>
> It should maybe be noted for those who wish to do/write-code-for mempool
> transaction selection (irrespective of one's opinion on it) that lower
> is better, since transactions with shorter relative locks are
> transactions with "higher priority".

That policy code should be simple to change, but thank you for pointing it out.
Also thank you for declaring your position (indifference) on the subject.

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Peter Todd]

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

On Wed, Aug 19, 2015 at 02:27:10PM -0700, Joseph Poon via bitcoin-dev wrote:
> On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev wrote:
> > If anyone feels strongly about this, please speak up.
> > 
> > On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 
> > > I repeated my nit on https://github.com/bitcoin/bips/pull/179
> 
> I am also indifferent, but also dislike technical debt.
> 
> It should maybe be noted for those who wish to do/write-code-for mempool
> transaction selection (irrespective of one's opinion on it) that lower
> is better, since transactions with shorter relative locks are
> transactions with "higher priority".

ACK on removing the inversion of nSequence from what would be human
readable.

I don't want to spend the rest of my life mentally having to subtrace
from 0xFFFFFFFF :)

-- 
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Tom Harding]

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

ack no inversion. This can actually allow more direct preservation of
existing semantics.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html


On 8/19/2015 9:21 AM, Mark Friedenbach via bitcoin-dev wrote:
> I am indifferent on this issue (the bit inversion), but so far only
> Jorge has spoken up. I opted for this detail during implementation in
> order to preserve existing semantics, even if those semantics are not
> commonly used. This was the conservative choice, driven in part
> because I didn't want the proposal to be held up by the other side
> saying "this is confusing because it changes how sequence numbers
> work! it used to count up but now it counts down!"
>
> I can see both sides and as I said I'm indifferent, so I went with the
> conservative choice of not messing with existing semantics. However if
> there is strong preferences from _multiple_ people on this matter it
> is not too late to change. If anyone feels strongly about this, please
> speak up.
>
> On Wed, Aug 19, 2015 at 3:37 AM, Jorge Timón
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     I repeated my nit on https://github.com/bitcoin/bips/pull/179
>
>
>     On Mon, Aug 17, 2015 at 9:58 PM, Btc Drak via bitcoin-dev
>     <bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>     > Please note there is now a PR for this BIP[1] and also a pull
>     request for
>     > the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].
>     >
>     > [1] https://github.com/bitcoin/bips/pull/179
>     > [2] https://github.com/bitcoin/bitcoin/pull/6564
>


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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Gregory Maxwell]

On Mon, Aug 24, 2015 at 12:25 AM, Tom Harding via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> ack no inversion. This can actually allow more direct preservation of
> existing semantics.
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html

I can't follow this logic. Can you help?  The existing semantics, to
the extent that they exist at all is that the earliest version starts
with the lowest sequence number then counts up (and if it makes its
way to the highest number, the result is final-- because it could go
no higher).

Thats the semantics 'the inversion' accomplishes for CSV: the that the
first version of a transaction begins with a smaller number which
successful versions increase, and the highest possible number is final
(no delay, because no delay is the shortest delay).


Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
discussion has any thought been given to represent one block with more
than one increment?  This would leave additional space for future
signaling, or allow, for example, higher resolution numbers for a
sharechain commitement.

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Jorge Timón]

On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
> discussion has any thought been given to represent one block with more
> than one increment?  This would leave additional space for future
> signaling, or allow, for example, higher resolution numbers for a
> sharechain commitement.

No, I don't think anybody thought about this. I just explained this to
Pieter using "for example, 10 instead of 1".
He suggested 600 increments so that it is more similar to timestamps.

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Mark Friedenbach]

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

A power of 2 would be far more efficient here. The key question is how long
of a relative block time do you need? Figure out what the maximum should be
( I don't know what that would be, any ideas?) and then see how many bits
you have left over.
On Aug 23, 2015 7:23 PM, "Jorge Timón" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
> > discussion has any thought been given to represent one block with more
> > than one increment?  This would leave additional space for future
> > signaling, or allow, for example, higher resolution numbers for a
> > sharechain commitement.
>
> No, I don't think anybody thought about this. I just explained this to
> Pieter using "for example, 10 instead of 1".
> He suggested 600 increments so that it is more similar to timestamps.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Mark Friedenbach]

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

To follow up on this, let's say that you want to be able to have up to 1
year relative lock-times. This choice is somewhat arbitrary and what I
would like some input on, but I'll come back to this point.

 * 1 bit is necessary to enable/disable relative lock-time.

 * 1 bit is necessary to indicate whether seconds vs blocks as the unit of
measurement.

 * 1 year of time with 1-second granularity requires 25 bits. However since
blocks occur at approximately 10 minute intervals on average, having a
relative lock-time significantly less than this interval doesn't make much
sense. A granularity of 256 seconds would be greater than the Nyquist
frequency and requires only 17 bits.

 * 1 year of blocks with 1-block granularity requires 16 bits.

So time-based relative lock time requires about 19 bits, and block-based
relative lock-time requires about 18 bits. That leaves 13 or 14 bits for
other uses.

Assuming a maximum of 1-year relative lock-times. But what is an
appropriate maximum to choose? The use cases I have considered have only
had lock times on the order of a few days to a month or so. However I would
feel uncomfortable going less than a year for a hard maximum, and am having
trouble thinking of any use case that would require more than a year of
lock-time. Can anyone else think of a use case that requires >1yr relative
lock-time?

TL;DR

On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:

> A power of 2 would be far more efficient here. The key question is how
> long of a relative block time do you need? Figure out what the maximum
> should be ( I don't know what that would be, any ideas?) and then see how
> many bits you have left over.
> On Aug 23, 2015 7:23 PM, "Jorge Timón" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
>> > discussion has any thought been given to represent one block with more
>> > than one increment?  This would leave additional space for future
>> > signaling, or allow, for example, higher resolution numbers for a
>> > sharechain commitement.
>>
>> No, I don't think anybody thought about this. I just explained this to
>> Pieter using "for example, 10 instead of 1".
>> He suggested 600 increments so that it is more similar to timestamps.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Tier Nolan]

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

On Tue, Aug 25, 2015 at 11:08 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Assuming a maximum of 1-year relative lock-times. But what is an
> appropriate maximum to choose? The use cases I have considered have only
> had lock times on the order of a few days to a month or so. However I would
> feel uncomfortable going less than a year for a hard maximum, and am having
> trouble thinking of any use case that would require more than a year of
> lock-time. Can anyone else think of a use case that requires >1yr relative
> lock-time?
>
>
The main advantage of relative locktime over absolute locktime is in
situations when it is not possible to determine when the clock should
start.   This inherently means lower delays.

As a workaround, you could chain transactions to extend the relative
locktime.

Transaction B has to be 360 days after transaction A and then transaction C
has to be 360 days after transaction B and C must be an input into the
final transaction.

The chain could be built up with multi-sig, like the refund transaction
system, so no one person can create an alternative chain.

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Mark Friedenbach]

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

So I've created 2 new repositories with changed rules regarding
sequencenumbers:

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

This repository inverts (un-inverts?) the sequence number. nSequence=1
means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means 1
second relative lock-height. nSequence>=0x80000000 (most significant bit
set) is not interpreted as a relative lock-time.

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

This repository not only inverts the sequence number, but also interprets
it as a fixed-point number. This allows up to 5 year relative lock times
using blocks as units, and saves 12 low-order bits for future use. Or, up
to about 2 year relative lock times using seconds as units, and saves 4
bits for future use without second-level granularity. More bits could be
recovered from time-based locktimes by choosing a higher granularity (a
soft-fork change if done correctly).

On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:

> To follow up on this, let's say that you want to be able to have up to 1
> year relative lock-times. This choice is somewhat arbitrary and what I
> would like some input on, but I'll come back to this point.
>
>  * 1 bit is necessary to enable/disable relative lock-time.
>
>  * 1 bit is necessary to indicate whether seconds vs blocks as the unit of
> measurement.
>
>  * 1 year of time with 1-second granularity requires 25 bits. However
> since blocks occur at approximately 10 minute intervals on average, having
> a relative lock-time significantly less than this interval doesn't make
> much sense. A granularity of 256 seconds would be greater than the Nyquist
> frequency and requires only 17 bits.
>
>  * 1 year of blocks with 1-block granularity requires 16 bits.
>
> So time-based relative lock time requires about 19 bits, and block-based
> relative lock-time requires about 18 bits. That leaves 13 or 14 bits for
> other uses.
>
> Assuming a maximum of 1-year relative lock-times. But what is an
> appropriate maximum to choose? The use cases I have considered have only
> had lock times on the order of a few days to a month or so. However I would
> feel uncomfortable going less than a year for a hard maximum, and am having
> trouble thinking of any use case that would require more than a year of
> lock-time. Can anyone else think of a use case that requires >1yr relative
> lock-time?
>
> TL;DR
>
> On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach <mark@friedenbach.org>
> wrote:
>
>> A power of 2 would be far more efficient here. The key question is how
>> long of a relative block time do you need? Figure out what the maximum
>> should be ( I don't know what that would be, any ideas?) and then see how
>> many bits you have left over.
>> On Aug 23, 2015 7:23 PM, "Jorge Timón" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
>>> > discussion has any thought been given to represent one block with more
>>> > than one increment?  This would leave additional space for future
>>> > signaling, or allow, for example, higher resolution numbers for a
>>> > sharechain commitement.
>>>
>>> No, I don't think anybody thought about this. I just explained this to
>>> Pieter using "for example, 10 instead of 1".
>>> He suggested 600 increments so that it is more similar to timestamps.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Btc Drak]

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

Where do we stand now on which sequencenumbers variation to use? We really
should make a decision now.

On Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> So I've created 2 new repositories with changed rules regarding
> sequencenumbers:
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers2
>
> This repository inverts (un-inverts?) the sequence number. nSequence=1
> means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means 1
> second relative lock-height. nSequence>=0x80000000 (most significant bit
> set) is not interpreted as a relative lock-time.
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers3
>
> This repository not only inverts the sequence number, but also interprets
> it as a fixed-point number. This allows up to 5 year relative lock times
> using blocks as units, and saves 12 low-order bits for future use. Or, up
> to about 2 year relative lock times using seconds as units, and saves 4
> bits for future use without second-level granularity. More bits could be
> recovered from time-based locktimes by choosing a higher granularity (a
> soft-fork change if done correctly).
>
> On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach <mark@friedenbach.org>
> wrote:
>
>> To follow up on this, let's say that you want to be able to have up to 1
>> year relative lock-times. This choice is somewhat arbitrary and what I
>> would like some input on, but I'll come back to this point.
>>
>>  * 1 bit is necessary to enable/disable relative lock-time.
>>
>>  * 1 bit is necessary to indicate whether seconds vs blocks as the unit
>> of measurement.
>>
>>  * 1 year of time with 1-second granularity requires 25 bits. However
>> since blocks occur at approximately 10 minute intervals on average, having
>> a relative lock-time significantly less than this interval doesn't make
>> much sense. A granularity of 256 seconds would be greater than the Nyquist
>> frequency and requires only 17 bits.
>>
>>  * 1 year of blocks with 1-block granularity requires 16 bits.
>>
>> So time-based relative lock time requires about 19 bits, and block-based
>> relative lock-time requires about 18 bits. That leaves 13 or 14 bits for
>> other uses.
>>
>> Assuming a maximum of 1-year relative lock-times. But what is an
>> appropriate maximum to choose? The use cases I have considered have only
>> had lock times on the order of a few days to a month or so. However I would
>> feel uncomfortable going less than a year for a hard maximum, and am having
>> trouble thinking of any use case that would require more than a year of
>> lock-time. Can anyone else think of a use case that requires >1yr relative
>> lock-time?
>>
>> TL;DR
>>
>> On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach <mark@friedenbach.org>
>> wrote:
>>
>>> A power of 2 would be far more efficient here. The key question is how
>>> long of a relative block time do you need? Figure out what the maximum
>>> should be ( I don't know what that would be, any ideas?) and then see how
>>> many bits you have left over.
>>> On Aug 23, 2015 7:23 PM, "Jorge Timón" <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>> > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
>>>> > discussion has any thought been given to represent one block with more
>>>> > than one increment?  This would leave additional space for future
>>>> > signaling, or allow, for example, higher resolution numbers for a
>>>> > sharechain commitement.
>>>>
>>>> No, I don't think anybody thought about this. I just explained this to
>>>> Pieter using "for example, 10 instead of 1".
>>>> He suggested 600 increments so that it is more similar to timestamps.
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Eric Lombrozo]

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

I'd rather replace the whole nSequence thing with an explicit relative locktime with clear semantics...but I'm not going to fight this one too much.

On September 16, 2015 6:40:06 PM EDT, Btc Drak via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>Where do we stand now on which sequencenumbers variation to use? We
>really
>should make a decision now.
>
>On Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> So I've created 2 new repositories with changed rules regarding
>> sequencenumbers:
>>
>> https://github.com/maaku/bitcoin/tree/sequencenumbers2
>>
>> This repository inverts (un-inverts?) the sequence number.
>nSequence=1
>> means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD
>means 1
>> second relative lock-height. nSequence>=0x80000000 (most significant
>bit
>> set) is not interpreted as a relative lock-time.
>>
>> https://github.com/maaku/bitcoin/tree/sequencenumbers3
>>
>> This repository not only inverts the sequence number, but also
>interprets
>> it as a fixed-point number. This allows up to 5 year relative lock
>times
>> using blocks as units, and saves 12 low-order bits for future use.
>Or, up
>> to about 2 year relative lock times using seconds as units, and saves
>4
>> bits for future use without second-level granularity. More bits could
>be
>> recovered from time-based locktimes by choosing a higher granularity
>(a
>> soft-fork change if done correctly).
>>
>> On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach
><mark@friedenbach.org>
>> wrote:
>>
>>> To follow up on this, let's say that you want to be able to have up
>to 1
>>> year relative lock-times. This choice is somewhat arbitrary and what
>I
>>> would like some input on, but I'll come back to this point.
>>>
>>>  * 1 bit is necessary to enable/disable relative lock-time.
>>>
>>>  * 1 bit is necessary to indicate whether seconds vs blocks as the
>unit
>>> of measurement.
>>>
>>>  * 1 year of time with 1-second granularity requires 25 bits.
>However
>>> since blocks occur at approximately 10 minute intervals on average,
>having
>>> a relative lock-time significantly less than this interval doesn't
>make
>>> much sense. A granularity of 256 seconds would be greater than the
>Nyquist
>>> frequency and requires only 17 bits.
>>>
>>>  * 1 year of blocks with 1-block granularity requires 16 bits.
>>>
>>> So time-based relative lock time requires about 19 bits, and
>block-based
>>> relative lock-time requires about 18 bits. That leaves 13 or 14 bits
>for
>>> other uses.
>>>
>>> Assuming a maximum of 1-year relative lock-times. But what is an
>>> appropriate maximum to choose? The use cases I have considered have
>only
>>> had lock times on the order of a few days to a month or so. However
>I would
>>> feel uncomfortable going less than a year for a hard maximum, and am
>having
>>> trouble thinking of any use case that would require more than a year
>of
>>> lock-time. Can anyone else think of a use case that requires >1yr
>relative
>>> lock-time?
>>>
>>> TL;DR
>>>
>>> On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach
><mark@friedenbach.org>
>>> wrote:
>>>
>>>> A power of 2 would be far more efficient here. The key question is
>how
>>>> long of a relative block time do you need? Figure out what the
>maximum
>>>> should be ( I don't know what that would be, any ideas?) and then
>see how
>>>> many bits you have left over.
>>>> On Aug 23, 2015 7:23 PM, "Jorge Timón" <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>> > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
>>>>> > discussion has any thought been given to represent one block
>with more
>>>>> > than one increment?  This would leave additional space for
>future
>>>>> > signaling, or allow, for example, higher resolution numbers for
>a
>>>>> > sharechain commitement.
>>>>>
>>>>> No, I don't think anybody thought about this. I just explained
>this to
>>>>> Pieter using "for example, 10 instead of 1".
>>>>> He suggested 600 increments so that it is more similar to
>timestamps.
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Mark Friedenbach]

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

Eric, that would be, I think, my sequencenumbers2 branch in which nSequence
is an explicit relative lock-time field (unless the most significant bit is
set). That has absolutely clear semantics. You should comment on #6312
where this is being discussed.

On Wed, Sep 16, 2015 at 7:23 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:

> I'd rather replace the whole nSequence thing with an explicit relative
> locktime with clear semantics...but I'm not going to fight this one too
> much.
>
>
> On September 16, 2015 6:40:06 PM EDT, Btc Drak via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Where do we stand now on which sequencenumbers variation to use? We
>> really should make a decision now.
>>
>> On Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> So I've created 2 new repositories with changed rules regarding
>>> sequencenumbers:
>>>
>>> https://github.com/maaku/bitcoin/tree/sequencenumbers2
>>>
>>> This repository inverts (un-inverts?) the sequence number. nSequence=1
>>> means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means 1
>>> second relative lock-height. nSequence>=0x80000000 (most significant bit
>>> set) is not interpreted as a relative lock-time.
>>>
>>> https://github.com/maaku/bitcoin/tree/sequencenumbers3
>>>
>>> This repository not only inverts the sequence number, but also
>>> interprets it as a fixed-point number. This allows up to 5 year relative
>>> lock times using blocks as units, and saves 12 low-order bits for future
>>> use. Or, up to about 2 year relative lock times using seconds as units, and
>>> saves 4 bits for future use without second-level granularity. More bits
>>> could be recovered from time-based locktimes by choosing a higher
>>> granularity (a soft-fork change if done correctly).
>>>
>>> On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach <mark@friedenbach.org>
>>> wrote:
>>>
>>>> To follow up on this, let's say that you want to be able to have up to
>>>> 1 year relative lock-times. This choice is somewhat arbitrary and what I
>>>> would like some input on, but I'll come back to this point.
>>>>
>>>>  * 1 bit is necessary to enable/disable relative lock-time.
>>>>
>>>>  * 1 bit is necessary to indicate whether seconds vs blocks as the unit
>>>> of measurement.
>>>>
>>>>  * 1 year of time with 1-second granularity requires 25 bits. However
>>>> since blocks occur at approximately 10 minute intervals on average, having
>>>> a relative lock-time significantly less than this interval doesn't make
>>>> much sense. A granularity of 256 seconds would be greater than the Nyquist
>>>> frequency and requires only 17 bits.
>>>>
>>>>  * 1 year of blocks with 1-block granularity requires 16 bits.
>>>>
>>>> So time-based relative lock time requires about 19 bits, and
>>>> block-based relative lock-time requires about 18 bits. That leaves 13 or 14
>>>> bits for other uses.
>>>>
>>>> Assuming a maximum of 1-year relative lock-times. But what is an
>>>> appropriate maximum to choose? The use cases I have considered have only
>>>> had lock times on the order of a few days to a month or so. However I would
>>>> feel uncomfortable going less than a year for a hard maximum, and am having
>>>> trouble thinking of any use case that would require more than a year of
>>>> lock-time. Can anyone else think of a use case that requires >1yr relative
>>>> lock-time?
>>>>
>>>> TL;DR
>>>>
>>>> On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach <mark@friedenbach.org
>>>> > wrote:
>>>>
>>>>> A power of 2 would be far more efficient here. The key question is how
>>>>> long of a relative block time do you need? Figure out what the maximum
>>>>> should be ( I don't know what that would be, any ideas?) and then see how
>>>>> many bits you have left over.
>>>>> On Aug 23, 2015 7:23 PM, "Jorge Timón" <
>>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>
>>>>>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
>>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>> > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
>>>>>> > discussion has any thought been given to represent one block with
>>>>>> more
>>>>>> > than one increment?  This would leave additional space for future
>>>>>> > signaling, or allow, for example, higher resolution numbers for a
>>>>>> > sharechain commitement.
>>>>>>
>>>>>> No, I don't think anybody thought about this. I just explained this to
>>>>>> Pieter using "for example, 10 instead of 1".
>>>>>> He suggested 600 increments so that it is more similar to timestamps.
>>>>>> _______________________________________________
>>>>>> bitcoin-dev mailing list
>>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>> ------------------------------
>>
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Rusty Russell]

Mark Friedenbach via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
writes:
> Eric, that would be, I think, my sequencenumbers2 branch in which nSequence
> is an explicit relative lock-time field (unless the most significant bit is
> set). That has absolutely clear semantics. You should comment on #6312
> where this is being discussed.

Indeed.  Simplicity wins.  We have half the number space left for the
future, too.  If people are paranoid, reserve the top *two* bits.

Thanks,
Rusty.

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[jl2012]

How many years of relative lock time do we need? It really depends why 
we need a relative lock time in the first place, what what does it offer 
in addition to CHECKLOCKTIMEVERIFY. The only case I know is when the 
confirmation taking too long, CLTV may expire before the tx is 
confirmed. For use case like this, 1 year of relative lock time is much 
more than enough, since Bitcoin is basically worthless if it takes 
months to confirm a tx with a reasonable fee.

Is there any other use case of CSV that is irreplaceable by CLTV? There 
is only one example in the BIP CSV draft.

For the timebased relative lock time, 256 seconds of granularity is more 
than enough since the block interval is 600s. Although it is not 
impossible to reduce the block interval in the future, that will be a 
hardfork anyway and we may just hardfork BIP68/CSV at the same time.



Mark Friedenbach via bitcoin-dev 於 2015-08-27 19:32 寫到:
> So I've created 2 new repositories with changed rules regarding
> sequencenumbers:
> 
> https://github.com/maaku/bitcoin/tree/sequencenumbers2 [2]
> 
> This repository inverts (un-inverts?) the sequence number. nSequence=1
> means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means
> 1 second relative lock-height. nSequence>=0x80000000 (most significant
> bit set) is not interpreted as a relative lock-time.
> 
> https://github.com/maaku/bitcoin/tree/sequencenumbers3 [3]
> 
> This repository not only inverts the sequence number, but also
> interprets it as a fixed-point number. This allows up to 5 year
> relative lock times using blocks as units, and saves 12 low-order bits
> for future use. Or, up to about 2 year relative lock times using
> seconds as units, and saves 4 bits for future use without second-level
> granularity. More bits could be recovered from time-based locktimes by
> choosing a higher granularity (a soft-fork change if done correctly).
> 
> On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach
> <mark@friedenbach.org> wrote:
> 
>> To follow up on this, let's say that you want to be able to have up
>> to 1 year relative lock-times. This choice is somewhat arbitrary and
>> what I would like some input on, but I'll come back to this point.
>> 
>> * 1 bit is necessary to enable/disable relative lock-time.
>> 
>> * 1 bit is necessary to indicate whether seconds vs blocks as the
>> unit of measurement.
>> 
>> * 1 year of time with 1-second granularity requires 25 bits.
>> However since blocks occur at approximately 10 minute intervals on
>> average, having a relative lock-time significantly less than this
>> interval doesn't make much sense. A granularity of 256 seconds would
>> be greater than the Nyquist frequency and requires only 17 bits.
>> 
>> * 1 year of blocks with 1-block granularity requires 16 bits.
>> 
>> So time-based relative lock time requires about 19 bits, and
>> block-based relative lock-time requires about 18 bits. That leaves
>> 13 or 14 bits for other uses.
>> 
>> Assuming a maximum of 1-year relative lock-times. But what is an
>> appropriate maximum to choose? The use cases I have considered have
>> only had lock times on the order of a few days to a month or so.
>> However I would feel uncomfortable going less than a year for a hard
>> maximum, and am having trouble thinking of any use case that would
>> require more than a year of lock-time. Can anyone else think of a
>> use case that requires >1yr relative lock-time?
>> 
>> TL;DR
>> 
>> On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach
>> <mark@friedenbach.org> wrote:
>> 
>> A power of 2 would be far more efficient here. The key question is
>> how long of a relative block time do you need? Figure out what the
>> maximum should be ( I don't know what that would be, any ideas?) and
>> then see how many bits you have left over.
>> 
>> On Aug 23, 2015 7:23 PM, "Jorge Timón"
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
>>> discussion has any thought been given to represent one block with
>> more
>>> than one increment? This would leave additional space for future
>>> signaling, or allow, for example, higher resolution numbers for a
>>> sharechain commitement.
>> 
>> No, I don't think anybody thought about this. I just explained this
>> to
>> Pieter using "for example, 10 instead of 1".
>> He suggested 600 increments so that it is more similar to
>> timestamps.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
> 
> 
> 
> Links:
> ------
> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> [2] https://github.com/maaku/bitcoin/tree/sequencenumbers2
> [3] https://github.com/maaku/bitcoin/tree/sequencenumbers3
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[jl2012]

Gregory Maxwell via bitcoin-dev 於 2015-08-23 21:01 寫到:

> 
> Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
> discussion has any thought been given to represent one block with more
> than one increment?  This would leave additional space for future
> signaling, or allow, for example, higher resolution numbers for a
> sharechain commitement.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

I think this comment is more related to BIP68 instead of OP_CSV? Without 
further complicating the BIP68, I believe the best way to leave room for 
improvement is to spend a bit in tx nVersion to indicate the activation 
of BIP68. I have raised this issue before with 
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html 
However, it seems Mark isn't in favor of my proposal

The idea is not to permanently change the meaning of nSequence. 
Actually, BIP68 is "only enforced if the most significant bit of the 
sequence number field is set." So BIP68 is optional, anyway. All I 
suggest is to move the flag from nSequence to nVersion. However, this 
will leave much bigger room for using nSequence for other purpose in the 
future.

AFAIK, nSequence is the only user definable and signed element in TxIn. 
There could be more interesting use of this field and we should not 
change its meaning permanently. (e.g. if nSequence had 8 bytes instead 
of 4 bytes, it could be used to indicate the value of the input to fix 
this problem: https://bitcointalk.org/index.php?topic=181734.0 )

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Mark Friedenbach]

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

Sorry this was meant for the list:

There are only 32 bits in the version field. If you're going to spend a bit
for perpetuity to indicate whether or not a feature is active, you'd better
have a good reason to make that feature optional.

I haven't seen a compelling use case for having BIP 68 be optional in that
way. As you note, BIP 68 semantics is already optional by toggling the most
significant bit, and that doesn't permanently burn a version bit.
On Aug 23, 2015 7:41 PM, "jl2012 via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[jl2012]

Your proposal also permanently burns a sequence bit. It depends on how 
we value a nSequence bit and a nVersion bit. I think there is a 
trade-off here:

1. nSequence is signed by each TxIn individually, while all TxIns must 
share the same nVersion

2. If nVersion is used to indicate the meaning of nSequence (as I 
suggested):
Pros:
It saves a nSequence bit and allows more space for redefining the 
nSequence
Cons:
It burns a nVersion bit.
All TxIns in a tx must share the same meaning for their nSequence

3. If nSequence is used to indicate the meaning of itself (as you 
suggested):
Pros:
It saves a nVersion bit
Different TxIn may have different meaning with their nSequence
Cons:
It burns a nSequence bit, thus less space for extension

I don't think there is a perfect choice. However, I still prefer my 
proposal because:

1. nSequence is signed by each TxIn individually and could be more 
interesting than nVersion.
2. If nVersion is expected to be a monotonic number, 2 bytes = 65536 
versions is enough for 65 millenniums if it ticks once per year. 4 bytes 
is an overkill. Why don't we spend a bit if there is a good reason? Most 
softforks (e.g. OP_CLTV, OP_CSV, BIP66) are not optional. These kind of 
optional new functions would not be common and should never use up the 
version bits. (or, could you suggest a better use of the tx version 
bits?)


Mark Friedenbach 於 2015-08-23 22:54 寫到:
> Sorry this was meant for the list:
> 
> There are only 32 bits in the version field. If you're going to spend
> a bit for perpetuity to indicate whether or not a feature is active,
> you'd better have a good reason to make that feature optional.
> 
> I haven't seen a compelling use case for having BIP 68 be optional in
> that way. As you note, BIP 68 semantics is already optional by
> toggling the most significant bit, and that doesn't permanently burn a
> version bit.

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Btc Drak]

This BIP has been assigned BIP112 by the BIP repository maintainer. I
have updated the pull request accordingly.

Regarding the suggestion to cannibalise version, by your own
disadvantage list, we would lose fine grained control over txins which
neuters the usefulness considerably. Also using version is also ugly
because there isn't a semantic association with what we are trying to
do, whereas, sequence is associated with transaction finality and is
thus the more appropriate and logical field to use.

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Rusty Russell]

Btc Drak via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
> This BIP has been assigned BIP112 by the BIP repository maintainer. I
> have updated the pull request accordingly.
>
> Regarding the suggestion to cannibalise version, by your own
> disadvantage list, we would lose fine grained control over txins which
> neuters the usefulness considerably. Also using version is also ugly
> because there isn't a semantic association with what we are trying to
> do, whereas, sequence is associated with transaction finality and is
> thus the more appropriate and logical field to use.

OK, having implemented lightning test code against the initial proposal,
I can give the following anecdata:

- I screwed up inversion in my initial implementation.  Please kill it.

- 256 second granularity would be be fine in deployment, but a bit
  painful for testing (I currently use 60 seconds, and "sleep 61").  64
  would work better for me, and works roughly as minutes.

- 1 year should be sufficient as a max; my current handwave is <= 1 day
  per lightning hop, max 12 hops, though we have no deployment data.

- We should immediately deploy an IsStandard() rule which insists that
  nSequence is 0xFFFFFFFF or 0, so nobody screws themselves when we
  soft fork and they had random junk in there.

Aside: I'd also like to have nLockTime apply even if nSequence !=
0xFFFFFFFF (another mistake I made).  So I'd like an IsStandard() rule
to say it nLockTime be 0 if an nSequence != 0xFFFFFFFF.  Would that
screw anyone currently?

Thanks,
Rusty.

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[David A. Harding]

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

On Thu, Aug 27, 2015 at 12:38:42PM +0930, Rusty Russell via bitcoin-dev wrote:
> So I'd like an IsStandard() rule to say it nLockTime be 0 if an
> nSequence != 0xFFFFFFFF. Would that screw anyone currently?

That sentence doesn't quite parse ("say it nLockTime"), so please
forgive me if I'm misunderstanding you. Are you saying that you want
IsStandard() to require a transaction have a locktime of 0 (no
confirmation delay) if any of its inputs use a non-final sequence?

If so, wouldn't that make locktime useless for delaying confirmation in
IsStandard() transactions because the consensus rules require at least
one input be non-final in order for locktime to have any effect?

Thanks,

-Dave

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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[jl2012]

Rusty Russell 於 2015-08-26 23:08 寫到:
> - We should immediately deploy an IsStandard() rule which insists that
>   nSequence is 0xFFFFFFFF or 0, so nobody screws themselves when we
>   soft fork and they had random junk in there.

This is not needed because BIP68 is not active for version 1 tx. No 
existing wallet would be affected.

> 
> Aside: I'd also like to have nLockTime apply even if nSequence !=
> 0xFFFFFFFF (another mistake I made).  So I'd like an IsStandard() rule
> to say it nLockTime be 0 if an nSequence != 0xFFFFFFFF.  Would that
> screw anyone currently?

Do you mean "have nLockTime apply even if nSequence = 0xFFFFFFFF"? This 
is a softfork. Should we do this together with BIP65, BIP68 and BIP112?


> Thanks,
> Rusty.

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Rusty Russell]

jl2012@xbt.hk writes:
> Rusty Russell 於 2015-08-26 23:08 寫到:
>> - We should immediately deploy an IsStandard() rule which insists that
>>   nSequence is 0xFFFFFFFF or 0, so nobody screws themselves when we
>>   soft fork and they had random junk in there.
>
> This is not needed because BIP68 is not active for version 1 tx. No 
> existing wallet would be affected.

Ah thanks!  I missed the version bump in BIP68.

>> Aside: I'd also like to have nLockTime apply even if nSequence !=
>> 0xFFFFFFFF (another mistake I made).  So I'd like an IsStandard() rule
>> to say it nLockTime be 0 if an nSequence != 0xFFFFFFFF.  Would that
>> screw anyone currently?
>
> Do you mean "have nLockTime apply even if nSequence = 0xFFFFFFFF"? This 
> is a softfork. Should we do this together with BIP65, BIP68 and BIP112?

Yes, but Mark pointed out that it has uses, so I withdraw the
suggestion.

Thanks,
Rusty.