Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Jorge Timón via bitcoin-dev]

On Fri, Oct 16, 2015 at 3:26 AM, Rusty Russell via bitcoin-dev
 wrote:
> ... Gavin just told me about setmocktime.  That's fast service!

Once more functions (specially consensus-critical functions) take
nTime explicitly as parameter instead of relying on the
library-unfriendly GetAdjustedTime(), then SetMockTime() will be less
necessary for testing. For example, see
https://github.com/jtimon/bitcoin/commit/88a35548518a27c7d24efe064e1bf4e5b3029578#diff-524ba4b43aa70d393ef51ab42a6d25f2L52
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Alex Morcos via bitcoin-dev]

Mark,

You seemed interested in changing BIP 68 to use 16 bits for sequence number
in both the block and time versions, making time based sequence numbers
have a resolution of 512 seconds.

I'm in favor of this approach because it leaves aside 14 bits for further
soft forks within the semantics of BIP 68.

It would be nice to know if you're planning this change, and perhaps people
can hold off on review until things are finalized.

I'd cast my "vote" against BIP 68 without this change, but am also open to
being convinced otherwise.

What are other peoples opinions on this?

On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Peter Todd  writes:
> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> >> Peter Todd via bitcoin-dev 
> >> writes:
> >> > However I don't think we've done a good job showing why we need to
> >> > implement this feature via nSequence.
> >>
> >> It could be implemented in other ways, but nSequence is the neatest and
> >> most straightforward I've seen.
> >>
> >> - I'm not aware of any other (even vague) proposal for its use?
> Enlighten?
> >
> > There's three that immediately come to mind:
> >
> > Gregory Maxwell has proposed it as a way of discouraging miners from
> > reorging chains, by including some of the low-order bits of a previous
> > block header in nSequence.
> >
> > A few people have proposed implementing proof-of-stake blocksize voting
> > with nSequence.
>
> Excellent, thanks!  It's good to have such ideas as a compass.  PoS
> voting seems like it won't be a problem in 5 bits.
>
> The "prevbits" idea would want more bits; naively 64 would be good, but
> I think there are some tricks we can use to make 32 work OK.  We would
> have to then split between nLocktime (if available) and multiple
> nSequence fields, and it would weaken it for some txs.
>
> There is one easy solution: change the BIP wording from:
>
> -For transactions with an nVersion of 2 or greater,
> +For transactions with an nVersion of 2,
>
> And on every tx bump, we decide whether to keep this scheme (mempool
> would enforce it always).
>
> Cheers,
> Rusty.
> ___
> 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

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Rusty Russell via bitcoin-dev]

Btc Drak  writes:
> Alex,
>
> I am sorry for not communicating more clearly. Mark and I discussed your
> concerns from the last meeting and he made the change. The BIP text still
> needs to be updated, but the discussed change was added to the PR, albeit
> squashed making it more non-obvious. BIP68 now explicitly uses 16 bits with
> a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK
> and SEQUENCE_LOCKTIME_GRANULARITY in the PR
> https://github.com/bitcoin/bitcoin/pull/6312.

I like it from a technical perspective.

>From a practical perspective: yuck.  There's currently no way to play
with bitcoind's perception of time, so that's a very long sleep to
blackbox test (which is what my lightning test script does).

So consider this YA feature request :)

Cheers,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Rusty Russell via bitcoin-dev]

Rusty Russell via bitcoin-dev  writes:
>>From a practical perspective: yuck.  There's currently no way to play
> with bitcoind's perception of time, so that's a very long sleep to
> blackbox test (which is what my lightning test script does).
>
> So consider this YA feature request :)
 
... Gavin just told me about setmocktime.  That's fast service!

Thanks,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Btc Drak via bitcoin-dev]

Alex,

I am sorry for not communicating more clearly. Mark and I discussed your
concerns from the last meeting and he made the change. The BIP text still
needs to be updated, but the discussed change was added to the PR, albeit
squashed making it more non-obvious. BIP68 now explicitly uses 16 bits with
a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK
and SEQUENCE_LOCKTIME_GRANULARITY in the PR
https://github.com/bitcoin/bitcoin/pull/6312.

/* If CTxIn::nSequence encodes a relative lock-time, this mask is
 * applied to extract that lock-time from the sequence field. */
static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x;

/* In order to use the same number of bits to encode roughly the
 * same wall-clock duration, and because blocks are naturally
 * limited to occur every 600s on average, the minimum granularity
 * for time-based relative lock-time is fixed at 512 seconds.
 * Converting from CTxIn::nSequence to seconds is performed by
 * multiplying by 512 = 2^9, or equivalently shifting up by
 * 9 bits. */
