Arbitrary Bitcoin Contracts over LN
A very interesting question was raised by ZmnSCPxj on transporting smart contracts through LN, which is possible in principle if the smart contract can be implemented as a Bitcoin Script. An opinion was given that Poon-Dryja channel is more reliable for transporting “arbitrary” contracts than Decker-Wattenhofer or Decker-Osuntokun-Russell channels, although the latter are better in every other sense.
This opinion holds that only HTLC or its “scriptless script” equivalent should be transported over LN. Let’s assume an arbitrary contract C is introduced to be transported over LN between two nodes A and B.
Under Poon-Dryja channel, the CSV-encumberance does not interact with C but rather only encumbers the claiming of the money, therefore any CLTV conditions in C will not be tampered with by CSV-encumberance on a subsequent transaction. Under Decker-Osuntokun-Russell (eltoo) however, the CSV-encumberance delays the on-chain enforcement of the final transaction until the CSV is satisfied.
This is contrary to “Poon-Dryja” in which C immediately appears on the next transaction and is enforced immediately as it appears onchain. Poon-Dryja only requires CSV for revocability while Decker-Osuntokun-Russell requires one that may interfere with a time sensitive contract C.
The perceived problem with Poon-Dryja is that contracts can leak onchain and immediately become valid. This is why an additional OP_CSV condition with a two stage HTLC resolution was introduced in which the OP_CSV guard is the first stage which protects the second stage and keeps it clean.
This is not really a problem because in Poon-Dryja, the CSV comes with CLTV dependent transactions and the transaction can scale through with smaller timeouts. The CSV also does not interfere with the CLTV, thus making it easier to enforce transactions onchain and reduce the extra size of scripts under Decker-Osuntokun-Russell eltoo.
Resources
Support us and the authors of this article by donating to the following address:
344i4jxDt2pNRixNSLwYdCStZrAbYiFnLe
Comments powered by Talkyard.