DRAFT: interactive tx construction protocol

Antoine proposed a transaction chain construction as a solution to utxos snooping. The proposal involves the first input being signed by A with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY and creating a first transaction txA1. A then creates and signs the funding transaction out of the first output of txA1 called txA2, which is signed with SINGLE|ANYONECANPAY allowing B to add inputs and outputs for its own change. This method requires more setup fees opener-side but avoids gratuitous probing by the accepter.Lisa Neigut shared feedback from the check-in for the dual-funding proposal suggesting simplifying it into smaller, more manageable chunks. The email highlights the biggest piece of the dual-funding protocol update as the move from a single peer constructing a transaction to two participants. The proposal aims to reuse this portion of the protocol for batched closings and splicing.The set of messages involved in the dual-funding proposal includes tx_add_input, tx_add_output, tx_remove_input, tx_remove_output, tx_complete, and tx_sigs with subtypes witness_stack and witness_element. Validity of inputs/outputs is not checked until both peers have sent consecutive tx_complete messages. Inputs must be segwit compatible (PW* or P2SH-PW*) and all output scripts must be standard. Either peer may add or remove inputs and outputs until both peers have successfully exchanged a tx_complete message in succession. In case of a failure to agree on tx_complete, either peer may fail the channel or open protocol.The Lightning Network protocol outlines the process for initiating a channel open with an open_channel2 message, which includes proposing a feerate for the opening transaction. The accepter then signals acceptance of the proposal via accept_channel2. In the case of a Splice, both peers signal opt_splice_ok and one peer initiates the splice, signaling the feerate for the transaction. The initiator sends tx_add_input with the original funding output, tx_add_output with the new post-splice funding output, and any additional tx_add_input/output as needed. The peer does the same and both parties send tx_complete. They then exchange commitment signatures and continue with the protocol. In the close case, both peers signal opt_collaborative_close in their node_announcement. A peer initiates a close by sending a shutdown, negotiates a feerate out of band, and then adds their output for the channel closure via tx_add_input and tx_add_output. 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 with a value at or within a reasonable feerate gap of the peer's funding output is present, then the peer must fail the channel.If any input is flagged as RBF’able, then the transaction is considered eligible for RBF. RBF can be initiated by either party, and serves as an initiation for another round of transaction composition, as outlined above. Each fee_step adds 1/4 (rounded down) to the initial transaction feerate. The sender MUST set fee_step greater than zero and greater than any prior fee_step. If the new fee exceeds the sender's current balance minus reserve after it is applied to the splice transaction, the recipient MUST error. An additional rule will be added to the checks of an RBF transaction that it must include at least one identical, replaceable input as the original transaction.