static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;

I am also much happier with this last tightening up of the specification
because it removes ambiguity. 512s granularity makes sense within the
context of the 10 minute block target.

Thank you for spending so much time carefully considering this BIP and
reference implementation and please let me know if there there are any
remaining nits so we can get those addressed.





On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Mark,
>
> You seemed interested in changing BIP 68 to use 16 bits for sequence
> number in both the block and time versions, making time based sequence
> numbers have a resolution of 512 seconds.
>
> I'm in favor of this approach because it leaves aside 14 bits for further
> soft forks within the semantics of BIP 68.
>
> It would be nice to know if you're planning this change, and perhaps
> people can hold off on review until things are finalized.
>
> I'd cast my "vote" against BIP 68 without this change, but am also open to
> being convinced otherwise.
>
> What are other peoples opinions on this?
>
> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Peter Todd  writes:
>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
>> >> Peter Todd via bitcoin-dev 
>> >> writes:
>> >> > However I don't think we've done a good job showing why we need to
>> >> > implement this feature via nSequence.
>> >>
>> >> It could be implemented in other ways, but nSequence is the neatest and
>> >> most straightforward I've seen.
>> >>
>> >> - I'm not aware of any other (even vague) proposal for its use?
>> Enlighten?
>> >
>> > There's three that immediately come to mind:
>> >
>> > Gregory Maxwell has proposed it as a way of discouraging miners from
>> > reorging chains, by including some of the low-order bits of a previous
>> > block header in nSequence.
>> >
>> > A few people have proposed implementing proof-of-stake blocksize voting
>> > with nSequence.
>>
>> Excellent, thanks!  It's good to have such ideas as a compass.  PoS
>> voting seems like it won't be a problem in 5 bits.
>>
>> The "prevbits" idea would want more bits; naively 64 would be good, but
>> I think there are some tricks we can use to make 32 work OK.  We would
>> have to then split between nLocktime (if available) and multiple
>> nSequence fields, and it would weaken it for some txs.
>>
>> There is one easy solution: change the BIP wording from:
>>
>> -For transactions with an nVersion of 2 or greater,
>> +For transactions with an nVersion of 2,
>>
>> And on every tx bump, we decide whether to keep this scheme (mempool
>> would enforce it always).
>>
>> Cheers,
>> Rusty.
>> ___
>> 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

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Mark Friedenbach via bitcoin-dev]

Adam, there is really no justification I can see to lower the interblock
interval on the Bitcoin blockchain, primarily due to the effects of network
latency. Lowering the interblock interval and raising the block size are
not equal alternatives - you can always get more throughput in bitcoin by
raising the block size than by lowering the interblock time. And that's
without considering the effect shorter intervals would have on e.g. SPV
client bandwidth or sidechain connectivity proofs. So I find it very
unlikely that such granularity would ever be needed on the Bitcoin block
chain, although if were to happen then extra bits from nSequence could be
used in a soft-fork compatible way.

However it is true that various sidechains such as Liquid will have a much
shorter interblock interval than 10min, as well as customer demand for
protocols with shorter timeouts. It would be nice if such systems did not
HAVE to resort to complex bit shifting to support more precision, and if
protocols written for bitcoin could be reused on such systems with minimal
or no modification.

To that end, it might be preferable to move the flag bit indicating use of
seconds from bit 16 to bit 23 and (by convention only) reserve bits 17..22
to provide higher granularity in a sidechain environment. This keeps the
size of a stack push to 3 bytes while also keeping sufficient room for
high-order bits of relative lock-time in a sidechain that supports shorter
block intervals.

Another alternative is to put the units flag in the least significant bit,
which has the advantage of allowing both units of lock-time to make use of
1-2 byte pushes, but the disadvantage of making lock times of 64..127
2-bytes instead of 1-byte.

Thoughts?

