Published on: 2019-03-22T07:46:28+00:00
In the bitcoin-dev mailing list, there is a discussion about using OP_CSV in settlement transactions. ZmnSCPxj raises concerns about the lack of OP_CSV in the settlement branch and suggests enforcing relative timelocks using timelocks on update transactions and absolute or relative timelocks on settlement transactions. Anthony Towns argues that relative timelock can be enforced in the settlement branch by refusing to sign a settlement transaction without the timelock set. Aj confirms that update-1 isn't immediately spendable by settlement-1 due to the enforcement of BIP-68 by consensus. The conversation also discusses the use of codeseparator for enforcing timelocks in Lightning Network transactions. ZmnSCPxj proposes using OP_CHECKLOCKTIMEVERIFY and OP_DROP instead of codeseparator, as well as using OP_CHECKDLSVERIFY and OP_CHECKDLS for update transactions with a set timelock. Settlement transactions would have an absolute or relative timelock via sequence and commit to the script code. However, ZmnSCPxj expresses concern about the lack of OP_CSV in the settlement branch. The issue of relative timelocks is addressed by refusing to sign a settlement transaction without the timelock set, making the use of OP_CSV redundant. The conversation also discusses how settlement transactions affect offchain transactions. If an update transaction is placed on-chain, it is not immediately spendable by the corresponding settlement transaction due to BIP-68 being enforced by consensus.In another conversation, ZmnSCPxj and aj discuss different ways to enforce CLTV in Bitcoin transactions. One approach is to sign with NOINPUT, NOSCRIPT, and codeseparatorpos=1, allowing binding to any prior update transaction. Another approach is signing with codeseparatorpos=-1 and NOINPUT but committing to the script code and nSequence, allowing binding to only that update transaction. In both approaches, two pubkeys, two sigs, and the taproot point reveal are required. Aj suggests using OP_CHECKLOCKTIMEVERIFY, OP_DROP, OP_CHECKDLSVERIFY, and OP_CHECKDLS for enforcing timelocks. Update transactions would set their timelock, while settlement transactions would set an absolute timelock, relative timelock via sequence, and commit to the script code. However, BIP118 doesn't allow committing to the script code without also committing to the input transaction and scriptpubkey, requiring key rolling. The conversation also explores proposals for shortening the update transaction payout script. One proposal includes IF, OP_CODESEPARATOR, OP_CHECKLOCKTIMEVERIFY, OP_DROP, ENDIF, OP_CHECKDLSVERIFY, and OP_CHECKDLS. Signing with NOINPUT, NOSCRIPT, and codeseparatorpos=1 enforces CLTV and allows binding to any prior update transaction. Signing with codeseparatorpos=-1 and NOINPUT but committing to the script code and nSequence allows binding to only that update transaction. However, the shared keys differ in the two branches. The "update" branch uses the same constant keys, while the "state commit" branch uses different keys depending on the state/sequence number.The discussion also covers the usage of eltoo with MAST and NOINPUT. Aj clarifies that either of the two scripts is acceptable for an eltoo script. ZmnSCPxj raises a concern about Watchtower's knowledge of SIGHASH_NOINPUT and the private key included in the blob sent to them. Aj assures that from Alice/Bob's perspective, the NOINPUT sig ensures they control their money. They discuss a possible eltoo construction using setup transactions and update transactions that pay out to OP_IF and OP_ELSE scripts. Different signing methods are suggested depending on whether the transaction is an update or settlement transaction. Two pubkeys, two sigs, and the taproot point reveal are required.In a recent discussion on the Lightning-dev mailing list, Anthony Towns proposes the concept of "taproot plus" outputs, which would allow for the inclusion of NOINPUT signatures along with normal taproot address features. This approach offers safer NOINPUT usage, fewer hints of eltoo being used, and reduced data and computation load on the blockchain. However, it is noted that output tagging can already indicate the usage of NOINPUT, potentially negating the second benefit. The conversation also touches on maximizing privacy in the Lightning Network, which requires a new signature for every in-flight HTLC when the state is updated. This can result in a large number of signatures for highly active channels, but it is already true for current Poon-Dryja channels in BOLT 1.0.Another discussion highlights the potential conflict between output tagging and Taproot. Tagged outputs are seen as "taproot plus," allowing for both normal taproot functions and noinput signatures. Examples are provided to illustrate different funding transactions and settlement scenarios that could utilize this feature.
Updated on: 2023-07-31T21:29:51.407184+00:00