Michael Folkson [ARCHIVE] on Nostr: 📅 Original date posted:2018-08-01 📝 Original message: Thanks for this ZmnSCPxj, ...
📅 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>;
📝 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>;