On Thu, Oct 15, 2015 at 9:37 AM, Adam Back via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Does that pre-judge that block interval would never change from
> 10mins?  Eg say with IBLT or fountain codes etc and security arguments
> for the current limitations of them are found, such that orphan rates
> can remain low in a decentralised way with 1min blocks, then the
> locktime granularity would be coarse relative to the block interval
> (with 512s locktime granularity.
>
> Adam
>
> On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev
>  wrote:
> > Alex,
> >
> > I am sorry for not communicating more clearly. Mark and I discussed your
> > concerns from the last meeting and he made the change. The BIP text still
> > needs to be updated, but the discussed change was added to the PR, albeit
> > squashed making it more non-obvious. BIP68 now explicitly uses 16 bits
> with
> > a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and
> > SEQUENCE_LOCKTIME_GRANULARITY in the PR
> > https://github.com/bitcoin/bitcoin/pull/6312.
> >
> > /* If CTxIn::nSequence encodes a relative lock-time, this mask is
> >  * applied to extract that lock-time from the sequence field. */
> > static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x;
> >
> > /* In order to use the same number of bits to encode roughly the
> >  * same wall-clock duration, and because blocks are naturally
> >  * limited to occur every 600s on average, the minimum granularity
> >  * for time-based relative lock-time is fixed at 512 seconds.
> >  * Converting from CTxIn::nSequence to seconds is performed by
> >  * multiplying by 512 = 2^9, or equivalently shifting up by
> >  * 9 bits. */
> > static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
> >
> > I am also much happier with this last tightening up of the specification
> > because it removes ambiguity. 512s granularity makes sense within the
> > context of the 10 minute block target.
> >
> > Thank you for spending so much time carefully considering this BIP and
> > reference implementation and please let me know if there there are any
> > remaining nits so we can get those addressed.
> >
> >
> >
> >
> >
> > On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev
> >  wrote:
> >>
> >> Mark,
> >>
> >> You seemed interested in changing BIP 68 to use 16 bits for sequence
> >> number in both the block and time versions, making time based sequence
> >> numbers have a resolution of 512 seconds.
> >>
> >> I'm in favor of this approach because it leaves aside 14 bits for
> further
> >> soft forks within the semantics of BIP 68.
> >>
> >> It would be nice to know if you're planning this change, and perhaps
> >> people can hold off on review until things are finalized.
> >>
> >> I'd cast my "vote" against BIP 68 without this change, but am also open
> to
> >> being convinced otherwise.
> >>
> >> What are other peoples opinions on this?
> >>
> >> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev
> >>  wrote:
> >>>
> >>> Peter Todd  writes:
> >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell 

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Peter Todd via bitcoin-dev]

On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote:
> BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics,


Another issue that came to mind re: CSV review is that there isn't
actually any one pull-req with all the code changes together, making it
hard to be sure what the final effect will be once all three BIPs are
merged.

While evaluating stuff separately is often good, I think this is a case
where the overall design needs to be evaluated as a single unit to fully
understand the behavior.

-- 
'peter'[:-1]@petertodd.org
0de60f807a5fd32057510e7715038ecbc888052861b6a5c1


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Peter Todd via bitcoin-dev]

On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> Peter Todd via bitcoin-dev 
> writes:
> > However I don't think we've done a good job showing why we need to
> > implement this feature via nSequence.
> 
> It could be implemented in other ways, but nSequence is the neatest and
> most straightforward I've seen.
> 
> - I'm not aware of any other (even vague) proposal for its use?  Enlighten?

There's three that immediately come to mind:

Gregory Maxwell has proposed it as a way of discouraging miners from
reorging chains, by including some of the low-order bits of a previous
block header in nSequence.

A few people have proposed implementing proof-of-stake blocksize voting
with nSequence.

> - BIP68 reserves much of it for future use already.

Well, a few low-order bits, if you want to use RCLTV functionality; pure
RCLTV would save a lot more bits.

> If we apply infinite caution we could never use nSequence, as there
> might be a better use tommorrow.

Indeed! But lets make sure we have a good argument in the BIP.

-- 
'peter'[:-1]@petertodd.org
0de60f807a5fd32057510e7715038ecbc888052861b6a5c1


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Joseph Poon via bitcoin-dev]

Hi Peter,

On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote:
> So we need to make the case for two main things:
> 
> 1) We have applications that need a relative (instead of absolute CLTV)

Lightning network needs RCLTV for bidireciontal payment channels without
an explicit expiration date. Without a relative locktime, there is an
economic tradeoff between longer channel expiry dates due to lower fees,
and the time-value delay for non-cooperation. Due to this tradeoff,
there is a risk that people may create channels with entities which they
believe will be around in the future and act in a particular way. In
other words, it is possible that people will attach reputation as part
of their decision-making for channel creation.

> 2) Additionally to RCLTV, we need to implement this via nSequence
> 
> However I don't think we've done a good job showing why we need to
> implement this feature via nSequence. BIP68 describes the new nSequence
> semantics, and gives the rational for them as being a
> "Consensus-enforced tx replacement" mechanism, with a bidirectional
> payment channel as an example of this in action. However, the
> bidirectional payment channel concept itself can be easily implemented
> with CLTV alone. There is a small drawback in that the initial
> transaction could be delayed, reducing the overall time the channel
> exists, but the protocol already assumes that transactions can be
> reliably confirmed within a day - significantly less than the proposed
> 30 days duration of the channel. That example alone I don't think
> justifies a fairly complex soft-fork that limits future upgrades; we
> need more justification.

