š
Original date posted:2022-08-20
š Original message:Good morning Greg,
> Hi James,
> Could you elaborate on a L2 contract where speedy
> settlement of the "first part" can be done, while having the rest
> take their time? I'm more thinking about time-out based protocols.
>
> Naturally my mind drifts to LN, where getting the proper commitment
> transaction confirmed in a timely fashion is required to get the proper
> balances back. The one hitch is that for HTLCs you still need speedy
> resolution otherwise theft can occur. And given today's "layered
> commitment" style transaction where HTLCs are decoupled from
> the balance output timeouts, I'm not sure this can save much.
As I understand it, layered commitments can be modified to use `OP_CTV`, which would be slightly smaller (need only to reveal a 32-byte `OP_CTV` hash on the witness instead of a 64-byte Taproot signature, or 73-byte classical pre-Taproot ECDSA signature), and is in fact precisely an example of the speedy settlement style.
> CTV style commitments have popped up in a couple places in my
> work on eltoo(emulated via APO sig-in-script), but mostly in the
> context of reducing interactivity in protocols, not in byte savings per se.
In many offchain cases, all channel participants would agree to some pre-determined set of UTXOs, which would be implemented as a transaction spending some single UTXO and outputting the pre-determined set of UTXOs.
The single UTXO can be an n-of-n of all participants, so that all agree by contributing their signatures:
* Assuming Taproot, the output address itself is 33 bytes (x4 weight).
* The n-of-n multisignature is 64 witness bytes (x1 weight).
Alternatly the single UTXO can be a P2WSH that reveals an `OP_CTV`:
* The P2WSH is 33 bytes (x4 weight) --- no savings here.
* The revelation of the `<hash> OP_CTV` is 33 witness bytes (x1 weight).
Thus, as I understand it, `OP_CTV` can (almost?) always translate to a small weight reduction for such "everyone agrees to this set of UTXOs" for all offchain protocols that would require it.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-07 23:12:54
in reply to nevent1qā¦vf8k
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-07 23:12:54Event JSON
{
"id": "187b5ddbd34e67c8972d0fa781b0523b292f8eeeaf96a500e48678e210e093d4",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686179574,
"kind": 1,
"tags": [
[
"e",
"fdc159e582b3535b43a6295520af31a5cc21e5962eb9d0ba42b0a051180ff466",
"",
"root"
],
[
"e",
"2db51ba8f3687bff4f10033100550583721194da7acd61bf1691f99022015bed",
"",
"reply"
],
[
"p",
"937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19"
]
],
"content": "š
Original date posted:2022-08-20\nš Original message:Good morning Greg,\n\n\n\u003e Hi James,\n\u003e Could you elaborate on a L2 contract where speedy\n\u003e settlement of the \"first part\" can be done, while having the rest\n\u003e take their time? I'm more thinking about time-out based protocols.\n\u003e \n\u003e Naturally my mind drifts to LN, where getting the proper commitment\n\u003e transaction confirmed in a timely fashion is required to get the proper\n\u003e balances back. The one hitch is that for HTLCs you still need speedy\n\u003e resolution otherwise theft can occur. And given today's \"layered\n\u003e commitment\" style transaction where HTLCs are decoupled from\n\u003e the balance output timeouts, I'm not sure this can save much.\n\nAs I understand it, layered commitments can be modified to use `OP_CTV`, which would be slightly smaller (need only to reveal a 32-byte `OP_CTV` hash on the witness instead of a 64-byte Taproot signature, or 73-byte classical pre-Taproot ECDSA signature), and is in fact precisely an example of the speedy settlement style.\n\n\u003e CTV style commitments have popped up in a couple places in my\n\u003e work on eltoo(emulated via APO sig-in-script), but mostly in the\n\u003e context of reducing interactivity in protocols, not in byte savings per se.\n\nIn many offchain cases, all channel participants would agree to some pre-determined set of UTXOs, which would be implemented as a transaction spending some single UTXO and outputting the pre-determined set of UTXOs.\n\nThe single UTXO can be an n-of-n of all participants, so that all agree by contributing their signatures:\n\n* Assuming Taproot, the output address itself is 33 bytes (x4 weight).\n* The n-of-n multisignature is 64 witness bytes (x1 weight). \n\nAlternatly the single UTXO can be a P2WSH that reveals an `OP_CTV`:\n\n* The P2WSH is 33 bytes (x4 weight) --- no savings here.\n* The revelation of the `\u003chash\u003e OP_CTV` is 33 witness bytes (x1 weight).\n\nThus, as I understand it, `OP_CTV` can (almost?) always translate to a small weight reduction for such \"everyone agrees to this set of UTXOs\" for all offchain protocols that would require it.\n\n\nRegards,\nZmnSCPxj",
"sig": "5cbc33c1d5e604b994376ae6da395381abcc40205da2de61f816f6c72e52ebdc57fd4654e100ebdf945e6b196089c0e2076353ff870d3f0292cf52d312ce61da"
}