📅 Original date posted:2018-08-01
📝 Original message:
Thanks for this ZmnSCPxj, very interesting.
A couple of follow ups please:
1) Poon-Dryja (LN penalty), Decker-Wattenhofer and Decker-Osuntokun-Russell
(eltoo) just refer to the process for claiming funds when an old state is
broadcast? Poon-Dryja doesn't require a soft fork but
Decker-Osuntokun-Russell does?
2) How does Decker-Wattenhofer claim funds when an old state is broadcast?
On Wed, Aug 1, 2018 at 11:36 AM, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> 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
>
>
--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180801/47c76b51/attachment-0001.html>;
Michael Folkson [ARCHIVE] /
npub103…2kpam
2023-06-09 12:51:17
in reply to nevent1q…fznu
Author Public Key
npub103ycruxnchhvja33mcnnkfdkgd0s7vlqlfkvufcdm5lnhpuh6f4q82kpamPublished at
2023-06-09 12:51:17Event JSON
{
"id": "20b8e2fc7b940e4b15e23d20627e1819b53757ae41bb42b725bc3c3d5a7cb348",
"pubkey": "7c4981f0d3c5eec97631de273b25b6435f0f33e0fa6cce270ddd3f3b8797d26a",
"created_at": 1686315077,
"kind": 1,
"tags": [
[
"e",
"e0078e5efbc2b1390e6d89e1720eefa0a84e13c624b812e84bace67c6c12c8f0",
"",
"root"
],
[
"e",
"e31cb8d33311966c59600f07435b5a9055377e542e4de945052e1e153f12a862",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-08-01\n📝 Original message:\nThanks for this ZmnSCPxj, very interesting.\n\nA couple of follow ups please:\n\n1) Poon-Dryja (LN penalty), Decker-Wattenhofer and Decker-Osuntokun-Russell\n(eltoo) just refer to the process for claiming funds when an old state is\nbroadcast? Poon-Dryja doesn't require a soft fork but\nDecker-Osuntokun-Russell does?\n2) How does Decker-Wattenhofer claim funds when an old state is broadcast?\n\nOn Wed, Aug 1, 2018 at 11:36 AM, ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\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\" is\n\u003e implementable as a Bitcoin SCRIPT.\n\u003e\n\u003e Afterwards, I opined that, for transportation of *arbitrary* contracts,\n\u003e 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 transporting\n\u003e any other contract on LN. HTLCs can even be used to implement\n\u003e (nontransferable) swap options, and can be composed (at the cost of\n\u003e 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 over\n\u003e 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, we\n\u003e 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, with\n\u003e 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 and\n\u003e B, and whose half is kept secret by the A (resp. B) until they both agree\n\u003e 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 which\n\u003e would be implicitly required by the funding transaction anyway). The\n\u003e (revoke) || does not affect the enforcement of C if the revocation key is\n\u003e not yet revealed; once the revocation key is revealed, that revokes the\n\u003e entire sequence of transactions (which is why (revoke) || appears in both\n\u003e the second and third transactions above). In particular, the\n\u003e CSV-encumberance does not affect claiming of C; it encumbers the claiming\n\u003e of the money, but does not interact with C itself. Thus, any CLTV\n\u003e conditions in C will not be interefered with by the CSV-encumberance on the\n\u003e *next* transaction.\n\u003e\n\u003e Note also that only signA and signB for the final transaction needs to be\n\u003e shared; the witnessC can presumably be fulfilled by each side themselves\n\u003e automatically.\n\u003e\n\u003e On the other hand, under Decker-Osuntokun-Russell eltoo, the transaction\n\u003e 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 \u0026\u0026\n\u003e B)] -\u003e [nSequence signA signB, C]\n\u003e\n\u003e Now the above is massively simpler with no additional SCRIPT that needs to\n\u003e be written, around the transported contract C --- but the CSV in the second\n\u003e transaction, is now potentially interfering with the operation of the\n\u003e contract C, as the final transaction cannot be enforced onchain until the\n\u003e CSV has been satisfied. This is in contrast with the Poon-Dryja case,\n\u003e where the contract C appears immediately on the second transaction in the\n\u003e sequence, and can be 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 the\n\u003e \"update\" path, and the CLTV required is always a past Unix Epoch time, so\n\u003e this CLTV cannot interfere with the contract C).\n\u003e\n\u003e The above consideration, is why I suppose that, *for arbitrary contracts*,\n\u003e Poon-Dryja is superior.\n\u003e\n\u003e Simply, the conclusion is that Decker-Osuntokun-Russell channels require a\n\u003e CSV that may interfere with the contract C if C is time-sensitive (i.e. has\n\u003e a CLTV or CSV itself), whereas Poon-Dryja requires CSV only for\n\u003e revocability, and the CSV cannot prevent the enforcement of time-sensitive\n\u003e 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 of\n\u003e the CLTV-deltas imposed by intermediary nodes, with weights complicated by\n\u003e the fact that CLTV-deltas are summed together but the highest CSV is added\n\u003e to the CLTV total, which does not mix well with typical route-finding\n\u003e algorithms (most of which assume a simple summing of costs, which\n\u003e CLTV-deltas use but CSVs on Decker-Osuntokun-Russell do not since highest\n\u003e 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.\n\u003e 2. Dangerous \"toxic waste\" (old revoked transactions) which (1) you\n\u003e should not recover from your backups and (2) you should not let your worst\n\u003e enemy find, because they can publish those onchain and make you LOSE MONEY.\n\u003e 3. Symmetrical chains of transactions, different for both parties,\n\u003e 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 transfers,\n\u003e and they (and their equivalents under scriptless) are sufficient for most\n\u003e practical transfers. Thus, moving forward, Decker-Osuntokun-Russell\n\u003e remains a superior technology over Poon-Dryja.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\n\n\n-- \nMichael Folkson\nEmail: michaelfolkson at gmail.com\nKeybase: michaelfolkson\nPGP: 92D6 0159 214C FEE3\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180801/47c76b51/attachment-0001.html\u003e",
"sig": "d26dea3306a480c3e39216a4fa6c83d036f33dcf21da80f87201805aa807d2219e17785b9d63b299fa26b373de363928ee5553ef1b028e111a3b1c5d22c2eb11"
}