The examples (including for Lightning Network) in BIP 112 provides a
rationale for using a relative locktime which cannot be achieved using
CLTV/hard-nLocktime alone. Without BIP 112, I agree the example in BIP
68 can also be done with nLocktime, but I think they sort of go
together?

However, there are some advantages to using some kind of relative
locktime field such as nSequence over purely a script opcode. This is
especially useful if one presumes some kind of long-term malleability
fix which does not include directly signing the TXID of the parent
transaction. It allows one to update dependent spending transactions
after-the-fact; after transactions are signed. If there are
unbroadcasted 2-of-2 multisig output transactions, where Tx1 is
confirmed on-chain and off-chain Tx2 spends from Tx1, they can elect to
spend Tx3a from the output of Tx2. Tx3a can have an nSequence value
which requires a minimum of 100 block confirmations of Tx2 to elapse
before Tx3a can be broadcast. As neither Tx2 or Tx3a have yet broadcast,
they can elect to double-spend Tx2 with a new transaction with a lower
nSequence value, e.g. Tx3b. This is important, as Tx2 will *always* be
spendable so creating new revocation rules is useful for Tx2.

I think Mark had once described the general idea is to have a similar
separation of the opcode and the actual validation of block height in
the codebase as nLockTime/OP_CLTV, as having pure validation in the
script which may make things a bit ugly.

> So, what else can the community come up with? nSequence itself exists
> because of a failed feature that turned out to not work as intended;
> it'd be a shame to make that kind of mistake again, so let's get our
> semantics and use-cases in the BIPs and documented before we deploy.

I agree. There may be some impact for future changes in Bitcoin, wrt BIP
68. For BIP 112, I think the impact could be minimal, but there may be
future interpretations of nSequence. In particular, in the long term
there may be some kind of need for some kind of "timestop" bit (to
define whether to count relative blockheight or timestopped
blockheight), which already consumes unreserved space. To account for
more than one upgrade, the next future upgrade after BIP 68 may be
implemented by taking the unused most significant bit in nSequence as
defined in BIP 68 in combination with using up a version field bit.
jl1202 had previously suggested doing this for BIP 68 itself:
e7b394187fd96bd77a1c49f7c9b7a...@xbt.hk
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011358.html

As-is, the only actual tradeoff made by BIP 68 is reducing range by
half. I think BIP 68 works as-is or with burning an nVersion bit today,
as it should allow for future (necessary) upgrades.

-- 
Joseph Poon
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Rusty Russell via bitcoin-dev]

Peter Todd via bitcoin-dev 
writes:
> However I don't think we've done a good job showing why we need to
> implement this feature via nSequence.

It could be implemented in other ways, but nSequence is the neatest and
most straightforward I've seen.

- I'm not aware of any other (even vague) proposal for its use?  Enlighten?
- BIP68 reserves much of it for future use already.

If we apply infinite caution we could never use nSequence, as there
might be a better use tommorrow.

Cheers,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Alex Morcos via bitcoin-dev]

Peter,

Your concern about whether this is the best way to use the nSequence field;
would that be addressed by providing more high order bits to signal
different uses of the field?  At a certain point we're really not limiting
the future at all and there is something to be said for not letting the
perfect be the enemy of the good.  I think it would be nice to make forward
progress on BIPS 68,112, and 113 and move towards getting them finalized
and implemented.  (Although I do suspect they aren't quite ready to go out
with CLTV)

What is the reasoning for having single second resolution on the time based
sequence number locks?  Might it not make some sense to reduce that
resolution and leave more low order bits as well?

Alex

