Published on: 2021-12-22T08:02:23+00:00
The Lightning Network developers are actively discussing various proposals and solutions to enhance efficiency and privacy in commitment transactions. One particular concern is the "toxic waste" issue associated with HTLCs, where committing to payment_hash directly inside transaction scripts leads to privacy concerns and the need to remember all payment_hashes seen. To address this, PTLCs are being considered, which commit the payment_point outside the scripts, allowing for independent recreation of scripts without revealing payment details on-chain.Another topic of discussion revolves around the use of revkey and pubkey in commitment transactions for the Lightning Network. While using the pubkey would enable participants to claim their anchor in the latest commitment, it undermines the purpose of the `OP_16 OP_CHECKSEQUENCEVERIFY` script branch. On the other hand, the revkey is not revealed when channels close with the latest commit, making it unable to clean up the utxo set. It is suggested that specifying the revkey as (revkey) instead of musig(revkey, remote_key) could work, but it would prevent bumping the current remote commitment if it appears on-chain. The consensus is that if someone needs to bump another party's commitment, they should use the remote_anchor provided by that party, not the local_anchor.A proposal has been made to introduce an additional feature bit that allows a channel to forward PTLCs only, excluding HTLCs. This proposal aims to ensure that state information remains bounded regardless of the channel's duration or the number of transactions over the channel.In terms of commitment transaction procedures, there is a suggestion to break down the data into several messages to reduce the number of required messages. The order of signing new commitments would be reversed, with Bob signing first if Alice initiates. Additionally, the proposal includes bundling with `option_simplified_update` without the adaptor sigs and adding the adaptor sigs as tlvs during PTLCs.ZmnSCPxj proposes an additional round-trip for certain transactions in the Lightning Network. For example, if A wants to sign a new commitment, she cannot immediately send it to B because B can broadcast this new commitment before A can claim PTLC_BA from B's new commitment. To solve this, B needs to send a new message called `remote_ptlcs_signed` to A containing his adaptor signatures for the PTLC-remote-success transactions. Similarly, A must send `remote_ptlcs_signed` to B before B can send its `commitment_signed`. This change simplifies the process and improves efficiency.Discussions also focus on including PTLC adaptor signatures in the `commitment_signed` message rather than `update_add_ptlc`. However, when the commitment changes, new signatures and adaptor signatures for all pending PTLCs need to be created, potentially requiring an extra round-trip. To address this, the other party must first send a new message (`remote_ptlcs_signed`) containing their adaptor signatures for the PTLC-remote-success transactions. Only then can the first party safely send their `commitment_signed`. Fast-forwards are mentioned as a way to avoid this issue by delaying the change of the commitment tx.LL suggests incorporating the adaptor signature in the `commitment_signed` message if possible, similar to pre-signed HTLC signatures, to avoid re-sending previous PTLC adaptor signatures for each `update_add_ptlc` message. MuSig2 and pre-sharing of signature nonces are also considered as potential ways to simplify the process and maintain a similar structure.There is a proposed script path to reduce the number of round trips required for generating signatures with MuSig. This involves having a script that the other party can spend if they reveal the discrete log of a point. With taproot, it is possible to have a script path as well, allowing a partial signature to satisfy "A CHECKSIGVERIFY" if the receiver knows the discrete log of the point. This reduces the number of round trips needed to set up the MuSig spend, with the PTLC-offerrer providing the adaptor signature and including it in the `update_add_ptlc` message.Implementing PTLCs on the Lightning Network necessitates significant changes to the transaction structure and update protocol. However, developers are exploring a minimal set of changes to enable deployment as soon as possible. Obtaining adaptor signatures before sending commit_sig and using pre-signed HTLC-success transactions for both local and remote commit are among the considerations. These changes introduce additional round-trips when updating the commitment, emphasizing the need for a design trade-off that minimizes protocol changes while reducing the number of extra round-trips. Ideas are being exchanged to achieve this without altering the transaction structure beyond adding PTLC outputs. The proposed protocol changes must accommodate both HTLCs and PTLCs and can be bundled with option_simplified_commitment or serve as an initial step toward the required protocol.
Updated on: 2023-07-31T23:56:59.791731+00:00