DRAFT: interactive tx construction protocol

Recently, there was a proposal for a dual-funding protocol update that aimed to simplify the Lightning Network channel funding, splicing, and closing process by breaking it into smaller chunks. The major change in this update was the move from a single peer constructing a transaction to two participants. The set of messages proposed for this update were discussed in detail in the email. In addition, multi-party transaction construction and transaction format were also discussed. It was suggested that a common transaction format should be used to avoid leaking protocol usage. The possibility of implementing anti-fee sniping and masking among wallet core txn set was also discussed. nLocktime was another topic of discussion, where it was suggested that one could set nLockTime to tip - 6 to prevent the funding tx from being dropped in case of a reorg. Finally, Antoine suggested implementing a mutual closing tx to hold tx broadcast for a bit if "opt_dual_fund" is signaled to see if a tx_construction + add_funding_input for the channel is received soon.The Lightning Network protocol involves both parties exchanging messages to add inputs and outputs until they reach agreement on a tx_complete message. Duplicate inputs or outputs are not allowed, and every peer pays fees for their contributions with overpayment permitted. The initiator is responsible for contributing the output/input in question. Both peers can add or remove inputs and outputs until both peers have successfully exchanged a tx_complete message in succession.In the Simple Open case (2 parties), both peers signal opt_dual_fund, and the opener initiates a channel open with open_channel2 message indicating the feerate for the opening transaction. The accepter signals acceptance of the proposed channel open and sends their inputs and outputs. Both parties then exchange commitment signatures. In the Splice case, both peers signal opt_splice_ok, and one peer initiates a splice, signaling the feerate for the transaction. The initiator adds inputs and outputs as needed and sends the tx_complete message, followed by the peer doing the same. Both parties then exchange commitment signatures.In the Close case, both peers signal opt_collaborative_close in their node_announcement. A peer initiates a close sending a shutdown message, and a feerate is negotiated. The closing initiator sends tx_add_input to spend the funding output and tx_add_output to add their output for channel closure. The peer responds with tx_add_output, adding their output to the close transaction. If option_upfront_shutdown_script is flagged but no such output is present, the peer must fail the channel. Updating a collaborative transaction with RBF requires at least one identical, replaceable input as the original transaction. The Lightning-dev mailing list, hosted by the Linux Foundation, is a platform for developers to discuss and collaborate on Lightning Network development. One recent topic of discussion was a proposed change to Bitcoin Core's wallet code, which sparked a debate about the best way to implement multi-party channels. The proposal in question can be found on GitHub, where interested parties can view the code and participate in the discussion. Additionally, the Lightning Network RFC repository has a pull request related to this proposal, which can also be viewed and commented on. Those interested in contributing to the discussion can join the Lightning-dev mailing list or contact the proposal author directly via email.