Published on: 2019-03-22T07:46:28+00:00
ZmnSCPxj and AJ Towns were discussing the implementation of eltoo in Bitcoin's Script language. They explored different options for enforcing timelocks in settlement transactions. ZmnSCPxj suggested using OP_CHECKLOCKTIMEVERIFY and OP_CHECKDLSVERIFY, while AJ proposed using OP_CODESEPARATOR. However, they acknowledged that both approaches require a flag for commitment to the scriptcode, which is not provided by BIP118.They also discussed the use of separate keys in the two branches of the script. The discussion touched on the necessity of OP_CSV in the settlement branch and concluded that OP_CSV is not needed if one party cannot single-handedly decide the relative locktime, as is the case with muSig. The post clarified that even a script without OP_CSV does not require it as long as the signatures use the same relative locktime.In another email exchange, ZmnSCPxj and AJ discussed the enforcement of relative timelocks in settlement transactions. AJ proposed refusing to sign a settlement transaction that doesn't have the timelock set as a way to enforce relative timelock in the settlement branch. They also mentioned that due to BIP-68 being enforced by consensus, settlement-1 signed by ZmnSCPxj is not immediately spendable by update-1.The conversation highlighted the technical details involved in enforcing timelocks in settlement transactions for offchain channels. It emphasized the need for a distinct public key for settlement transactions and the enforcement of nLockTime with OP_CHECKLOCKTIMEVERIFY. It also discussed the possibility of using OP_CODESEPARATOR to distinguish between update and settlement transactions.AJ and ZmnSCPxj discussed potential ways to simplify the Bitcoin script for Taproot. They explored using different shared keys in the two branches of the script and signing with NOINPUT, NOSCRIPT, and codeseparatorpos to enforce CheckLockTimeVerify (CLTV). They also mentioned the requirement of two pubkeys, two sigs, and the taproot point reveal.The email exchange touched on the proposal of using either of two scripts for eltoo. It was clarified that both scripts can be used, with differences in the signing process. One style involves exchanging the NOINPUT signature, while the other style requires cosigning the muSig with NOINPUT and sharing the private key for Q. The discussion highlighted the simplicity of the first style and the efficiency of the second style with multiple parties.ZmnSCPxj raised a question about the "must have a non-SIGHASH_NOINPUT" rule and its implications for watchtowers. It was suggested that watchtowers store both SIGHASH_NOINPUT signatures from both sides in the blob sent to them. Rusty Russell responded by mentioning the possibility of future segwit versions relaxing the rule. ZmnSCPxj proposed the idea of requiring a sig that commits to the input tx as a safe and inexpensive approach to address the issue.The discussion delved into the potential problems with NOINPUT signatures and the need for safety measures. The differentiation between malicious and non-malicious double-spends was debated, with concerns raised about the risks associated with coins sent to the sender. The conversation emphasized the importance of implementing safety measures that are helpful in practical failure scenarios. It was suggested that a "sig that commits to the input tx" could be a standardness rule for NOINPUT.Anthony Towns proposed the concept of tagged outputs, called "taproot plus," which would allow for the use of noinput signatures alongside normal taproot addresses. Different transaction structures were discussed, including cooperative claims, update transactions, settlement transactions, and trigger transactions. Concerns were raised about how to bind update transactions to the funding tx output if they are not tagged. Solutions such as storing multiple separate states or adding a trigger transaction were considered.ZmnSCPxj shared insights on the disadvantages of maximizing privacy, particularly in terms of performance and use with DLC. He suggested splitting a channel into high-activity LN payments and rare-activity DLC bets as a way to mitigate the potential issues.In a discussion on the Lightning-dev mailing list, ZmnSCPxj responds to AJ's post about the potential conflict between output tagging and Taproot. ZmnSCPxj raises the question of whether it is possible to hide the clause "or a NOINPUT sig from A with a non-NOINPUT sig from B" behind a Taproot. They also provide their thoughts on using scriptless scripts for HTLCs and bilateral/cooperative close when an HTLC is in-flight.The email proposes a way to enhance the security of the eltoo channel in Bitcoin by requiring every script to have a valid signature that commits to the input. However, this approach has some drawbacks such as revealing the taproot point and two keys, and additional script overhead. The email suggests that requiring a non-NOINPUT signature can provide a defense against third party malleability, unlike output tagging.
Updated on: 2023-08-02T00:39:11.911579+00:00