DRAFT: interactive tx construction protocol

The conversation revolves around the proposal for dual-funding protocol, which involves two participants in constructing a transaction. The issue of nLocktime is raised, and it is suggested to add "My tip is xxxx" to the openchannel message to avoid problems with reorg. The initiator can announce its own, and the receiver can use it to sign the funding tx even if the receiver's tip is backward. However, the funding tx won't propagate from the receiver mempool, but that's fine if it does from the initiator one.The discussion also touches on the matter of multi-party tx construction and transactions format. It is proposed to coordinate with Coinjoin people to converge to a common format to avoid leaking protocol usage when we can hinder under Taproot. Additionally, the suggestion of implementing anti-fee sniping and masking among wallet core txn set is put forth. In case of a close, a failed collaborative close would result in an error and a unilateral close. Lastly, it is proposed to look at simplifying the dual-funding protocol by breaking it into smaller, more manageable chunks.The proposed change in the dual-funding protocol allows for the removal of inputs and outputs. The protocol involves several message types, including tx_add_input, tx_add_output, tx_remove_input, tx_remove_output, tx_complete, and tx_sigs, which are used to initiate transactions of various types (open, close, or splice) with different data fields. Duplicate inputs or outputs are considered a protocol error, and feerate is set by the initiator or negotiated before transaction construction in case of closing transactions.The Lightning Network protocol outlines the process for opening, splicing, and closing payment channels between parties. In the case of a close, the opener pays for the opening output, while in the case of a splice, the initiator of the splice pays for the funding tx's inclusion as an input and the new 'funding tx' output. Any contributor may signal that their input is RBF'able, with the nSequence for this input set to 0xFEFF FFFF, 0xFFFFFFFF otherwise.In the Simple Open case, both peers signal opt_dual_fund. In the Splice case, both peers signal opt_splice_ok. In the Close case, both parties signal opt_collaborative_close. 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. Type 45 (init_rbf) and data (channel_id and fee_step) are included in the collaborative RBF option. This section has been cribbed and repurposed from the original RBF proposal for splicing.The Lightning-dev mailing list has released a new proposal regarding RBF (Replace-By-Fee) fee bumping in Lightning Network transactions. The proposal suggests that each "fee_step" should add 1/4 to the initial transaction feerate, which should exceed the minimum transaction relay setting as per Rule 4 of BIP125. The sender must set "fee_step" greater than zero and greater than any prior "fee_step." The recipient must check that the new fee does not exceed the sender's current balance minus reserve after being applied to the splice transaction. If it exceeds, an error must be thrown. It should also include at least one identical, replaceable input as the original transaction. The proposal aims to make it easier for users to change fees on their transactions while ensuring that they meet certain minimum requirements. The proposal has been published on PR #524 and includes a link to the relevant section of the Bitcoin source code where the implementation can be found.