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@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 92D6 0159 214C FEE3
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
