DRAFT: interactive tx construction protocol

The conversation thread revolves around the implementation of nLockTime in C-lightning and a proposal for a dual-funding protocol update. One notable feature of this update is that the initiator can announce its own tip to sign the funding transaction, even if the receiver's tip is backward. However, there is a caveat that the funding transaction signature would fail verification if the tip differs between the funder and fundee. Additionally, the discussion also covers the construction of multi-party transactions. In this scenario, Alice initiates the transaction construction to Bob, who then announces it to Carol. The proposed set of messages for the dual-funding protocol update includes various steps such as tx_add_input, tx_add_output, tx_remove_input, tx_remove_output, tx_complete, and tx_sigs. It is worth noting that the validity of inputs/outputs is not checked until both peers have sent consecutive tx_complete messages, and duplicate inputs or outputs are deemed a protocol error. Furthermore, the feerate is set by the initiator and negotiated before the transaction construction is initiated in the case of a closing transaction.The Lightning Network protocol specifies the rules for opening, splicing, and closing payment channels between two peers. When opening a simple channel, both parties signal opt_dual_fund, and the opener initiates the process by sending an open_channel2 message indicating the feerate for the opening transaction. The accepter then signals acceptance of the channel open via accept_channel2. Both parties add inputs and outputs to the transaction until they reach an agreement, signaled by the exchange of tx_complete messages, after which they can exchange commitment signatures and continue with the channel.For splicing, both peers signal opt_splice_ok, and one peer initiates the splice by sending the original funding output as an input and the new post-splice funding output as an output via tx_add_input/output. Both parties continue adding inputs and outputs and send tx_complete messages until they reach an agreement, then exchange commitment signatures and complete the splice process.Closing a channel involves both peers signaling opt_collaborative_close in their node announcement. A peer initiates the close by sending a shutdown message, and the closing initiator adds an input for the funding output and an output for their own output for the channel closure via tx_add_input/output. The other peer responds by adding their output via tx_add_output. If option_upfront_shutdown_script is flagged but no such output with a value within reasonable feerate gap is present, the peer must fail the channel.Lastly, RBF (replace-by-fee) allows either party to initiate another round of transaction composition when any input is flagged as RBF'able. This is done through an init_rbf message that includes the channel ID and a fee step, which adds 1/4 to the initial transaction feerate. The recipient must error if the new fee exceeds the sender's current balance minus reserve after it is applied to the splice transaction. Overall, the Lightning Network protocol specifies various rules for inputs, outputs, fees, and other details to ensure secure and efficient payment channel management.