On Sun, Oct 4, 2015 at 8:04 AM, s7r via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi aj,
>
> On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote:
> > On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via
> > bitcoin-dev wrote:
> >> So we need to make the case for two main things: 1) We have
> >> applications that need a relative (instead of absolute CLTV) 2)
> >> Additionally to RCLTV, we need to implement this via nSequence
> >
> >> However I don't think we've done a good job showing why we need
> >> to implement this feature via nSequence. BIP68 describes the new
> >> nSequence semantics, and gives the rational for them as being a
> >> "Consensus-enforced tx replacement" mechanism, with a
> >> bidirectional payment channel as an example of this in action.
> >> However, the bidirectional payment channel concept itself can be
> >> easily implemented with CLTV alone.
> >
> > Do you mean "with RCLTV alone" here?
> >
> > RCLTV/OP_CSV is used in lightning commitment transactions to
> > enforce a delay between publishing the commitment transaction, and
> > spending the output -- that delay is needed so that the
> > counterparty has time to prove the commitment was revoked and claim
> > the outputs as a penalty.
> >
>
> I partially understand - can you please provide a simple Alice and Bob
> example here with the exact scenario? Thanks. Why is there a need to
> 'delay between publishing the commitment transaction and spending the
> output'? If the absolute CLTV script reached its maturity it means
> something went wrong (e.g. counterparty cheated or got hit by a bus)
> so what is with the delay time needed for proving that the commitment
> was revoked? I assume an absolute CLTV script reaching its maturity
> (nLockTime) is the proof itself that the commitment was revoked - but
> maybe I'm missing something obvious, sorry if this is the case.
>
> > Using absolute CLTV instead would mean that once the effective
> > delay a commitment transaction has decreases over time -- initially
> > it will be longer than desirable, causing unwanted delays in
> > claiming funds when no cheating is going on; but over time it will
> > become too short, which means there is not enough time to prove
> > cheating (and the channel has to be closed prematurely). You can
> > trade those things off and pick something that works, but it's
> > always going to be bad.
> >
> I agree, I see the logic here. Absolute CLTV is not necessary inferior
> to RCLTV - there are use cases and use cases. For example, you can
> avoid unnecessary waiting until the nLockTime expires if you use
> absolute CLTV in combination with P2SH (2/2). Again, it always depends
> on the use case - it might be a good solution, it might not be such a
> good solution, but even absolute CLTV alone clearly fixes a lot of
> things and takes smart contracts to the next level.
>
> >> There is a small drawback in that the initial transaction could
> >> be delayed, reducing the overall time the channel exists, but the
> >> protocol already assumes that transactions can be reliably
> >> confirmed within a day - significantly less than the proposed 30
> >> days duration of the channel.
> >
> > Compared to using a CLTV with 30 days duration, With RCLTV a
> > channel could be available for years (ie 20x longer), but in the
> > case of problems funds could be reclaimed within hours or days (ie
> > 30x faster).
> >
> Indeed. I for one _need_ CLTV / RCLTV in my day to day use cases, it
> would be neat to have both, but if I can only have (for the time
> being) absolute CLTV so be it - it's still a lot better.
>
> > But that's all about RCLTV vs CLTV, not about RCLTV vs
> > nSequence/OP_CSV. ie, it needs BIP 112 (OP_CSV) but not necessarily
> > BIP 68 (nSequence relative locktime), if they could be
> > disentangled.
> >
> > You could do all that with " OP_CHECK_HEIGHT_DELTA_VERIFY" that
> > ignores nSequence, and directly compares the height of the current
> > block versus the input tx's block (or the diff of their
> > timestamps?) though, I think?
> >
> > I think the disadvantage is that (a) you have to look into the
> > input transaction's block height when processing the 

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Mark Friedenbach via bitcoin-dev]

Alex, decreasing granularity is a soft-fork, increasing is a hard-fork.
Therefore I've kept the highest possible precision (1 second, 1 block) with
the expectation that at some point in the future if we need more low-order
bits we can soft-fork them to other purposes, we can decrease granularity
at that time.

