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 " 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 >> -----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 > >