From b570f226dc7e5a6ce68ac8f617dac16880d04ee8 Mon Sep 17 00:00:00 2001 From: niftynei Date: Tue, 8 Jun 2021 12:56:09 -0500 Subject: [PATCH] fixup! interactive-tx: Add dual-funding flow, using the interactive tx protocol Suggested-By: Antoine Riard @ariard --- 02-peer-protocol.md | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index ddbba31c5..ad721f3e7 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -221,7 +221,7 @@ The receiving node: - `prevtx` is not a valid transaction - `prevtx_vout` is greater or equal to the number of outputs on `prevtx` - the `prevtx_out` input of `prevtx` is not an `OP_0` to `OP_16` - followed by a single push + followed by a single push of 2 to 40 bytes - the `serial_id` is already included in the transaction - the `serial_id` has the wrong parity - if has received 4096 `tx_add_input` messages during this negotiation @@ -276,7 +276,8 @@ The receiving node: - the `serial_id` is already included in the transaction - the `serial_id` has the wrong parity - it has received 4096 `tx_add_output` messages during this negotiation - - the `sats` amount is less than or equal to the `dust_limit` + - the `sats` amount is less than the `dust_limit` + - the `sats` amount is greater than 21,0000,0000 (`MAX_MONEY`) #### Rationale @@ -346,6 +347,7 @@ The receiving node: - the *initiator*'s fees do not cover the `common` fields - there are more than 252 inputs - there are more than 252 outputs + - the estimated weight of the tx is greater than 400,000 (`MAX_STANDARD_TX_WEIGHT`) #### Rationale To signal the conclusion of exchange of transaction inputs and outputs. @@ -382,12 +384,18 @@ 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: + - MUST transmit their `tx_signatures` before the peer - MUST order the `witness_stack`s by the `serial_id` of the input they correspond to - number of `witness_stack`s MUST equal the number of inputs they added The receiving node: - MUST fail the negotiation if: + - if they have not sent a `tx_signatures` message and they are the + peer with the lowest total satoshis contributed, as defined by + `tx_add_input` values - the message contains an empty `witness_stack` - the number of `witness_stack`s does not equal the number of inputs added by the sending node @@ -400,6 +408,10 @@ The receiving node: #### Rationale +The counterparty with the lowest total of inputs amounts must transmit its +`tx_signatures` first. This gives in a strict ordering of transmission +for any multiparty tx collaboration. + `witness` is the data for a witness element in a witness stack. Witness elements should *not* include their length. @@ -844,7 +856,6 @@ The protocol is also expanded to include a mechanism for initiating RBF. ----| |<-(b)--- ack_rbf ------------| | | | | | | |--(7)--- funding_locked ----->| | -n- | |<-(8)--- funding_locked ------| | +-------+ +-------+ @@ -1139,7 +1150,9 @@ The sender: - MUST NOT have sent or received a `funding_locked` message The recipient: - - MUST either fail the negotiation or transmit a `tx_add_input` message + - MUST either fail the negotiation or transmit a `tx_add_input` message, + restarting the interactive tx collaboration protocol, and proceeding + the same as with `accept_channel2`. #### Rationale `funding_satoshis` is the amount of satoshis that this peer will