On Mon, Oct 5, 2015 at 3:03 PM, Alex Morcos via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Peter,
>
> Your concern about whether this is the best way to use the nSequence
> field; would that be addressed by providing more high order bits to signal
> different uses of the field?  At a certain point we're really not limiting
> the future at all and there is something to be said for not letting the
> perfect be the enemy of the good.  I think it would be nice to make forward
> progress on BIPS 68,112, and 113 and move towards getting them finalized
> and implemented.  (Although I do suspect they aren't quite ready to go out
> with CLTV)
>
> What is the reasoning for having single second resolution on the time
> based sequence number locks?  Might it not make some sense to reduce that
> resolution and leave more low order bits as well?
>
> Alex
>
> On Sun, Oct 4, 2015 at 8:04 AM, s7r via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Hi aj,
>>
>> On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote:
>> > On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via
>> > bitcoin-dev wrote:
>> >> So we need to make the case for two main things: 1) We have
>> >> applications that need a relative (instead of absolute CLTV) 2)
>> >> Additionally to RCLTV, we need to implement this via nSequence
>> >
>> >> However I don't think we've done a good job showing why we need
>> >> to implement this feature via nSequence. BIP68 describes the new
>> >> nSequence semantics, and gives the rational for them as being a
>> >> "Consensus-enforced tx replacement" mechanism, with a
>> >> bidirectional payment channel as an example of this in action.
>> >> However, the bidirectional payment channel concept itself can be
>> >> easily implemented with CLTV alone.
>> >
>> > Do you mean "with RCLTV alone" here?
>> >
>> > RCLTV/OP_CSV is used in lightning commitment transactions to
>> > enforce a delay between publishing the commitment transaction, and
>> > spending the output -- that delay is needed so that the
>> > counterparty has time to prove the commitment was revoked and claim
>> > the outputs as a penalty.
>> >
>>
>> I partially understand - can you please provide a simple Alice and Bob
>> example here with the exact scenario? Thanks. Why is there a need to
>> 'delay between publishing the commitment transaction and spending the
>> output'? If the absolute CLTV script reached its maturity it means
>> something went wrong (e.g. counterparty cheated or got hit by a bus)
>> so what is with the delay time needed for proving that the commitment
>> was revoked? I assume an absolute CLTV script reaching its maturity
>> (nLockTime) is the proof itself that the commitment was revoked - but
>> maybe I'm missing something obvious, sorry if this is the case.
>>
>> > Using absolute CLTV instead would mean that once the effective
>> > delay a commitment transaction has decreases over time -- initially
>> > it will be longer than desirable, causing unwanted delays in
>> > claiming funds when no cheating is going on; but over time it will
>> > become too short, which means there is not enough time to prove
>> > cheating (and the channel has to be closed prematurely). You can
>> > trade those things off and pick something that works, but it's
>> > always going to be bad.
>> >
>> I agree, I see the logic here. Absolute CLTV is not necessary inferior
>> to RCLTV - there are use cases and use cases. For example, you can
>> avoid unnecessary waiting until the nLockTime expires if you use
>> absolute CLTV in combination with P2SH (2/2). Again, it always depends
>> on the use case - it might be a good solution, it might not be such a
>> good solution, but even absolute CLTV alone clearly fixes a lot of
>> things and takes smart contracts to the next level.
>>
>> >> There is a small drawback in that the initial transaction could
>> >> be delayed, reducing the overall time the channel exists, but the
>> >> protocol already assumes that transactions can be reliably
>> >> confirmed within a day - significantly less than the proposed 30
>> >> days duration of the channel.
>> >
>> > Compared to using a CLTV with 30 days duration, With RCLTV a
>> > channel could be available for years (ie 20x longer), but in the
>> > case of problems funds could be reclaimed within hours or days (ie
>> > 30x faster).
>> >
>> Indeed. I for one _need_ CLTV / RCLTV in my day to day use cases, it
>> would be neat to have both, but if I can only have (for the time
>> being) absolute CLTV so be it - it's still a lot better.
>>
>> > But that's all about RCLTV vs CLTV, not about 

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Btc Drak via bitcoin-dev]

Regarding the keeping nSequence for future expansion I believe this has
been covered in the specification section of BIP68[1]: For transaction
version >= 2, if the MSB of nSequence is unset, the field is interpreted as
relative locktime, otherwise no special consensus meaning is attached (and
thus free for repurposing in the future). Effectively if the MSB is set,
the remaining 31 bits (out of 32) are free.

Also please note the BIP112 text has been updated with several more
usecases.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Anthony Towns via bitcoin-dev]

On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote:
> So we need to make the case for two main things:
> 1) We have applications that need a relative (instead of absolute CLTV)
> 2) Additionally to RCLTV, we need to implement this via nSequence

> However I don't think we've done a good job showing why we need to
> implement this feature via nSequence. BIP68 describes the new nSequence
> semantics, and gives the rational for them as being a
> "Consensus-enforced tx replacement" mechanism, with a bidirectional
> payment channel as an example of this in action. However, the
> bidirectional payment channel concept itself can be easily implemented
> with CLTV alone.

Do you mean "with RCLTV alone" here?

RCLTV/OP_CSV is used in lightning commitment transactions to enforce a
delay between publishing the commitment transaction, and spending the
output -- that delay is needed so that the counterparty has time to
prove the commitment was revoked and claim the outputs as a penalty.

Using absolute CLTV instead would mean that once the effective delay a
commitment transaction has decreases over time -- initially it will be
longer than desirable, causing unwanted delays in claiming funds when no
cheating is going on; but over time it will become too short, which
means there is not enough time to prove cheating (and the channel has to
be closed prematurely). You can trade those things off and pick
something that works, but it's always going to be bad.

> There is a small drawback in that the initial
> transaction could be delayed, reducing the overall time the channel
> exists, but the protocol already assumes that transactions can be
> reliably confirmed within a day - significantly less than the proposed
> 30 days duration of the channel.

