Discussion:
[BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
(too old to reply)
Btc Drak via bitcoin-dev
2015-08-13 11:06:44 UTC
Permalink
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 <***@gmail.com>
Mark Friedenbach <***@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.
Mark Friedenbach via bitcoin-dev
2015-08-13 18:12:43 UTC
Permalink
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 <
Post by Btc Drak via bitcoin-dev
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
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.
{
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==
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
OP_CHECKLOCKTIMEVERIFY,
Consensus-enforced transaction replacement signalled via sequence numbers,
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Gregory Maxwell via bitcoin-dev
2015-08-13 19:20:02 UTC
Permalink
Post by Mark Friedenbach via bitcoin-dev
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
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008452.html
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...
Joseph Poon via bitcoin-dev
2015-08-13 23:42:13 UTC
Permalink
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.
Post by Btc Drak via bitcoin-dev
// 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
Mark Friedenbach via bitcoin-dev
2015-08-14 00:47:17 UTC
Permalink
On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev <
Post by Joseph Poon via bitcoin-dev
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.
Matt Corallo via bitcoin-dev
2015-08-14 18:53:59 UTC
Permalink
Post by Mark Friedenbach via bitcoin-dev
On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev
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).
Post by Mark Friedenbach via bitcoin-dev
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?
Post by Mark Friedenbach via bitcoin-dev
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.
Post by Mark Friedenbach via bitcoin-dev
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?
Post by Mark Friedenbach via bitcoin-dev
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.
Mark Friedenbach via bitcoin-dev
2015-08-14 21:29:31 UTC
Permalink
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.
Post by Matt Corallo via bitcoin-dev
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...
Post by Matt Corallo via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev
I haven't tested the details of this, but is there another bit
available
Post by Mark Friedenbach via bitcoin-dev
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,
Post by Mark Friedenbach via bitcoin-dev
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).
Post by Mark Friedenbach via bitcoin-dev
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?
Post by Mark Friedenbach via bitcoin-dev
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.
Post by Mark Friedenbach via bitcoin-dev
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?
Post by Mark Friedenbach via bitcoin-dev
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.
Jorge Timón via bitcoin-dev
2015-08-14 22:24:43 UTC
Permalink
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).
Btc Drak via bitcoin-dev
2015-08-17 19:58:10 UTC
Permalink
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
Jorge Timón via bitcoin-dev
2015-08-19 10:37:33 UTC
Permalink
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
Post by Btc Drak via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Mark Friedenbach via bitcoin-dev
2015-08-19 16:21:36 UTC
Permalink
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 <
Post by Jorge Timón via bitcoin-dev
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
Post by Btc Drak via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Joseph Poon via bitcoin-dev
2015-08-19 21:27:10 UTC
Permalink
Post by Mark Friedenbach via bitcoin-dev
If anyone feels strongly about this, please speak up.
On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n <
Post by Jorge Timón via bitcoin-dev
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
Jorge Timón via bitcoin-dev
2015-08-19 21:32:57 UTC
Permalink
Post by Joseph Poon via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
If anyone feels strongly about this, please speak up.
On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n <
Post by Jorge Timón via bitcoin-dev
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.
Peter Todd via bitcoin-dev
2015-08-20 21:23:37 UTC
Permalink
Post by Joseph Poon via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
If anyone feels strongly about this, please speak up.
On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n <
Post by Jorge Timón via bitcoin-dev
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
Tom Harding via bitcoin-dev
2015-08-24 00:25:20 UTC
Permalink
ack no inversion. This can actually allow more direct preservation of
existing semantics.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html
Post by Mark Friedenbach via bitcoin-dev
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
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
Post by Btc Drak via bitcoin-dev
Please note there is now a PR for this BIP[1] and also a pull
request for
Post by Btc Drak via bitcoin-dev
the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].
[1] https://github.com/bitcoin/bips/pull/179
[2] https://github.com/bitcoin/bitcoin/pull/6564
Gregory Maxwell via bitcoin-dev
2015-08-24 01:01:26 UTC
Permalink
On Mon, Aug 24, 2015 at 12:25 AM, Tom Harding via bitcoin-dev
Post by Tom Harding via bitcoin-dev
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.
Jorge Timón via bitcoin-dev
2015-08-24 02:23:05 UTC
Permalink
On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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.
Mark Friedenbach via bitcoin-dev
2015-08-24 02:37:20 UTC
Permalink
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" <
Post by Jorge Timón via bitcoin-dev
On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Mark Friedenbach via bitcoin-dev
2015-08-25 22:08:32 UTC
Permalink
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
Post by Mark Friedenbach via bitcoin-dev
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" <
Post by Jorge Timón via bitcoin-dev
On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Tier Nolan via bitcoin-dev
2015-08-25 22:36:23 UTC
Permalink
On Tue, Aug 25, 2015 at 11:08 PM, Mark Friedenbach via bitcoin-dev <
Post by Mark Friedenbach via bitcoin-dev
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.
Mark Friedenbach via bitcoin-dev
2015-08-27 23:32:55 UTC
Permalink
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).
Post by Mark Friedenbach via bitcoin-dev
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
Post by Mark Friedenbach via bitcoin-dev
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" <
Post by Jorge Timón via bitcoin-dev
On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Btc Drak via bitcoin-dev
2015-09-16 22:40:06 UTC
Permalink
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 <
Post by Mark Friedenbach via bitcoin-dev
So I've created 2 new repositories with changed rules regarding
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).
Post by Mark Friedenbach via bitcoin-dev
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
Post by Mark Friedenbach via bitcoin-dev
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" <
Post by Jorge Timón via bitcoin-dev
On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Eric Lombrozo via bitcoin-dev
2015-09-16 23:23:18 UTC
Permalink
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.
Post by Btc Drak via bitcoin-dev
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 <
Post by Mark Friedenbach via bitcoin-dev
So I've created 2 new repositories with changed rules regarding
https://github.com/maaku/bitcoin/tree/sequencenumbers2
This repository inverts (un-inverts?) the sequence number.
nSequence=1
Post by Mark Friedenbach via bitcoin-dev
means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD
means 1
Post by Mark Friedenbach via bitcoin-dev
second relative lock-height. nSequence>=0x80000000 (most significant
bit
Post by Mark Friedenbach via bitcoin-dev
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
Post by Mark Friedenbach via bitcoin-dev
it as a fixed-point number. This allows up to 5 year relative lock
times
Post by Mark Friedenbach via bitcoin-dev
using blocks as units, and saves 12 low-order bits for future use.
Or, up
Post by Mark Friedenbach via bitcoin-dev
to about 2 year relative lock times using seconds as units, and saves
4
Post by Mark Friedenbach via bitcoin-dev
bits for future use without second-level granularity. More bits could
be
Post by Mark Friedenbach via bitcoin-dev
recovered from time-based locktimes by choosing a higher granularity
(a
Post by Mark Friedenbach via bitcoin-dev
soft-fork change if done correctly).
On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach
Post by Mark Friedenbach via bitcoin-dev
To follow up on this, let's say that you want to be able to have up
to 1
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
year relative lock-times. This choice is somewhat arbitrary and what
I
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
of measurement.
* 1 year of time with 1-second granularity requires 25 bits.
However
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
since blocks occur at approximately 10 minute intervals on average,
having
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
a relative lock-time significantly less than this interval doesn't
make
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
much sense. A granularity of 256 seconds would be greater than the
Nyquist
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
relative lock-time requires about 18 bits. That leaves 13 or 14 bits
for
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
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
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
had lock times on the order of a few days to a month or so. However
I would
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
feel uncomfortable going less than a year for a hard maximum, and am
having
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
trouble thinking of any use case that would require more than a year
of
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
lock-time. Can anyone else think of a use case that requires >1yr
relative
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
lock-time?
TL;DR
On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach
Post by Mark Friedenbach via bitcoin-dev
A power of 2 would be far more efficient here. The key question is
how
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
long of a relative block time do you need? Figure out what the
maximum
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
should be ( I don't know what that would be, any ideas?) and then
see how
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
many bits you have left over.
On Aug 23, 2015 7:23 PM, "Jorge Timón" <
Post by Jorge Timón via bitcoin-dev
On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
discussion has any thought been given to represent one block
with more
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
than one increment? This would leave additional space for
future
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
signaling, or allow, for example, higher resolution numbers for
a
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
sharechain commitement.
No, I don't think anybody thought about this. I just explained
this to
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Pieter using "for example, 10 instead of 1".
He suggested 600 increments so that it is more similar to
timestamps.
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Mark Friedenbach via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
------------------------------------------------------------------------
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Mark Friedenbach via bitcoin-dev
2015-09-17 04:23:41 UTC
Permalink
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.
Post by Eric Lombrozo via bitcoin-dev
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 <
Post by Btc Drak via bitcoin-dev
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 <
Post by Mark Friedenbach via bitcoin-dev
So I've created 2 new repositories with changed rules regarding
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).
Post by Mark Friedenbach via bitcoin-dev
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
Post by Mark Friedenbach via bitcoin-dev
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" <
Post by Jorge Timón via bitcoin-dev
On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
discussion has any thought been given to represent one block with
more
Post by Gregory Maxwell via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
------------------------------
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Rusty Russell via bitcoin-dev
2015-09-18 01:21:19 UTC
Permalink
Post by Mark Friedenbach via bitcoin-dev
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.

jl2012 via bitcoin-dev
2015-09-17 07:43:02 UTC
Permalink
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.
Post by Mark Friedenbach via bitcoin-dev
So I've created 2 new repositories with changed rules regarding
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
Post by Mark Friedenbach via bitcoin-dev
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
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"
On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
discussion has any thought been given to represent one block with
more
Post by Gregory Maxwell via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
------
[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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
jl2012 via bitcoin-dev
2015-08-24 02:40:56 UTC
Permalink
Post by Gregory Maxwell via bitcoin-dev
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
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 )
Mark Friedenbach via bitcoin-dev
2015-08-24 02:54:34 UTC
Permalink
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" <
Post by jl2012 via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
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,
https://bitcointalk.org/index.php?topic=181734.0 )
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
jl2012 via bitcoin-dev
2015-08-24 07:00:37 UTC
Permalink
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?)
Post by Mark Friedenbach via bitcoin-dev
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.
Btc Drak via bitcoin-dev
2015-08-25 10:15:35 UTC
Permalink
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.
Rusty Russell via bitcoin-dev
2015-08-27 03:08:42 UTC
Permalink
Post by Btc Drak via bitcoin-dev
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.
David A. Harding via bitcoin-dev
2015-08-27 11:03:30 UTC
Permalink
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
jl2012 via bitcoin-dev
2015-08-27 12:29:06 UTC
Permalink
Post by Rusty Russell via bitcoin-dev
- 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.
Post by Rusty Russell via bitcoin-dev
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?
Post by Rusty Russell via bitcoin-dev
Thanks,
Rusty.
Rusty Russell via bitcoin-dev
2015-08-30 21:33:57 UTC
Permalink
Post by jl2012 via bitcoin-dev
Post by Rusty Russell via bitcoin-dev
- 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.
Post by jl2012 via bitcoin-dev
Post by Rusty Russell via bitcoin-dev
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.
Loading...