📅 Original date posted:2018-08-01
📝 Original message:
Thanks for the excellent writeup ZmnSCPxj, I just have a minor issue
with your characterization that LN-penalty is to be preferred.
My issue is with the fact that CLTV-branches and nLocktimed spending
transactions also need to be guarded with a further `OP_CSV` condition,
since they may leak on-chain, and be immediately valid. This is the
reason why we introduced the two stage HTLC resolution, with the first
stage acting as the `OP_CSV` guard, and keeping the second stage clean.
I think therefore the construction of the contract ought to be this:
[/*arbitrary*/, A && B] -> [signA signB, (revoke) || (CSV && A && B && C)] -> [signA signB witnessCbyA, revoke || A] /* held by A */
[/*arbitrary*/, A && B] -> [signA signB, (revoke) || (CSV && A && B && C)] -> [signA signB witnessCbyB, revoke || B] /* held by B */
Namely the CSV belongs in the output script, not the input script (which
is under the control of the spending party). Notice that I might have
misgroked your syntax :-) If C now contains a CLTV-branch whose timeout
expires before we attempt the on-chain mediation, suddenly both branches
become valid and we have a race.
Take this for example:
```
OP_IF
x OP_CLTV
<checksigs>
OP_ELSE
<checksigs>
OP_END
```
If we wait until block x was found, we attempt to cheat by publishing
this state, and suddenly both prepared reaction transactions are valid,
resulting in a race. This is simply due to the fact that transactions
can leak. To fix this we'd have to encumber the OP_IF branch with an
additional CSV. So it's not really like we can just add an OR-clause to
an arbitrary contract and we're safe, we actually have to weave it into
the logic, or create a second stage that just disambiguates the cheat
and the non-cheat unilateral case.
With eltoo this sort of weaving falls away, since we guarantee that the
old state can never leak on-chain. If we squint at it we can see that
we have effectively pushed down the second stage into the on-chain state
resolution, allowing us to keep the contracts clean.
Cheers,
Christian
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:
> Good morning list,
>
> Recently, somebody on the IRC channel, asked regarding smart contracts
> being transported via LN.
>
> Indeed, this is theoretically possible, provided the "smart contract"
> is implementable as a Bitcoin SCRIPT.
>
> Afterwards, I opined that, for transportation of *arbitrary*
> contracts, Poon-Dryja is superior to either Decker-Wattenhofer or
> Decker-Osuntokun-Russell.
>
> So, first, my other opinions:
>
> 1. The only smart contract you really want to transport is HTLC (or
> equivalent in scriptless script). There really is no point in
> transporting any other contract on LN. HTLCs can even be used to
> implement (nontransferable) swap options, and can be composed (at the
> cost of increasing CLTV limits on backoff) to create multi-step swaps.
>
> 2. Decker-Osuntokun-Russell "eltoo" is far superior to Poon-Dryja
> "LN-penalty" in everything else, except transportation of *arbitrary*
> contracts.
>
> Now, ultimately any Bitcoin SCRIPT may be expressed as a Boolean
> computation whether or not the contract has been fulfilled by the
> transaction that attempts to claim it.
>
> So I introduce, an arbitrary contract C, ostensibly to be transported
> over LN.
>
> And I introduce our transactions, as so: [scriptSig, redeemScript] ->
> redeeming transaction
>
> To transport C over a channel between nodes A and B, under Poon-Dryja,
> we first have a channel anchoring transaction onchain:
>
> [/*arbitrary*/, A && B] ->
>
> Now suppose the entire output is to be put into a contract C. Under
> Poon-Dryja, we create the below symmetrical series of transactions,
> with only the anchoring transaction existing onchain:
>
> [/*arbitrary*/, A && B] -> [signA signB, (revoke) || (A && B && C)] ->
> [signA signB witnessCbyA, revoke || (A && CSV)] /* held by A */
>
> [/*arbitrary*/, A && B] -> [signA signB, (revoke) || (A && B && C)] ->
> [signA signB witnessCbyB, revoke || (B && CSV)] /* held by B */
>
> Where (revoke) is the revocation key, whose derivation requires both A
> and B, and whose half is kept secret by the A (resp. B) until they
> both agree to revoke the old state.
>
> Of note is that the only additional condition added to C is (A && B),
> which makes sense since the contract is between nodes A and B (and
> which would be implicitly required by the funding transaction anyway).
> The (revoke) || does not affect the enforcement of C if the revocation
> key is not yet revealed; once the revocation key is revealed, that
> revokes the entire sequence of transactions (which is why (revoke) ||
> appears in both the second and third transactions above). In
> particular, the CSV-encumberance does not affect claiming of C; it
> encumbers the claiming of the money, but does not interact with C
> itself. Thus, any CLTV conditions in C will not be interefered with
> by the CSV-encumberance on the *next* transaction.
>
> Note also that only signA and signB for the final transaction needs to
> be shared; the witnessC can presumably be fulfilled by each side
> themselves automatically.
>
> On the other hand, under Decker-Osuntokun-Russell eltoo, the
> transaction series is:
>
> [/*arbitrary*/, A && B] -> [signA signB, (CSV && A && B) || (CLTV && A
> && B)] -> [nSequence signA signB, C]
>
> Now the above is massively simpler with no additional SCRIPT that
> needs to be written, around the transported contract C --- but the CSV
> in the second transaction, is now potentially interfering with the
> operation of the contract C, as the final transaction cannot be
> enforced onchain until the CSV has been satisfied. This is in
> contrast with the Poon-Dryja case, where the contract C appears
> immediately on the second transaction in the sequence, and can be
> enforced, as soon as it appears onchain.
>
> (In eltoo, the (CTLV && A && B) branch of the intermediate contract is
> the "update" path, and the CLTV required is always a past Unix Epoch
> time, so this CLTV cannot interfere with the contract C).
>
> The above consideration, is why I suppose that, *for arbitrary
> contracts*, Poon-Dryja is superior.
>
> Simply, the conclusion is that Decker-Osuntokun-Russell channels
> require a CSV that may interfere with the contract C if C is
> time-sensitive (i.e. has a CLTV or CSV itself), whereas Poon-Dryja
> requires CSV only for revocability, and the CSV cannot prevent the
> enforcement of time-sensitive C.
>
> Indeed, as I pointed out, even when transporting HTLCs,
> Decker-Osuntokun-Russell will require consideration of the CSV on top
> of the CLTV-deltas imposed by intermediary nodes, with weights
> complicated by the fact that CLTV-deltas are summed together but the
> highest CSV is added to the CLTV total, which does not mix well with
> typical route-finding algorithms (most of which assume a simple
> summing of costs, which CLTV-deltas use but CSVs on
> Decker-Osuntokun-Russell do not since highest is used).
>
> In almost all other ways, Poon-Dryja is inferior:
>
> 1. Does not use nLockTime in a sufficiently clever way. 2.
> Dangerous "toxic waste" (old revoked transactions) which (1) you
> should not recover from your backups and (2) you should not let your
> worst enemy find, because they can publish those onchain and make you
> LOSE MONEY. 3. Symmetrical chains of transactions, different for
> both parties, instead of a single chain.
>
> In addition, arbitrary contracts are not really particularly useful.
> HTLCs seem to me an important building block for digital value
> transfers, and they (and their equivalents under scriptless) are
> sufficient for most practical transfers. Thus, moving forward,
> Decker-Osuntokun-Russell remains a superior technology over
> Poon-Dryja.
>
> Regards, ZmnSCPxj _______________________________________________
> Lightning-dev mailing list Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:51:18
in reply to nevent1q…5zuy
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:51:18Event JSON
{
"id": "4f8660a80f3eabf2a61ba34a9a7ff10315a3a8efd613fb630a19a1a0af7b4e14",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315078,
"kind": 1,
"tags": [
[
"e",
"e0078e5efbc2b1390e6d89e1720eefa0a84e13c624b812e84bace67c6c12c8f0",
"",
"root"
],
[
"e",
"2246db4d03adc691475ab486f6f29bf5a63c2d618cd7cbce004e6ba8833f20f0",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-08-01\n📝 Original message:\nThanks for the excellent writeup ZmnSCPxj, I just have a minor issue\nwith your characterization that LN-penalty is to be preferred.\n\nMy issue is with the fact that CLTV-branches and nLocktimed spending\ntransactions also need to be guarded with a further `OP_CSV` condition,\nsince they may leak on-chain, and be immediately valid. This is the\nreason why we introduced the two stage HTLC resolution, with the first\nstage acting as the `OP_CSV` guard, and keeping the second stage clean.\n\nI think therefore the construction of the contract ought to be this:\n\n[/*arbitrary*/, A \u0026\u0026 B] -\u003e [signA signB, (revoke) || (CSV \u0026\u0026 A \u0026\u0026 B \u0026\u0026 C)] -\u003e [signA signB witnessCbyA, revoke || A] /* held by A */\n[/*arbitrary*/, A \u0026\u0026 B] -\u003e [signA signB, (revoke) || (CSV \u0026\u0026 A \u0026\u0026 B \u0026\u0026 C)] -\u003e [signA signB witnessCbyB, revoke || B] /* held by B */\n\nNamely the CSV belongs in the output script, not the input script (which\nis under the control of the spending party). Notice that I might have\nmisgroked your syntax :-) If C now contains a CLTV-branch whose timeout\nexpires before we attempt the on-chain mediation, suddenly both branches\nbecome valid and we have a race.\n\nTake this for example:\n\n```\nOP_IF\n x OP_CLTV\n \u003cchecksigs\u003e\nOP_ELSE\n \u003cchecksigs\u003e\nOP_END\n```\n\nIf we wait until block x was found, we attempt to cheat by publishing\nthis state, and suddenly both prepared reaction transactions are valid,\nresulting in a race. This is simply due to the fact that transactions\ncan leak. To fix this we'd have to encumber the OP_IF branch with an\nadditional CSV. So it's not really like we can just add an OR-clause to\nan arbitrary contract and we're safe, we actually have to weave it into\nthe logic, or create a second stage that just disambiguates the cheat\nand the non-cheat unilateral case.\n\nWith eltoo this sort of weaving falls away, since we guarantee that the\nold state can never leak on-chain. If we squint at it we can see that\nwe have effectively pushed down the second stage into the on-chain state\nresolution, allowing us to keep the contracts clean.\n\nCheers,\nChristian\nZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e\nwrites:\n\n\u003e Good morning list,\n\u003e\n\u003e Recently, somebody on the IRC channel, asked regarding smart contracts\n\u003e being transported via LN.\n\u003e\n\u003e Indeed, this is theoretically possible, provided the \"smart contract\"\n\u003e is implementable as a Bitcoin SCRIPT.\n\u003e\n\u003e Afterwards, I opined that, for transportation of *arbitrary*\n\u003e contracts, Poon-Dryja is superior to either Decker-Wattenhofer or\n\u003e Decker-Osuntokun-Russell.\n\u003e\n\u003e So, first, my other opinions:\n\u003e\n\u003e 1. The only smart contract you really want to transport is HTLC (or\n\u003e equivalent in scriptless script). There really is no point in\n\u003e transporting any other contract on LN. HTLCs can even be used to\n\u003e implement (nontransferable) swap options, and can be composed (at the\n\u003e cost of increasing CLTV limits on backoff) to create multi-step swaps.\n\u003e\n\u003e 2. Decker-Osuntokun-Russell \"eltoo\" is far superior to Poon-Dryja\n\u003e \"LN-penalty\" in everything else, except transportation of *arbitrary*\n\u003e contracts.\n\u003e\n\u003e Now, ultimately any Bitcoin SCRIPT may be expressed as a Boolean\n\u003e computation whether or not the contract has been fulfilled by the\n\u003e transaction that attempts to claim it.\n\u003e\n\u003e So I introduce, an arbitrary contract C, ostensibly to be transported\n\u003e over LN.\n\u003e\n\u003e And I introduce our transactions, as so: [scriptSig, redeemScript] -\u003e\n\u003e redeeming transaction\n\u003e\n\u003e To transport C over a channel between nodes A and B, under Poon-Dryja,\n\u003e we first have a channel anchoring transaction onchain:\n\u003e\n\u003e [/*arbitrary*/, A \u0026\u0026 B] -\u003e\n\u003e\n\u003e Now suppose the entire output is to be put into a contract C. Under\n\u003e Poon-Dryja, we create the below symmetrical series of transactions,\n\u003e with only the anchoring transaction existing onchain:\n\u003e\n\u003e [/*arbitrary*/, A \u0026\u0026 B] -\u003e [signA signB, (revoke) || (A \u0026\u0026 B \u0026\u0026 C)] -\u003e\n\u003e [signA signB witnessCbyA, revoke || (A \u0026\u0026 CSV)] /* held by A */\n\u003e\n\u003e [/*arbitrary*/, A \u0026\u0026 B] -\u003e [signA signB, (revoke) || (A \u0026\u0026 B \u0026\u0026 C)] -\u003e\n\u003e [signA signB witnessCbyB, revoke || (B \u0026\u0026 CSV)] /* held by B */\n\u003e\n\u003e Where (revoke) is the revocation key, whose derivation requires both A\n\u003e and B, and whose half is kept secret by the A (resp. B) until they\n\u003e both agree to revoke the old state.\n\u003e\n\u003e Of note is that the only additional condition added to C is (A \u0026\u0026 B),\n\u003e which makes sense since the contract is between nodes A and B (and\n\u003e which would be implicitly required by the funding transaction anyway).\n\u003e The (revoke) || does not affect the enforcement of C if the revocation\n\u003e key is not yet revealed; once the revocation key is revealed, that\n\u003e revokes the entire sequence of transactions (which is why (revoke) ||\n\u003e appears in both the second and third transactions above). In\n\u003e particular, the CSV-encumberance does not affect claiming of C; it\n\u003e encumbers the claiming of the money, but does not interact with C\n\u003e itself. Thus, any CLTV conditions in C will not be interefered with\n\u003e by the CSV-encumberance on the *next* transaction.\n\u003e\n\u003e Note also that only signA and signB for the final transaction needs to\n\u003e be shared; the witnessC can presumably be fulfilled by each side\n\u003e themselves automatically.\n\u003e\n\u003e On the other hand, under Decker-Osuntokun-Russell eltoo, the\n\u003e transaction series is:\n\u003e\n\u003e [/*arbitrary*/, A \u0026\u0026 B] -\u003e [signA signB, (CSV \u0026\u0026 A \u0026\u0026 B) || (CLTV \u0026\u0026 A\n\u003e \u0026\u0026 B)] -\u003e [nSequence signA signB, C]\n\u003e\n\u003e Now the above is massively simpler with no additional SCRIPT that\n\u003e needs to be written, around the transported contract C --- but the CSV\n\u003e in the second transaction, is now potentially interfering with the\n\u003e operation of the contract C, as the final transaction cannot be\n\u003e enforced onchain until the CSV has been satisfied. This is in\n\u003e contrast with the Poon-Dryja case, where the contract C appears\n\u003e immediately on the second transaction in the sequence, and can be\n\u003e enforced, as soon as it appears onchain.\n\u003e\n\u003e (In eltoo, the (CTLV \u0026\u0026 A \u0026\u0026 B) branch of the intermediate contract is\n\u003e the \"update\" path, and the CLTV required is always a past Unix Epoch\n\u003e time, so this CLTV cannot interfere with the contract C).\n\u003e\n\u003e The above consideration, is why I suppose that, *for arbitrary\n\u003e contracts*, Poon-Dryja is superior.\n\u003e\n\u003e Simply, the conclusion is that Decker-Osuntokun-Russell channels\n\u003e require a CSV that may interfere with the contract C if C is\n\u003e time-sensitive (i.e. has a CLTV or CSV itself), whereas Poon-Dryja\n\u003e requires CSV only for revocability, and the CSV cannot prevent the\n\u003e enforcement of time-sensitive C.\n\u003e\n\u003e Indeed, as I pointed out, even when transporting HTLCs,\n\u003e Decker-Osuntokun-Russell will require consideration of the CSV on top\n\u003e of the CLTV-deltas imposed by intermediary nodes, with weights\n\u003e complicated by the fact that CLTV-deltas are summed together but the\n\u003e highest CSV is added to the CLTV total, which does not mix well with\n\u003e typical route-finding algorithms (most of which assume a simple\n\u003e summing of costs, which CLTV-deltas use but CSVs on\n\u003e Decker-Osuntokun-Russell do not since highest is used).\n\u003e\n\u003e In almost all other ways, Poon-Dryja is inferior:\n\u003e\n\u003e 1. Does not use nLockTime in a sufficiently clever way. 2.\n\u003e Dangerous \"toxic waste\" (old revoked transactions) which (1) you\n\u003e should not recover from your backups and (2) you should not let your\n\u003e worst enemy find, because they can publish those onchain and make you\n\u003e LOSE MONEY. 3. Symmetrical chains of transactions, different for\n\u003e both parties, instead of a single chain.\n\u003e\n\u003e In addition, arbitrary contracts are not really particularly useful.\n\u003e HTLCs seem to me an important building block for digital value\n\u003e transfers, and they (and their equivalents under scriptless) are\n\u003e sufficient for most practical transfers. Thus, moving forward,\n\u003e Decker-Osuntokun-Russell remains a superior technology over\n\u003e Poon-Dryja.\n\u003e\n\u003e Regards, ZmnSCPxj _______________________________________________\n\u003e Lightning-dev mailing list Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "a5124cda34b715688b70bd920fdf7d92361c82347c4a70ef95da46cd01a7873b620660ba4cb46d35c27cb5b00ecf6a4d1ff93d5c81b8c427883b0cd6c866b331"
}