Compared to using a CLTV with 30 days duration, With RCLTV a channel
could be available for years (ie 20x longer), but in the case of problems
funds could be reclaimed within hours or days (ie 30x faster).

But that's all about RCLTV vs CLTV, not about RCLTV vs nSequence/OP_CSV.
ie, it needs BIP 112 (OP_CSV) but not necessarily BIP 68 (nSequence
relative locktime), if they could be disentangled.

You could do all that with " OP_CHECK_HEIGHT_DELTA_VERIFY"
that ignores nSequence, and directly compares the height of the current
block versus the input tx's block (or the diff of their timestamps?)
though, I think?

I think the disadvantage is that (a) you have to look into the input
transaction's block height when processing the script; and (b) you don't
have an easy lookup to check whether the transaction can be included in
the next block.

You could maybe avoid (b) by using locktime though. Have "
OP_CHECK_RELATIVE_LOCKTIME_VERIFY" compare the transactions locktime
against the input's block height or time; if the locktime is 0 or too low,
the transaction is invalid. (So if nLockTime is in blockheight, you can
only spend inputs with blockheight based OP_CRLTV tests; and if it's in
blocktime, you can only spend inputs with blocktime based OP_CRLTV. "n"
does need to encode whether it's time/block height though).

That way, when you see a txn:

 - run the script. if you see  RCLTV, then
+ if the tx's locktime isn't set, it's invalid; drop it
+ if the input txn is unconfirmed, it's invalid; try again later
+ workout "locktime - n" if that's >= the input tx's block
  height/time, it's good; keep it in mempool, forward it, etc

 - if you're mining, include the tx when locktime hits, just like you
   would any other valid tx with a locktime

I think the use cases for BIP68 (nSequence) are of the form:

 1) published input; here's a signed tx that spends it to you, usable
after a delay. might as well just use absolute locktime here, though.

 2) here's an unpublished input, you can build your own transaction to
spend it, just not immediately after it's published. BIP112 is
required, and OP_RCLTV as defined above works fine, just include it
in the published input's script.

 3) here's an unpublished input, and a signed transaction spending it,
that you can use to spend it after a delay. BIP68 is enough; but
OP_RCLTV in the second transaction works here. however without
normalised tx ids, the input could be malleated before publication,
so maybe this use case isn't actually important anyway.

So I think OP_CRLTV alone works fine for them too...

(Does that make sense, or am I missing something obvious?)

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[s7r via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi aj,

On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote:
> On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via
> bitcoin-dev wrote:
>> So we need to make the case for two main things: 1) We have
>> applications that need a relative (instead of absolute CLTV) 2)
>> Additionally to RCLTV, we need to implement this via nSequence
> 
>> However I don't think we've done a good job showing why we need
>> to implement this feature via nSequence. BIP68 describes the new
>> nSequence semantics, and gives the rational for them as being a 
>> "Consensus-enforced tx replacement" mechanism, with a
>> bidirectional payment channel as an example of this in action.
>> However, the bidirectional payment channel concept itself can be
>> easily implemented with CLTV alone.
> 
> Do you mean "with RCLTV alone" here?
> 
> RCLTV/OP_CSV is used in lightning commitment transactions to
> enforce a delay between publishing the commitment transaction, and
> spending the output -- that delay is needed so that the
> counterparty has time to prove the commitment was revoked and claim
> the outputs as a penalty.
> 

I partially understand - can you please provide a simple Alice and Bob
example here with the exact scenario? Thanks. Why is there a need to
'delay between publishing the commitment transaction and spending the
output'? If the absolute CLTV script reached its maturity it means
something went wrong (e.g. counterparty cheated or got hit by a bus)
so what is with the delay time needed for proving that the commitment
was revoked? I assume an absolute CLTV script reaching its maturity
(nLockTime) is the proof itself that the commitment was revoked - but
maybe I'm missing something obvious, sorry if this is the case.

> Using absolute CLTV instead would mean that once the effective
> delay a commitment transaction has decreases over time -- initially
> it will be longer than desirable, causing unwanted delays in
> claiming funds when no cheating is going on; but over time it will
> become too short, which means there is not enough time to prove
> cheating (and the channel has to be closed prematurely). You can
> trade those things off and pick something that works, but it's
> always going to be bad.
> 
I agree, I see the logic here. Absolute CLTV is not necessary inferior
to RCLTV - there are use cases and use cases. For example, you can
avoid unnecessary waiting until the nLockTime expires if you use
absolute CLTV in combination with P2SH (2/2). Again, it always depends
on the use case - it might be a good solution, it might not be such a
good solution, but even absolute CLTV alone clearly fixes a lot of
things and takes smart contracts to the next level.

