s7r [ARCHIVE] on Nostr: š
Original date posted:2015-10-04 š Original message:-----BEGIN PGP SIGNED ...
š
Original date posted:2015-10-04
š Original message:-----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-----
Published at
2023-06-07 17:42:25Event JSON
{
"id": "8b2149083d3d822888ad04b8abfba6e3340f55e4f2c3b75ead4a4a0f13199b7d",
"pubkey": "947955301a8805054c8d6a2c9ac2abf07a7a18f4a33b0a573a277868302953b1",
"created_at": 1686159745,
"kind": 1,
"tags": [
[
"e",
"cd753793d8b3cbb49eaba9a2f4a53184f03e5acc23bc580b4ff40cab73993d1e",
"",
"root"
],
[
"e",
"137590085033f49921cd76a4a215a6d3b15b9b64b53476f952097274dcd1870a",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "š
Original date posted:2015-10-04\nš Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nHi aj,\n\nOn 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote:\n\u003e On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via\n\u003e bitcoin-dev wrote:\n\u003e\u003e So we need to make the case for two main things: 1) We have\n\u003e\u003e applications that need a relative (instead of absolute CLTV) 2)\n\u003e\u003e Additionally to RCLTV, we need to implement this via nSequence\n\u003e \n\u003e\u003e However I don't think we've done a good job showing why we need\n\u003e\u003e to implement this feature via nSequence. BIP68 describes the new\n\u003e\u003e nSequence semantics, and gives the rational for them as being a \n\u003e\u003e \"Consensus-enforced tx replacement\" mechanism, with a\n\u003e\u003e bidirectional payment channel as an example of this in action.\n\u003e\u003e However, the bidirectional payment channel concept itself can be\n\u003e\u003e easily implemented with CLTV alone.\n\u003e \n\u003e Do you mean \"with RCLTV alone\" here?\n\u003e \n\u003e RCLTV/OP_CSV is used in lightning commitment transactions to\n\u003e enforce a delay between publishing the commitment transaction, and\n\u003e spending the output -- that delay is needed so that the\n\u003e counterparty has time to prove the commitment was revoked and claim\n\u003e the outputs as a penalty.\n\u003e \n\nI partially understand - can you please provide a simple Alice and Bob\nexample here with the exact scenario? Thanks. Why is there a need to\n'delay between publishing the commitment transaction and spending the\noutput'? If the absolute CLTV script reached its maturity it means\nsomething went wrong (e.g. counterparty cheated or got hit by a bus)\nso what is with the delay time needed for proving that the commitment\nwas revoked? I assume an absolute CLTV script reaching its maturity\n(nLockTime) is the proof itself that the commitment was revoked - but\nmaybe I'm missing something obvious, sorry if this is the case.\n\n\u003e Using absolute CLTV instead would mean that once the effective\n\u003e delay a commitment transaction has decreases over time -- initially\n\u003e it will be longer than desirable, causing unwanted delays in\n\u003e claiming funds when no cheating is going on; but over time it will\n\u003e become too short, which means there is not enough time to prove\n\u003e cheating (and the channel has to be closed prematurely). You can\n\u003e trade those things off and pick something that works, but it's\n\u003e always going to be bad.\n\u003e \nI agree, I see the logic here. Absolute CLTV is not necessary inferior\nto RCLTV - there are use cases and use cases. For example, you can\navoid unnecessary waiting until the nLockTime expires if you use\nabsolute CLTV in combination with P2SH (2/2). Again, it always depends\non the use case - it might be a good solution, it might not be such a\ngood solution, but even absolute CLTV alone clearly fixes a lot of\nthings and takes smart contracts to the next level.\n\n\u003e\u003e There is a small drawback in that the initial transaction could\n\u003e\u003e be delayed, reducing the overall time the channel exists, but the\n\u003e\u003e protocol already assumes that transactions can be reliably\n\u003e\u003e confirmed within a day - significantly less than the proposed 30\n\u003e\u003e days duration of the channel.\n\u003e \n\u003e Compared to using a CLTV with 30 days duration, With RCLTV a\n\u003e channel could be available for years (ie 20x longer), but in the\n\u003e case of problems funds could be reclaimed within hours or days (ie\n\u003e 30x faster).\n\u003e \nIndeed. I for one _need_ CLTV / RCLTV in my day to day use cases, it\nwould be neat to have both, but if I can only have (for the time\nbeing) absolute CLTV so be it - it's still a lot better.\n\n\u003e But that's all about RCLTV vs CLTV, not about RCLTV vs\n\u003e nSequence/OP_CSV. ie, it needs BIP 112 (OP_CSV) but not necessarily\n\u003e BIP 68 (nSequence relative locktime), if they could be\n\u003e disentangled.\n\u003e \n\u003e You could do all that with \"\u003cn\u003e OP_CHECK_HEIGHT_DELTA_VERIFY\" that\n\u003e ignores nSequence, and directly compares the height of the current \n\u003e block versus the input tx's block (or the diff of their\n\u003e timestamps?) though, I think?\n\u003e \n\u003e I think the disadvantage is that (a) you have to look into the\n\u003e input transaction's block height when processing the script; and\n\u003e (b) you don't have an easy lookup to check whether the transaction\n\u003e can be included in the next block.\n\u003e \n\u003e You could maybe avoid (b) by using locktime though. Have \"\u003cn\u003e \n\u003e OP_CHECK_RELATIVE_LOCKTIME_VERIFY\" compare the transactions\n\u003e locktime against the input's block height or time; if the locktime\n\u003e is 0 or too low, the transaction is invalid. (So if nLockTime is in\n\u003e blockheight, you can only spend inputs with blockheight based\n\u003e OP_CRLTV tests; and if it's in blocktime, you can only spend inputs\n\u003e with blocktime based OP_CRLTV. \"n\" does need to encode whether it's\n\u003e time/block height though).\n\u003e \n\u003e That way, when you see a txn:\n\u003e \n\u003e - run the script. if you see \u003cn\u003e RCLTV, then + if the tx's locktime\n\u003e isn't set, it's invalid; drop it + if the input txn is unconfirmed,\n\u003e it's invalid; try again later + workout \"locktime - n\" if that's \u003e=\n\u003e the input tx's block height/time, it's good; keep it in mempool,\n\u003e forward it, etc\n\u003e \n\u003e - if you're mining, include the tx when locktime hits, just like\n\u003e you would any other valid tx with a locktime\n\u003e \n\u003e I think the use cases for BIP68 (nSequence) are of the form:\n\u003e \n\u003e 1) published input; here's a signed tx that spends it to you,\n\u003e usable after a delay. might as well just use absolute locktime\n\u003e here, though.\n\u003e \n\u003e 2) here's an unpublished input, you can build your own transaction\n\u003e to spend it, just not immediately after it's published. BIP112 is \n\u003e required, and OP_RCLTV as defined above works fine, just include\n\u003e it in the published input's script.\n\u003e \n\u003e 3) here's an unpublished input, and a signed transaction spending\n\u003e it, that you can use to spend it after a delay. BIP68 is enough;\n\u003e but OP_RCLTV in the second transaction works here. however without \n\u003e normalised tx ids, the input could be malleated before\n\u003e publication, so maybe this use case isn't actually important\n\u003e anyway.\n\u003e \n\u003e So I think OP_CRLTV alone works fine for them too...\n\u003e \n\u003e (Does that make sense, or am I missing something obvious?)\n\u003e \n\u003e Cheers, aj\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v2.0.22 (MingW32)\n\niQEcBAEBCAAGBQJWERXAAAoJEIN/pSyBJlsRypMH/2Q+jVRf4hWtPr9cs/06pXM9\nmKHd2OPDEJO8HjSe+cIMCxOz76EZxXglUEkK4YV/huP0Tp0bcMp6EJxsZVD9L78k\ndugyh2747ddL6aqRmt0ducTEfIC/Q4BxPA2HRQZkvyyIUQv2Tyo780bC0y8BwUpb\nj/BQjFZwk4QgqkTlf5lbCgn85alOKHki2El04iALHc27pUiDWKQPPeNOy6po6mmD\n/csvh4XOTQwCVy384ljuFBp0+QN7Z/zx4E8i6GqV2BmfNcveTG6Fc5KrHr2Ud4Th\nRD8k6n9mLaPs6ufhVkgUiUqPzQsJ+ns+mm7OEUdd645Kxqxg3Tu1u32DgdpRcHk=\n=U0N6\n-----END PGP SIGNATURE-----",
"sig": "33f0ae648db0865d9b49c8bb048e24a1496df8bf9b14cdcec289814d2a925af72a2ca9a9b2505c4e7b3b794b602c930dd7598cf0e493dfab777beef52d603f8a"
}