DRAFT: interactive tx construction protocol

One proposal involved implementing a multi-channel open with PoDLE signature committing to a node_id to prevent attacks. The use of the lower bit on the serial_id was also discussed for multifunding and creating multiple channels simultaneously. The protocol for serial ids in multiparty constructions was discussed, with agreement that collisions between peers are considered a protocol error.The inclusion of UTXOs in Schnorr signatures for Lightning Network transactions was discussed, highlighting that it does not add security to the verification process. Compatibility with JoinMarket was debated, and upgrading the protocol to schnorr/taproot or native segwit was suggested. Mitigating flooding through acceptable reuse after a valid PoDLE exchange and limiting accepted node_ids to those previously seen in a node_announcement were also discussed.Improvements to protocol messages used in transactions were suggested, including adding a serial_id to inputs and outputs for ordering and deletions. The concern of reusing addresses in Bitcoin's Lightning Network was raised, but it was noted that PoDLE provides security by proving control of the utxo, so including the utxo in the signature commitment is unnecessary.The challenge-bypass-extension protocol and its differences from the Lightning Network use-case were mentioned, with ongoing analysis of the document. The use of PoDLEs in JoinMarket was discussed, suggesting sharing the PoDLE format with JoinMarket to slow down probe attempts.A new transfer opening method using an equation to verify the Schnorr signature was proposed. The need to commit to the utxo was questioned, but it was noted that including it prevents address reuse when two UTXOs with the same address are used to make different channels.Proposals were made to add a second commitment requirement to PoDLEs in JoinMarket and limit their validity between an initiator and a single peer. This would prevent attacks where verification by any node other than the intended recipient fails. The mechanism used in JoinMarket to prevent reuse of commitments was explained.Overall, the discussions on the Lightning Network protocol focused on improving multi-channel opens, serial ids, UTXO inclusion in signatures, compatibility with JoinMarket, and preventing address reuse. Various proposals and suggestions were made to enhance security and efficiency.In addition to the email exchanges, there have been discussions on the Lightning-dev mailing list regarding multi-party channels, transaction collaboration between peers, and the use of PSBT and RBF protocols. One proposal suggests changing Bitcoin Core's wallet code to enable multi-party channels, and interested parties can participate in the discussion through the Lightning Network RFC repository or the Lightning-dev mailing list.The suitability of PSBT for wallet interoperability and peer-to-peer transaction collaboration has been debated, with concerns raised about its weightiness for the latter. Links to the BIP-0174.mediawiki page on GitHub were shared in the email exchanges on the mailing list.The email exchange primarily focused on the dual-funding protocol update, which allows two participants to construct a transaction together. It covers various cases such as open, close, and splice, and discusses splicing, closing, and updating collaborative transactions with RBF. Feedback received suggested breaking down the update into smaller parts for simplicity.The set of messages involved in initiating the protocol varies depending on the case of the transaction, and inputs/outputs validity is not checked until both peers have sent consecutive tx_complete messages. Each peer pays fees for their contributed inputs and outputs, along with enough to cover the maximum estimate of their witnesses. The initiator is responsible for contributing the relevant output/input, and both peers can add or remove inputs and outputs until a tx_complete message is successfully exchanged.Overall, the discussions and email exchange aim to simplify and standardize the transaction format within the Lightning Network, ensuring interoperability and privacy while implementing multi-party channels, facilitating transaction collaboration, and incorporating protocols like PSBT and RBF.