>> There is a small drawback in that the initial transaction could
>> be delayed, reducing the overall time the channel exists, but the
>> protocol already assumes that transactions can be reliably
>> confirmed within a day - significantly less than the proposed 30
>> days duration of the channel.
> 
> Compared to using a CLTV with 30 days duration, With RCLTV a
> channel could be available for years (ie 20x longer), but in the
> case of problems funds could be reclaimed within hours or days (ie
> 30x faster).
> 
Indeed. I for one _need_ CLTV / RCLTV in my day to day use cases, it
would be neat to have both, but if I can only have (for the time
being) absolute CLTV so be it - it's still a lot better.

> But that's all about RCLTV vs CLTV, not about RCLTV vs
> nSequence/OP_CSV. ie, it needs BIP 112 (OP_CSV) but not necessarily
> BIP 68 (nSequence relative locktime), if they could be
> disentangled.
> 
> You could do all that with " OP_CHECK_HEIGHT_DELTA_VERIFY" that
> ignores nSequence, and directly compares the height of the current 
> block versus the input tx's block (or the diff of their
> timestamps?) though, I think?
> 
> I think the disadvantage is that (a) you have to look into the
> input transaction's block height when processing the script; and
> (b) you don't have an easy lookup to check whether the transaction
> can be included in the next block.
> 
> You could maybe avoid (b) by using locktime though. Have " 
> OP_CHECK_RELATIVE_LOCKTIME_VERIFY" compare the transactions
> locktime against the input's block height or time; if the locktime
> is 0 or too low, the transaction is invalid. (So if nLockTime is in
> blockheight, you can only spend inputs with blockheight based
> OP_CRLTV tests; and if it's in blocktime, you can only spend inputs
> with blocktime based OP_CRLTV. "n" does need to encode whether it's
> time/block height though).
> 
> That way, when you see a txn:
> 
> - run the script. if you see  RCLTV, then + if the tx's locktime
> isn't set, it's invalid; drop it + if the input txn is unconfirmed,
> it's invalid; try again later + workout "locktime - n" if that's >=
> the input tx's block height/time, it's good; keep it in mempool,
> forward it, etc
> 
> - if you're mining, include the tx when 

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[jl2012 via bitcoin-dev]

BIP68 allows per-input locktime, though I don't know how this could be 
useful.


BIP68 and BIP112 are mostly ready. If we try to reimplement 
relative-locktime without using nSequence, we may need to wait for 
another year for deployment.


A compromise is to make BIP68 optional, indicated by a bit in tx 
nVersion, as I suggested earlier (1). This will allow deploying 
relative-locktime without further delay while not permanently limiting 
future upgrades.


(1) 
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html


Peter Todd via bitcoin-dev 於 2015-10-03 10:30 寫到:

BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics,
which can be summarized conceptually as a relative CHECKLOCKTIMEVERIFY.
However, CSV does define behavior for the previously undefined 
nSequence

field, which is the only "free-form" field we currently have in the
transaction serialization format that can be used for future upgrades -
we should justify this new behavior carefully as it limits our options
in the future. Adding new fields to the serialization format is very
difficult, due to the very broad system-wide impact of the hard-fork
required to do so.

So we need to make the case for two main things:

1) We have applications that need a relative (instead of absolute CLTV)

2) Additionally to RCLTV, we need to implement this via nSequence

To show we need RCLTV BIP112 provides the example "Escrow with 
Timeout",

which is a need that was brought up by GreenAddress, among others; I
don't think we have an issue there, though getting more examples would
be a good thing. (the CLTV BIP describes seven use cases, and one
additional future use-case)

However I don't think we've done a good job showing why we need to
implement this feature via nSequence. BIP68 describes the new nSequence
semantics, and gives the rational for them as being a
"Consensus-enforced tx replacement" mechanism, with a bidirectional
payment channel as an example of this in action. However, the
bidirectional payment channel concept itself can be easily implemented
with CLTV alone. There is a small drawback in that the initial
transaction could be delayed, reducing the overall time the channel
exists, but the protocol already assumes that transactions can be
reliably confirmed within a day - significantly less than the proposed
30 days duration of the channel. That example alone I don't think
justifies a fairly complex soft-fork that limits future upgrades; we
need more justification.

So, what else can the community come up with? nSequence itself exists
because of a failed feature that turned out to not work as intended;
it'd be a shame to make that kind of mistake again, so let's get our
semantics and use-cases in the BIPs and documented before we deploy.

___
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