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 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 "<n> 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 "<n>
>> > 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 <n> 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
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.22 (MingW32)
>>
>> iQEcBAEBCAAGBQJWERXAAAoJEIN/pSyBJlsRypMH/2Q+jVRf4hWtPr9cs/06pXM9
>> mKHd2OPDEJO8HjSe+cIMCxOz76EZxXglUEkK4YV/huP0Tp0bcMp6EJxsZVD9L78k
>> dugyh2747ddL6aqRmt0ducTEfIC/Q4BxPA2HRQZkvyyIUQv2Tyo780bC0y8BwUpb
>> j/BQjFZwk4QgqkTlf5lbCgn85alOKHki2El04iALHc27pUiDWKQPPeNOy6po6mmD
>> /csvh4XOTQwCVy384ljuFBp0+QN7Z/zx4E8i6GqV2BmfNcveTG6Fc5KrHr2Ud4Th
>> RD8k6n9mLaPs6ufhVkgUiUqPzQsJ+ns+mm7OEUdd645Kxqxg3Tu1u32DgdpRcHk=
>> =U0N6
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> 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

Reply via email to