Explicit ordering of tx_signatures

The peer that sends `tx_signatures` first is taking a risk when they are
contributing to the channel funding: the other peer may never send their
`tx_signatures`, and the signer will need to double-spend themselves
to ensure that their funds are not locked.

The accepting node is more at risk here, as they don't choose who tries
to open channels to them, whereas an opening node who detects a
malicious accepting node can just go somewhere else to open a channel.

Thus by default, the opener should send their `tx_signatures` first, unless
they explicitly request the accepting node to go first because they are
trying to coordinate multiparty tx construction.

Author: t-bast

02-peer-protocol.md

@@ -381,10 +381,6 @@ the byte size of the input and output counts on the transaction to one (1).
 #### Requirements
 
 The sending node:
-  - if it has the lowest total satoshis contributed, as defined by total
-    `tx_add_input` values, or both peers have contributed equal amounts
-    but it has the lowest `node_id` (sorted lexicographically):
-    - MUST transmit their `tx_signatures` first
   - MUST order the `witnesses` by the `serial_id` of the input they
     correspond to
   - `num_witnesses`s MUST equal the number of inputs they added
@@ -401,10 +397,6 @@ The receiving node:
 
 #### Rationale
 
-A strict ordering is used to decide which peer sends `tx_signatures` first.
-This prevents deadlocks where each peer is waiting for the other peer to
-send `tx_signatures`, and enables multiparty tx collaboration.
-
 `witness_data` is the data for a witness element in a witness stack, not
 prefixed with its length (since it is already specified in the `len` field).
 
@@ -1118,6 +1110,9 @@ This message initiates the v2 channel establishment workflow.
    1. type: 2 (`require_confirmed_inputs`)
    2. data:
         * [`0*byte`:``]
+   1. type: 4 (`remote_tx_signatures_first`)
+   2. data:
+        * [`0*byte`:``]
 
 Rationale and Requirements are the same as for [`open_channel`](#the-open_channel-message),
 with the following additions.
@@ -1132,13 +1127,16 @@ The sending node:
   - MUST set `funding_feerate_perkw` to the feerate for this transaction
   - If it requires the receiving node to only use confirmed inputs:
     - MUST set `require_confirmed_inputs`
+  - If it requires the accepting node to send their `tx_signatures` first:
+    - MUST set `remote_tx_signatures_first`
 
 The receiving node:
   - MAY fail the negotiation if:
     - the `locktime` is unacceptable
     - the `funding_feerate_perkw` is unacceptable
   - MUST fail the negotiation if:
     - `require_confirmed_inputs` is set but it cannot provide confirmed inputs
+    - `remote_tx_signatures_first` is set, but it doesn't want to sign first
 
 #### Rationale
 
@@ -1169,6 +1167,19 @@ The sending node may require the other participant to only use confirmed inputs.
 This ensures that the sending node doesn't end up paying the fees of a low
 feerate unconfirmed ancestor of one of the other participant's inputs.
 
+A strict ordering is used to decide which peer will send `tx_signatures` first,
+based on whether `remote_tx_signatures_first` was set. This prevents deadlocks
+where each peer is waiting for the other peer to send `tx_signatures`, and
+enables multiparty tx collaboration. The opening node should set
+`remote_tx_signatures_first` when they are batching multiple interactive-tx
+sessions, as they will need to collect all signatures before forwarding
+them. If the accepting node contributes to the channel funding, they are
+taking a risk when they sign first: the opening node may never send their
+`tx_signatures`, which forces the accepting node to eventually double-spend
+themselves to avoid having their funds locked. The accepting node may be
+willing to take that risk if they are paid for contributing to the channel
+funding.
+
 ### The `accept_channel2` Message
 
 This message contains information about a node and indicates its
@@ -1296,24 +1307,25 @@ The receiving node:
     - MUST fail the negotiation
   - if it has not already transmitted its `commitment_signed`:
     - MUST send `commitment_signed`
-  - Otherwise:
-    - MUST send `tx_signatures` if it should sign first, as specified
-      in the [`tx_signatures` requirements](#the-tx_signatures-message)
 
 #### Rationale
 
 The first commitment transaction has no HTLCs.
 
 ### Sharing funding signatures: `tx_signatures`
 
-After a valid `commitment_signed` has been received
-from the peer and a `commitment_signed` has been sent, a peer:
-  - MUST transmit `tx_signatures` with their signatures for the funding
-    transaction, following the order specified in the
-    [`tx_signatures` requirements](#the-tx_signatures-message)
+After a valid `commitment_signed` has been received from the peer and a
+`commitment_signed` has been sent, peers exchange `tx_signatures` for the
+funding transaction.
 
 #### Requirements
 
+The opening node, if it has not set `open_channel2.remote_tx_signatures_first`:
+  - MUST send `tx_signatures` first
+
+The accepting node, if `open_channel2.remote_tx_signatures_first` was set:
+  - MUST send `tx_signatures` first
+
 The sending node:
   - MUST verify it has received a valid commitment signature from its peer
   - MUST remember the details of this funding transaction
@@ -1331,9 +1343,6 @@ The receiving node:
 
 #### Rationale
 
-A peer sends their `tx_signatures` after receiving a valid `commitment_signed`
-message, following the order specified in the [`tx_signatures` section](#the-tx_signatures-message).
-
 In the case where a peer provides valid witness data that causes their paid
 feerate to fall beneath the `open_channel2.funding_feerate_perkw`, the protocol
 should be aborted and the channel should be double-spent when there is a