DRAFT: interactive tx construction protocol

The author discusses the use of PoDLEs (Proof of Discrete Logarithm Equivalence) in lightning transactions. In the case of an open channel, 'H2' field is included in the initiating message which represents a 32-byte hash commitment to the P2 key. Only one H2 commitment is required. The tx_add_input message is extended to include a TLV type that should be present on the input addition corresponding to the UTXO used for the transmitted commitment. If the proof is incorrect, the non-initiator may fail the transaction collaboration or respond with tx_complete. If the proof is correct, the non-initiator verifies that the commitment has not been communicated to them via gossip. If the proof is not in their gossip store, the transaction collaboration continues. If the proof IS in their gossip store, the transaction collaboration SHOULD reply with tx_complete.The initiator must not remove the committed to UTXO from the collaboration set. If the transaction collaboration fails/is errored by the initiator, the non-initiator SHOULD broadcast the original PoDLE commitment to the gossip network. The gossip message for a PoDLE blacklist entry includes signature, H2, node_id and timestamp. The JoinMarket protocol allows nodes to use any of a range of secondary points for J. It seems unnecessary to allow for more than one valid J point as the smaller the pool of eligible J's, the smaller the pool of potential blacklisted PoDLE's.Assuming that every node honestly participates in the blacklist, only verified H2's will be submitted to the blacklist. A malicious non-initiator can only prevent an honest initiator from using the committed UTXO for collaborative transactions; they won't prevent them from successfully initiating a one-sided transaction with honest peers. Duplicate H2 gossip should replace older timestamped versions. It's possible for gossip message floods to originate from a malicious peer. It is possible for a malicious peer to fail to relay their H2 entries in the blacklisted gossip set.The author discusses whether PoDLE should be required for every collaborative transaction or only for opens and also considers whether fixing the generator point is too restrictive. The JoinMarket protocol allows a UTXO to be used at most N times by appending a single byte to something that is hashed, and ensuring its value is less than N. There is no concrete answer on "when to delete old PoDLE". Watermarks like nLockTime, nSequence, nVersion are currently fixed values according to the author.JoinMarket is a tool that implements PayJoin, which involves anti-fee-sniping emulation. JoinMarket also aims to create similar feerates across its users. The use-case for JoinMarket is much like PayJoin, where the opener proposes to make a payment to a channel between themselves and the acceptor, rather than giving outright control to the acceptor as in PayJoin. This means that they probably want to consider nLockTime anti-fee-sniping in multi-funded channel opens. Multi-funded channel opens can also be used for channel factories through interactive transaction construction mechanisms, while PoDLE techniques would be useful for multi-funded channel factories. Sharing PoDLE format with JoinMarket could be beneficial so that there could be bridges that share PoDLEs between JoinMarket makers and Lightning nodes, as each network already has its own gossip protocols. It might be helpful to mandate retaining PoDLE for at least a year or a month or two weeks in some BOLT specification, which should be enough to slow down probe attempts.