diff --git a/.aspell.en.pws b/.aspell.en.pws
index 8b6e9dc05..a4d459d96 100644
--- a/.aspell.en.pws
+++ b/.aspell.en.pws
@@ -23,6 +23,7 @@ nhops
 retransmitted
 dev
 tradeoff
+kiloweight
 mixHeader
 uint
 hopsData
@@ -115,6 +116,17 @@ delayedsig
 hopDataSize
 I'th
 segwit
+RBF
+accepter
+accepter's
+subtype
+redeemScript
+scriptSig
+utxo
+scriptPubKey
+scriptPubKeys
+scriptlen
+sats
 htlc
 htlcs
 ChaCha
@@ -401,5 +413,14 @@ pkh
 kB
 unblind
 unblinded
-accepter
-kiloweight
+workflow
+PUSHDATA
+prev
+vout
+rbf
+standardness
+perkw
+prevtx
+ints
+replaceability
+disincentivize
diff --git a/01-messaging.md b/01-messaging.md
index a602d40b5..f7e38f758 100644
--- a/01-messaging.md
+++ b/01-messaging.md
@@ -344,14 +344,22 @@ For simplicity of diagnosis, it's often useful to tell a peer that something is
 
 The channel is referred to by `channel_id`, unless `channel_id` is 0 (i.e. all bytes are 0), in which case it refers to all channels.
 
-The funding node:
+The funding node using channel establishment v1 (`open_channel`):
   - for all error messages sent before (and including) the `funding_created` message:
     - MUST use `temporary_channel_id` in lieu of `channel_id`.
 
-The fundee node:
+The fundee node using channel establishment v1 (`accept_channel`):
   - for all error messages sent before (and not including) the `funding_signed` message:
     - MUST use `temporary_channel_id` in lieu of `channel_id`.
 
+The opener node using channel establishment v2 (`open_channel2`):
+  - for all error messages sent before the `accept_channel2` message is received:
+    - MUST use `temporary_channel_id` in lieu of `channel_id`.
+
+The accepter node using channel establishment v2 (`open_channel2`):
+  - for all error messages sent before (and including) the `accept_channel2` message:
+    - MUST use `temporary_channel_id` in lieu of `channel_id`.
+
 A sending node:
   - SHOULD send `error` for protocol violations or internal errors that make channels unusable or that make further communication unusable.
   - SHOULD send `error` with the unknown `channel_id` in reply to messages of type `32`-`255` related to unknown channels.
diff --git a/02-peer-protocol.md b/02-peer-protocol.md
index d484b4891..4141665af 100644
--- a/02-peer-protocol.md
+++ b/02-peer-protocol.md
@@ -7,12 +7,31 @@ operation, and closing.
 
   * [Channel](#channel)
     * [Definition of `channel_id`](#definition-of-channel_id)
-    * [Channel Establishment](#channel-establishment)
+    * [Interactive Transaction Construction](#interactive-transaction-construction)
+      * [Set-Up and Vocabulary](#set-up-and-vocabulary)
+      * [Fee Responsibility](#fee-responsibility)
+      * [Overview](#overview)
+      * [The `tx_add_input` Message](#the-tx_add_input-message)
+      * [The `tx_add_output` Message](#the-tx_add_output-message)
+      * [The `tx_remove_input` and `tx_remove_output` Messages](#the-tx_remove_input-and-tx_remove_output-messages)
+      * [The `tx_complete` Message](#the-tx_complete-message)
+      * [The `tx_signatures` Message](#the-tx_signatures-message)
+      * [The `tx_init_rbf` Message](#the-tx_init_rbf-message)
+      * [The `tx_ack_rbf` Message](#the-tx_ack_rbf-message)
+      * [The `tx_abort` Message](#the-tx_abort-message)
+    * [Channel Establishment v1](#channel-establishment-v1)
       * [The `open_channel` Message](#the-open_channel-message)
       * [The `accept_channel` Message](#the-accept_channel-message)
       * [The `funding_created` Message](#the-funding_created-message)
       * [The `funding_signed` Message](#the-funding_signed-message)
       * [The `channel_ready` Message](#the-channel_ready-message)
+    * [Channel Establishment v2](#channel-establishment-v2)
+      * [The `open_channel2` Message](#the-open_channel2-message)
+      * [The `accept_channel2` Message](#the-accept_channel2-message)
+      * [Funding Composition](#funding-composition)
+      * [The `commitment_signed` Message](#the-commitment_signed-message)
+      * [Sharing funding signatures: `tx_signatures`](#sharing-funding-signatures-tx_signatures)
+      * [Fee bumping: `tx_init_rbf` and `tx_ack_rbf`](#fee-bumping-tx_init_rbf-and-tx_ack_rbf)
     * [Channel Close](#channel-close)
       * [Closing Initiation: `shutdown`](#closing-initiation-shutdown)
       * [Closing Negotiation: `closing_signed`](#closing-negotiation-closing_signed)
@@ -49,11 +68,439 @@ transaction is confirmed are also not persistent - until you know the script
 pubkey corresponding to the funding output nothing prevents duplicative channel
 ids.
 
+### `channel_id`, v2
 
-## Channel Establishment
+For channels established using the v2 protocol, the `channel_id` is the
+`SHA256(lesser-revocation-basepoint || greater-revocation-basepoint)`,
+where the lesser and greater is based off the order of the basepoint.
+
+When sending `open_channel2`, the peer's revocation basepoint is unknown.
+A `temporary_channel_id` must be computed by using a zeroed out basepoint
+for the non-initiator.
+
+When sending `accept_channel2`, the `temporary_channel_id` from `open_channel2`
+must be used, to allow the initiator to match the response to its request.
+
+#### Rationale
+
+The revocation basepoints must be remembered by both peers for correct
+operation anyway. They're known after the first exchange of messages,
+obviating the need for a `temporary_channel_id` in subsequent messages.
+By mixing information from both sides, they avoid `channel_id` collisions,
+and they remove the dependency on the funding txid.
+
+## Interactive Transaction Construction
+
+Interactive transaction construction allows two peers to collaboratively
+build a transaction for broadcast.  This protocol is the foundation
+for dual-funded channels establishment (v2).
+
+### Set-Up and Vocabulary
+
+There are two parties to a transaction construction: an *initiator*
+and a *non-initiator*.
+The *initiator* is the peer which initiates the protocol, e.g.
+for channel establishment v2 the *initiator* would be the peer which
+sends `open_channel2`.
+
+The protocol makes the following assumptions:
+
+- The `feerate` for the transaction is known.
+- The `dust_limit` for the transaction is known.
+- The `nLocktime` for the transaction is known.
+- The `nVersion` for the transaction is known.
+
+### Fee Responsibility
+
+The *initiator* is responsible for paying the fees for the following fields,
+to be referred to as the `common fields`.
+
+  - version
+  - segwit marker + flag
+  - input count
+  - output count
+  - locktime
+
+The rest of the transaction bytes' fees are the responsibility of
+the peer who contributed that input or output via `tx_add_input` or
+`tx_add_output`, at the agreed upon `feerate`.
+
+### Overview
+
+The *initiator* initiates the interactive transaction construction
+protocol with `tx_add_input`. The *non-initiator* responds with any
+of `tx_add_input`, `tx_add_output`, `tx_remove_input`, `tx_remove_output`, or
+`tx_complete`. The protocol continues with the synchronous exchange
+of interactive transaction protocol messages until both nodes have sent
+and received a consecutive `tx_complete`. This is a turn-based protocol.
+
+Once peers have exchanged consecutive `tx_complete`s, the
+interactive transaction construction protocol is considered concluded.
+Both peers should construct the transaction and fail the negotiation
+if an error is discovered.
+
+This protocol is expressly designed to allow for parallel, multi-party
+sessions to collectively construct a single transaction. This preserves
+the ability to open multiple channels in a single transaction. While
+`serial_id`s are generally chosen randomly, to maintain consistent transaction
+ordering across all peer sessions, it is simplest to reuse received
+`serial_id`s when forwarding them to other peers, inverting the bottom bit as
+necessary to satisfy the parity requirement.
+
+Here are a few example exchanges.
+
+#### *initiator* only
+
+A, the *initiator*, has two inputs and an output (the funding output).
+B, the *non-initiator* has nothing to contribute.
+
+        +-------+                       +-------+
+        |       |--(1)- tx_add_input -->|       |
+        |       |<-(2)- tx_complete ----|       |
+        |       |--(3)- tx_add_input -->|       |
+        |   A   |<-(4)- tx_complete ----|   B   |
+        |       |--(5)- tx_add_output ->|       |
+        |       |<-(6)- tx_complete ----|       |
+        |       |--(7)- tx_complete --->|       |
+        +-------+                       +-------+
+
+#### *initiator* and *non-initiator*
+
+A, the *initiator*, contributes 2 inputs and an output that they
+then remove.  B, the *non-initiator*, contributes 1 input and an output,
+but waits until A adds a second input before contributing.
+
+Note that if A does not send a second input, the negotiation will end without
+B's contributions.
+
+        +-------+                         +-------+
+        |       |--(1)- tx_add_input ---->|       |
+        |       |<-(2)- tx_complete ------|       |
+        |       |--(3)- tx_add_output --->|       |
+        |       |<-(4)- tx_complete ------|       |
+        |       |--(5)- tx_add_input ---->|       |
+        |   A   |<-(6)- tx_add_input -----|   B   |
+        |       |--(7)- tx_remove_output >|       |
+        |       |<-(8)- tx_add_output ----|       |
+        |       |--(9)- tx_complete ----->|       |
+        |       |<-(10) tx_complete ------|       |
+        +-------+                         +-------+
+
+### The `tx_add_input` Message
+
+This message contains a transaction input.
+
+1. type: 66 (`tx_add_input`)
+2. data:
+    * [`channel_id`:`channel_id`]
+    * [`u64`:`serial_id`]
+    * [`u16`:`prevtx_len`]
+    * [`prevtx_len*byte`:`prevtx`]
+    * [`u32`:`prevtx_vout`]
+    * [`u32`:`sequence`]
+
+#### Requirements
+
+The sending node:
+  - MUST add all sent inputs to the transaction
+  - MUST use a unique `serial_id` for each input currently added to the
+    transaction
+  - MUST set `sequence` to be less than or equal to 4294967293 (`0xFFFFFFFD`)
+  - MUST NOT re-transmit inputs it has received from the peer
+  - if is the *initiator*:
+    - MUST send even `serial_id`s
+  - if is the *non-initiator*:
+    - MUST send odd `serial_id`s
+
+The receiving node:
+  - MUST add all received inputs to the transaction
+  - MUST fail the negotiation if:
+    - `sequence` is set to `0xFFFFFFFE` or `0xFFFFFFFF`
+    - the `prevtx` and `prevtx_vout` are identical to a previously added
+      (and not removed) input's
+    - `prevtx` is not a valid transaction
+    - `prevtx_vout` is greater or equal to the number of outputs on `prevtx`
+    - the `scriptPubKey` of the `prevtx_vout` output of `prevtx` is not exactly a 1-byte push opcode (for the numeric values `0` to `16`) followed by a data push between 2 and 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
+
+#### Rationale
+
+Each node must know the set of the transaction inputs. The *non-initiator*
+MAY omit this message.
+
+`serial_id` is a randomly chosen number which uniquely identifies this input.
+Inputs in the constructed transaction are sorted by `serial_id`.
+
+`prevtx` is the serialized transaction that contains the output
+this input spends. Used to verify that the input is non-malleable.
+
+`prevtx_vout` is the index of the output being spent.
+
+`sequence` is the sequence number of this input: it must signal
+replaceability, and the same value should be used across implementations
+to avoid on-chain fingerprinting.
+
+### The `tx_add_output` Message
+
+This message adds a transaction output.
+
+1. type: 67 (`tx_add_output`)
+2. data:
+    * [`channel_id`:`channel_id`]
+    * [`u64`:`serial_id`]
+    * [`u64`:`sats`]
+    * [`u16`:`scriptlen`]
+    * [`scriptlen*byte`:`script`]
+
+#### Requirements
+
+Either node:
+  - MAY omit this message
+
+The sending node:
+  - MUST add all sent outputs to the transaction
+  - if is the *initiator*:
+    - MUST send even `serial_id`s
+  - if is the *non-initiator*:
+    - MUST send odd `serial_id`s
+
+The receiving node:
+  - MUST add all received outputs to the transaction
+  - MUST accept P2WSH, P2WPKH, P2TR `script`s
+  - MAY fail the negotiation if `script` is non-standard
+  - MUST fail the negotiation if:
+    - 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 the `dust_limit`
+    - the `sats` amount is greater than 2,100,000,000,000,000 (`MAX_MONEY`)
+
+#### Rationale
+
+Each node must know the set of the transaction outputs.
+
+`serial_id` is a randomly chosen number which uniquely identifies this output.
+Outputs in the constructed transaction are sorted by `serial_id`.
+
+`sats` is the satoshi value of the output.
+
+`script` is the scriptPubKey for the output (with its length omitted).
+`script`s are not required to follow standardness rules: non-standard
+scripts such as `OP_RETURN` may be accepted, but the corresponding
+transaction may fail to relay across the network.
+
+### The `tx_remove_input` and `tx_remove_output` Messages
+
+This message removes an input from the transaction.
+
+1. type: 68 (`tx_remove_input`)
+2. data:
+    * [`channel_id`:`channel_id`]
+    * [`u64`:`serial_id`]
+
+This message removes an output from the transaction.
+
+1. type: 69 (`tx_remove_output`)
+2. data:
+    * [`channel_id`:`channel_id`]
+    * [`u64`:`serial_id`]
+
+#### Requirements
+
+The sending node:
+  - MUST NOT send a `tx_remove` with a `serial_id` it did not add
+    to the transaction or has already been removed
+
+The receiving node:
+  - MUST remove the indicated input or output from the transaction
+  - MUST fail the negotiation if:
+    - the input or output identified by the `serial_id` was not added by the
+      sender
+    - the `serial_id` does not correspond to a currently added input (or output)
+
+### The `tx_complete` Message
+
+This message signals the conclusion of a peer's transaction
+contributions.
+
+1. type: 70 (`tx_complete`)
+2. data:
+    * [`channel_id`:`channel_id`]
+
+#### Requirements
+
+The nodes:
+  - MUST send this message in succession to conclude this protocol
+
+The receiving node:
+  - MUST use the negotiated inputs and outputs to construct a transaction
+  - MUST fail the negotiation if:
+    - the peer's total input satoshis is less than their outputs
+    - the peer's paid feerate does not meet or exceed the agreed `feerate`
+      (based on the `minimum fee`).
+    - if is the *non-initiator*:
+      - 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.
+
+Upon successful exchange of `tx_complete` messages, both nodes
+should construct the transaction and proceed to the next portion of the
+protocol. For channel establishment v2, exchanging commitment transactions.
+
+For the `minimum fee` calculation see [BOLT #3](03-transactions.md#calculating-fees-for-collaborative-transaction-construction).
+
+The maximum inputs and outputs are capped at 252. This effectively fixes
+the byte size of the input and output counts on the transaction to one (1).
+
+### The `tx_signatures` Message
+
+1. type: 71 (`tx_signatures`)
+2. data:
+    * [`channel_id`:`channel_id`]
+    * [`sha256`:`txid`]
+    * [`u16`:`num_witnesses`]
+    * [`num_witnesses*witness_stack`:`witnesses`]
+
+1. subtype: `witness_stack`
+2. data:
+    * [`u16`:`num_witness_elements`]
+    * [`num_witness_elements*witness_element`:`witness_elements`]
+
+1. subtype: `witness_element`
+2. data:
+    * [`u16`:`len`]
+    * [`len*byte`:`witness_data`]
+
+#### 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
+
+The receiving node:
+  - MUST fail the negotiation if:
+    - the message contains an empty `witness_stack`
+    - the number of `witnesses` does not equal the number of inputs
+      added by the sending node
+    - the `txid` does not match the txid of the transaction
+    - the witnesses are non-standard
+  - SHOULD apply the `witnesses` to the transaction and broadcast it
+  - MUST reply with their `tx_signatures` if not already transmitted
+
+#### 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).
+
+While the `minimum fee` is calculated and verified at `tx_complete` conclusion,
+it is possible for the fee for the exchanged witness data to be underpaid.
+It is the responsibility of the sending peer to correctly account for the
+required fee, e.g. a multisig witness stack whose weight exceeds 107.
+
+### The `tx_init_rbf` Message
+
+This message initiates a replacement of the transaction after it's been
+completed.
+
+1. type: 72 (`tx_init_rbf`)
+2. data:
+   * [`channel_id`:`channel_id`]
+   * [`u32`:`locktime`]
+   * [`u32`:`feerate`]
+   * [`tx_init_rbf_tlvs`:`tlvs`]
+
+1. `tlv_stream`: `tx_init_rbf_tlvs`
+2. types:
+    1. type: 0 (`funding_output_contribution`)
+    2. data:
+        * [`tu64`:`satoshis`]
+
+#### Requirements
+
+The sender:
+  - MUST set `feerate` greater than or equal to 25/24 times the `feerate`
+    of the previously constructed transaction, rounded down.
+
+The recipient:
+  - MUST respond either by failing the negotiation or with `tx_ack_rbf`.
+  - MUST fail the negotiation if:
+    - the `feerate` is not greater than 25/24 times `feerate` of the last
+      successfully constructed transaction
+  - MAY fail the negotiation for any reason
+
+#### Rationale
+
+`feerate` is the feerate this transaction will pay. It must be at least
+1/24 greater than the last used `feerate`, rounded down to the nearest
+satoshi to ensure there is progress.
+
+E.g. if the last `feerate` was 520, the next sent `feerate` must be 541
+(520 * 25 / 24 = 541.667, rounded down to 541).
+
+If the previous transaction confirms in the middle of an RBF attempt,
+the attempt MUST be abandoned.
+
+`funding_output_contribution` is the amount of satoshis that this peer
+will contribute to the funding output of the transaction, when there is
+such an output. Note that it may be different from the contribution
+made in the previously completed transaction.
+
+### The `tx_ack_rbf` Message
+
+1. type: 73 (`tx_ack_rbf`)
+2. data:
+   * [`channel_id`:`channel_id`]
+   * [`tx_ack_rbf_tlvs`:`tlvs`]
+
+1. `tlv_stream`: `tx_ack_rbf_tlvs`
+2. types:
+    1. type: 0 (`funding_output_contribution`)
+    2. data:
+        * [`tu64`:`satoshis`]
+
+#### Requirements
+
+The recipient:
+  - MUST either fail the negotiation or transmit a `tx_add_input` message,
+    restarting the interactive tx collaboration protocol.
+
+#### Rationale
+
+`funding_output_contribution` is the amount of satoshis that this peer
+will contribute to the funding output of the transaction, when there is
+such an output. Note that it may be different from the contribution
+made in the previously completed transaction.
+
+It's recommended that a peer, rather than fail the RBF negotiation due to
+a large feerate change, instead sets their `funding_output_contribution` to
+zero, and decline to participate further in the transaction (by not
+contributing, they may obtain incoming liquidity at no cost).
+
+## Channel Establishment v1
 
 After authenticating and initializing a connection ([BOLT #8](08-transport.md)
 and [BOLT #1](01-messaging.md#the-init-message), respectively), channel establishment may begin.
+
+There are two pathways for establishing a channel, a legacy version presented here,
+and a second version ([below](#channel-establishment-v2)). Which channel
+establishment protocols are available for use is negotiated in the `init` message.
+
 This consists of the funding node (funder) sending an `open_channel` message,
 followed by the responding node (fundee) sending `accept_channel`. With the
 channel parameters locked in, the funder is able to create the funding
@@ -258,6 +705,8 @@ The receiving node MUST:
  `open_channel`, BUT before receiving a `funding_created` message:
     - accept a new `open_channel` message.
     - discard the previous `open_channel` message.
+  - if `option_dual_fund` has been negotiated:
+    - fail the channel.
 
 The receiving node MAY fail the channel if:
   - `option_channel_type` was negotiated but the message doesn't include a `channel_type`
@@ -560,6 +1009,309 @@ ones it has sent so it can use them should they be requested by
 incoming HTLCs.  The recipient only need remember one, for use in
 `r` route hints in BOLT 11 invoices.
 
+If an RBF negotiation is in progress when a `channel_ready` message is
+exchanged, the negotiation must be abandoned.
+
+## Channel Establishment v2
+
+This is a revision of the channel establishment protocol.
+It changes the previous protocol to allow the `accept_channel2` peer
+(the *accepter*/*non-initiator*) to contribute inputs to the funding
+transaction, via the interactive transaction construction protocol.
+
+        +-------+                              +-------+
+        |       |--(1)--- open_channel2  ----->|       |
+        |       |<-(2)--- accept_channel2 -----|       |
+        |       |                              |       |
+    --->|       |      <tx collaboration>      |       |
+    |   |       |                              |       |
+    |   |       |--(3)--  commitment_signed -->|       |
+    |   |       |<-(4)--  commitment_signed ---|       |
+    |   |   A   |                              |   B   |
+    |   |       |<-(5)--  tx_signatures -------|       |
+    |   |       |--(6)--  tx_signatures ------>|       |
+    |   |       |                              |       |
+    |   |       |--(a)--- tx_init_rbf -------->|       |
+    ----|       |<-(b)--- tx_ack_rbf ----------|       |
+        |       |                              |       |
+        |       |    <tx rbf collaboration>    |       |
+        |       |                              |       |
+        |       |--(c)--  commitment_signed -->|       |
+        |       |<-(d)--  commitment_signed ---|       |
+        |       |                              |       |
+        |       |<-(e)--  tx_signatures -------|       |
+        |       |--(f)--  tx_signatures ------>|       |
+        |       |                              |       |
+        |       |--(7)--- channel_ready  ----->|       |
+        |       |<-(8)--- channel_ready  ------|       |
+        +-------+                              +-------+
+
+        - where node A is *opener*/*initiator* and node B is
+          *accepter*/*non-initiator*
+
+### The `open_channel2` Message
+
+This message initiates the v2 channel establishment workflow.
+
+1. type: 64 (`open_channel2`)
+2. data:
+   * [`chain_hash`:`chain_hash`]
+   * [`channel_id`:`temporary_channel_id`]
+   * [`u32`:`funding_feerate_perkw`]
+   * [`u32`:`commitment_feerate_perkw`]
+   * [`u64`:`funding_satoshis`]
+   * [`u64`:`dust_limit_satoshis`]
+   * [`u64`:`max_htlc_value_in_flight_msat`]
+   * [`u64`:`htlc_minimum_msat`]
+   * [`u16`:`to_self_delay`]
+   * [`u16`:`max_accepted_htlcs`]
+   * [`u32`:`locktime`]
+   * [`point`:`funding_pubkey`]
+   * [`point`:`revocation_basepoint`]
+   * [`point`:`payment_basepoint`]
+   * [`point`:`delayed_payment_basepoint`]
+   * [`point`:`htlc_basepoint`]
+   * [`point`:`first_per_commitment_point`]
+   * [`byte`:`channel_flags`]
+   * [`opening_tlvs`:`tlvs`]
+
+1. `tlv_stream`: `opening_tlvs`
+2. types:
+   1. type: 0 (`upfront_shutdown_script`)
+   2. data:
+       * [`...*byte`:`shutdown_scriptpubkey`]
+   1. type: 1 (`channel_type`)
+   2. data:
+        * [`...*byte`:`type`]
+
+Rationale and Requirements are the same as for [`open_channel`](#the-open_channel-message),
+with the following additions.
+
+#### Requirements
+
+If nodes have negotiated `option_dual_fund`:
+  - the opening node:
+    - MUST NOT send `open_channel`
+
+The sending node:
+  - MUST set `funding_feerate_perkw` to the feerate for this transaction
+
+The receiving node:
+  - MAY fail the negotiation if:
+    - the `locktime` is unacceptable
+    - the `funding_feerate_perkw` is unacceptable
+
+#### Rationale
+
+`temporary_channel_id` MUST be derived using a zeroed out basepoint for the
+peer's revocation basepoint. This allows the peer to return channel-assignable
+errors before the *accepter*'s revocation basepoint is known.
+
+`funding_feerate_perkw` indicates the fee rate that the opening node will
+pay for the funding transaction in satoshi per 1000-weight, as described
+in [BOLT-3, Appendix F](03-transactions.md#appendix-f-dual-funded-transaction-test-vectors).
+
+`locktime` is the locktime for the funding transaction.
+
+The receiving node, if the `locktime` or `funding_feerate_perkw` is considered
+out of an acceptable range, may fail the negotiation. However, it is
+recommended that the *accepter* permits the channel open to proceed
+without their participation in the channel's funding.
+
+Note that `open_channel`'s `channel_reserve_satoshi` has been omitted.
+Instead, the channel reserve is fixed at 1% of the total channel balance
+(`open_channel2`.`funding_satoshis` + `accept_channel2`.`funding_satoshis`)
+rounded down to the nearest whole satoshi or the `dust_limit_satoshis`,
+whichever is greater.
+
+Note that `push_msat` has been omitted.
+
+### The `accept_channel2` Message
+
+This message contains information about a node and indicates its
+acceptance of the new channel.
+
+1. type: 65 (`accept_channel2`)
+2. data:
+    * [`channel_id`:`temporary_channel_id`]
+    * [`u64`:`funding_satoshis`]
+    * [`u64`:`dust_limit_satoshis`]
+    * [`u64`:`max_htlc_value_in_flight_msat`]
+    * [`u64`:`htlc_minimum_msat`]
+    * [`u32`:`minimum_depth`]
+    * [`u16`:`to_self_delay`]
+    * [`u16`:`max_accepted_htlcs`]
+    * [`point`:`funding_pubkey`]
+    * [`point`:`revocation_basepoint`]
+    * [`point`:`payment_basepoint`]
+    * [`point`:`delayed_payment_basepoint`]
+    * [`point`:`htlc_basepoint`]
+    * [`point`:`first_per_commitment_point`]
+    * [`accept_tlvs`:`tlvs`]
+
+1. `tlv_stream`: `accept_tlvs`
+2. types:
+   1. type: 0 (`upfront_shutdown_script`)
+   2. data:
+       * [`...*byte`:`shutdown_scriptpubkey`]
+   1. type: 1 (`channel_type`)
+   2. data:
+        * [`...*byte`:`type`]
+
+Rationale and Requirements are the same as listed above,
+for [`accept_channel`](#the-accept_channel-message) with the following
+additions.
+
+#### Requirements
+
+The accepting node:
+  - MUST use the `temporary_channel_id` of the `open_channel2` message
+  - MAY respond with a `funding_satoshis` value of zero.
+
+#### Rationale
+
+The `funding_satoshis` is the amount of bitcoin in satoshis
+the *accepter* will be contributing to the channel's funding transaction.
+
+Note that `accept_channel`'s `channel_reserve_satoshi` has been omitted.
+Instead, the channel reserve is fixed at 1% of the total channel balance
+(`open_channel2`.`funding_satoshis` + `accept_channel2`.`funding_satoshis`)
+rounded down to the nearest whole satoshi or the `dust_limit_satoshis`,
+whichever is greater.
+
+### Funding Composition
+
+Funding composition for channel establishment v2 makes use of the
+[Interactive Transaction Construction](#interactive-transaction-construction)
+protocol, with the following additional caveats.
+
+#### The `tx_add_input` Message
+
+No additional caveats or requirements.
+
+#### The `tx_add_output` Message
+
+##### Requirements
+
+The sending node:
+  - if is the *opener*:
+    - MUST send at least one `tx_add_output`,  which contains the
+      channel's funding output
+
+##### Rationale
+
+The channel funding output must be added by the *opener*, who pays its fees.
+
+#### The `tx_complete` Message
+
+Upon receipt of consecutive `tx_complete`s, the receiving node:
+  - if is the *accepter*:
+    - MUST fail the negotiation if:
+      - no funding output was received
+      - the value of the funding output is not equal to the sum of
+        `open_channel2`.`funding_satoshis` and `accept_channel2`.
+        `funding_satoshis`
+      - the value of the funding output is less than the `dust_limit`
+ - if it is an RBF attempt:
+    - MUST fail the negotiation if:
+      - the transaction's total fees is less than the last
+        successfully negotiated transaction's fees
+      - the transaction does not share a common input with all previous
+        funding transactions
+
+### The `commitment_signed` Message
+
+This message is exchanged by both peers. It contains the signatures for
+the first commitment transaction.
+
+Rationale and Requirements are the same as listed below,
+for [`commitment_signed`](#commiting-updates-so-far-commitment_signed) with the following additions.
+
+#### Requirements
+
+The sending node:
+  - MUST send zero HTLCs.
+
+The receiving node:
+  - if the message has one or more HTLCs:
+    - 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)
+
+#### Requirements
+
+The sending node:
+  - MUST verify it has received a valid commitment signature from its peer
+  - MUST remember the details of this funding transaction
+  - if it has NOT received a valid `commitment_signed` message:
+    - MUST NOT send a `tx_signatures` message
+
+The receiving node:
+  - if the `witness_stack` weight lowers the effective `feerate`
+    below the the *opener*'s feerate for the funding transaction:
+    - SHOULD broadcast their commitment transaction, closing the channel.
+  - SHOULD apply `witnesses` to the funding transaction and broadcast it
+  - if has already sent or received a `channel_ready` message for this
+    channel:
+    - MUST ignore this message
+
+#### 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
+productive opportunity to do so. This should disincentivize peers from
+underpaying fees.
+
+### Fee bumping: `tx_init_rbf` and `tx_ack_rbf`
+
+After the funding transaction has been broadcast, it can be replaced by
+a transaction paying more fees to make the channel confirm faster.
+
+#### Requirements
+
+The sender of `tx_init_rbf`:
+  - MUST be the *initiator*
+  - MUST NOT have sent or received a `channel_ready` message.
+
+The recipient:
+  - MUST fail the negotiation if they have already sent or received
+    `channel_ready`
+  - MAY fail the negotiation for any reason
+
+#### Rationale
+
+If a valid `channel_ready` message is received in the middle of an
+RBF attempt, the attempt MUST be abandoned.
+
+Peers can use different values in `tx_init_rbf.funding_output_contribution`
+and `tx_ack_rbf.funding_output_contribution` from the amounts transmitted
+in `open_channel2` and `accept_channel2`: they are allowed to change how
+much they wish to commit to the funding output.
+
+It's recommended that a peer, rather than fail the RBF negotiation due to
+a large feerate change, instead sets their `sats` to zero, and decline to
+participate further in the channel funding: by not contributing, they
+may obtain incoming liquidity at no cost.
+
 ## Channel Close
 
 Nodes can negotiate a mutual close of the connection, which unlike a
@@ -1526,11 +2278,13 @@ A node:
   - if `next_commitment_number` is 1 in both the `channel_reestablish` it
   sent and received:
     - MUST retransmit `channel_ready`.
+    - MUST retransmit `tx_signatures` if it is using channel establishment v2.
   - otherwise:
     - MUST NOT retransmit `channel_ready`, but MAY send `channel_ready` with
       a different `short_channel_id` `alias` field.
   - upon reconnection:
     - MUST ignore any redundant `channel_ready` it receives.
+    - MUST ignore any redundant `tx_signatures` it receives.
   - if `next_commitment_number` is equal to the commitment number of
   the last `commitment_signed` message the receiving node has sent:
     - MUST reuse the same commitment number for its next `commitment_signed`.
diff --git a/03-transactions.md b/03-transactions.md
index a8e843ff9..4ebd028b8 100644
--- a/03-transactions.md
+++ b/03-transactions.md
@@ -21,6 +21,7 @@ This details the exact format of on-chain transactions, which both sides need to
     * [Fees](#fees)
         * [Fee Calculation](#fee-calculation)
         * [Fee Payment](#fee-payment)
+        * [Calculating Fees for Collaborative Transactions](#calculating-fees-for-collaborative-transactions)
     * [Dust Limits](#dust-limits)
     * [Commitment Transaction Construction](#commitment-transaction-construction)
   * [Keys](#keys)
@@ -30,6 +31,7 @@ This details the exact format of on-chain transactions, which both sides need to
         * [Per-commitment Secret Requirements](#per-commitment-secret-requirements)
     * [Efficient Per-commitment Secret Storage](#efficient-per-commitment-secret-storage)
   * [Appendix A: Expected Weights](#appendix-a-expected-weights)
+      * [Expected Weight of the Funding Transaction (v2 Channel Establishment)](#expected-weight-of-the-funding-transaction-v2-channel-establishment)
       * [Expected Weight of the Commitment Transaction](#expected-weight-of-the-commitment-transaction)
       * [Expected Weight of HTLC-timeout and HTLC-success Transactions](#expected-weight-of-htlc-timeout-and-htlc-success-transactions)
   * [Appendix B: Funding Transaction Test Vectors](#appendix-b-funding-transaction-test-vectors)
@@ -40,6 +42,7 @@ This details the exact format of on-chain transactions, which both sides need to
   * [Appendix E: Key Derivation Test Vectors](#appendix-e-key-derivation-test-vectors)
   * [Appendix F: Commitment and HTLC Transaction Test Vectors (anchors)](#appendix-f-commitment-and-htlc-transaction-test-vectors-anchors)
   * [Appendix G: Commitment and HTLC Transaction Test Vectors (anchors-zero-fee-htlc-tx)](#appendix-g-commitment-and-htlc-transaction-test-vectors-anchors_zero_fee_htlc_tx)
+  * [Appendix H: Dual Funded Transaction Test Vectors](#appendix-h-dual-funded-transaction-test-vectors)
   * [References](#references)
   * [Authors](#authors)
 
@@ -489,6 +492,12 @@ A node:
     - MAY send a `warning` and close the connection, or send an
       `error` and fail the channel.
 
+### Calculating Fees for Collaborative Transactions
+
+For transactions constructed using the [interactive protocol](02-peer-protocol.md#interactive-transaction-construction),
+fees are paid by each party to the transaction, at a `feerate` determined during the
+initiation, with the initiator covering the fees for the common transaction fields.
+
 ## Dust Limits
 
 The `dust_limit_satoshis` parameter is used to configure the threshold below
@@ -828,6 +837,101 @@ at each bucket is a prefix of the desired index.
 
 # Appendix A: Expected Weights
 
+## Expected Weight of the Funding Transaction (v2 Channel Establishment)
+
+The *expected weight* of a funding transaction is calculated as follows:
+
+      inputs: 41 bytes
+        - previous_out_point: 36 bytes
+          - hash: 32 bytes
+          - index: 4 bytes
+        - var_int: 1 byte
+        - script_sig: 0 bytes
+        - witness <---- Cost for "witness" data calculated separately.
+        - sequence: 4 bytes
+
+      non_funding_outputs: 9 bytes + `scriptlen`
+        - value: 8 bytes
+        - var_int: 1 byte <---- assuming a standard output script
+        - script: `scriptlen`
+
+      funding_output: 43 bytes
+        - value: 8 bytes
+        - var_int: 1 byte
+        - script: 34 bytes
+          - OP_0: 1 byte
+          - PUSHDATA(32-byte-hash): 33 bytes
+
+Multiplying non-witness data by 4 results in a weight of:
+
+      // transaction_fields = 10 (version, input count, output count, locktime)
+      // segwit_fields = 2 (marker + flag)
+      // funding_transaction = 43 + num_inputs * 41 + num_outputs * 9 + sum(scriptlen)
+      funding_transaction_weight = 4 * (funding_transaction + transaction_fields) + segwit_fields
+
+      witness_weight = sum(witness_len)
+
+      overall_weight = funding_transaction_weight + witness_weight
+
+### Calculating Fees for Collaborative Transaction Construction
+
+Every participant in a collaborative transaction covers the fees for
+their own inputs and outputs. The initiator also provides funds to
+cover for the common transaction fields.
+
+Upon successful exchange of `tx_complete` messages, each peer must at
+least cover a minimum estimated fee. Here is how to calculate the minimum
+fee for each participant.
+
+The minimum witness weight for an input is 107.
+
+In the following, the initiator has provided one input (P2WPKH), one change output
+(P2WPKH), and the funding output. The contributor has provided two
+inputs (P2WPKH) and two change outputs (P2WPKH).
+
+Assuming a `feerate` of 253 per kiloweight, the initiator's minimum fee is
+calculated as follows.  Note that the feerate is rounded up to the nearest satoshi.
+
+    initiator_weight = transaction_fields * 4
+                     + segwit_fields
+                     + p2wpkh_input * 4
+                     + funding_output * 4
+                     + p2wpkh_output * 4
+                     + input_count * 107 (minimum witness weight)
+
+    initiator_weight = 10 * 4
+                     + 2
+                     + 41 * 4
+                     + 43 * 4
+                     + 31 * 4
+                     + 107
+
+    initiator_weight = 609
+
+    initiator_fees = initiator_weight * feerate
+    initiator_fees = 609 * 253 / 1000
+    initiator_fees = 155 sats
+
+The contributor's minimum fee is calculated as follows.
+
+    contributor_weight = 2 * p2wpkh_input * 4
+                       + 2 * p2wpkh_output * 4
+                       + input_count * 107 (minimum witness weight)
+
+    contributor_weight = 2 * 41 * 4
+                       + 2 * 31 * 4
+                       + 2 * 107
+
+    contributor_weight = 790
+
+    contributor_fees = contributor_weight * feerate
+    contributor_fees = 790 * 253 / 1000
+    contributor_fees = 200 sats
+
+This is an estimated fee. The peer MUST at least contribute the estimated fee,
+and MUST exceed the minimum fee in the case that their witness weight is greater
+than the estimated weight of 107 per input.
+
 ## Expected Weight of the Commitment Transaction
 
 The *expected weight* of a commitment transaction is calculated as follows:
@@ -1124,7 +1228,7 @@ The resulting funding transaction is:
 
 In the following:
  - *local* transactions are considered, which implies that all payments to *local* are delayed.
- - It's assumed that *local* is the funder.
+ - It's assumed that *local* is the opener.
  - Private keys are displayed as 32 bytes plus a trailing 1 (Bitcoin's convention for "compressed" private keys, i.e. keys for which the public key is compressed).
  - Transaction signatures are all deterministic, using RFC6979 (using HMAC-SHA256).
 
@@ -2679,6 +2783,264 @@ before subtraction of:
 ]
 ```
 
+# Appendix H: Dual Funded Transaction Test Vectors
+
+## Funding Transaction Construction
+### Preliminaries:
+
+```
+Genesis block 0:
+0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4adae5494dffff7f20020000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000
+
+Block 1:0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910ff86fd1d0db3ac5a72df968622f31e6b5e6566a09e29206d7c7a55df90e181de8be86815cffff7f200000000001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0200f2052a0100000017a914113ca7e584fe1575b6fc39abae991529f66eda58870000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
+Coinbase address pubkey: 2MtpN8zCxTp8AWSg7VBjBX7vU6x73bVCKP8
+Coinbase address privkey: cPxFtfE1w3ptFnsZvvFeWji21kTArYa9GXwMkYsoQHdaJKrjUTek
+
+Parent transaction (spends coinbase of block 1):
+02000000000101f86fd1d0db3ac5a72df968622f31e6b5e6566a09e29206d7c7a55df90e181de800000000171600141fb9623ffd0d422eacc450fd1e967efc477b83ccffffffff0580b2e60e00000000220020fd89acf65485df89797d9ba7ba7a33624ac4452f00db08107f34257d33e5b94680b2e60e0000000017a9146a235d064786b49e7043e4a042d4cc429f7eb6948780b2e60e00000000160014fbb4db9d85fba5e301f4399e3038928e44e37d3280b2e60e0000000017a9147ecd1b519326bc13b0ec716e469b58ed02b112a087f0006bee0000000017a914f856a70093da3a5b5c4302ade033d4c2171705d387024730440220696f6cee2929f1feb3fd6adf024ca0f9aa2f4920ed6d35fb9ec5b78c8408475302201641afae11242160101c6f9932aeb4fcd1f13a9c6df5d1386def000ea259a35001210381d7d5b1bc0d7600565d827242576d9cb793bfe0754334af82289ee8b65d137600000000
+```
+
+### Funding transaction (spends parent's outputs):
+
+Locktime: 120
+Feerate: 253 sat/kiloweight
+Opener's `funding_satoshi`: 2 0000 0000 sat
+Accepter's `funding_satoshi`: 2 0000 0000 sat
+
+Inputs:
+```
+4303ca8ff10c6c345b9299672a66f111c5b81ae027cc5b0d4d39d09c66b032b9 0
+	witness_data:
+	  preimage: 20 68656c6c6f2074686572652c2074686973206973206120626974636f6e212121
+	  witness_script: 27 82012088a820add57dfe5277079d069ca4ad4893c96de91f88ffb981fdc6a2a34d5336c66aff87
+	scriptPubKey: 0020fd89acf65485df89797d9ba7ba7a33624ac4452f00db08107f34257d33e5b946
+	address: bcrt1qlky6eaj5sh0cj7tanwnm573nvf9vg3f0qrdssyrlxsjh6vl9h9rql40v2g
+
+4303ca8ff10c6c345b9299672a66f111c5b81ae027cc5b0d4d39d09c66b032b9 2
+	pubkey: 034695f5b7864c580bf11f9f8cb1a94eb336f2ce9ef872d2ae1a90ee276c772484
+	privkey: cUM8Dr33wK4uFmw3Tz8sbQ7BiBNgX5BthRurU7RkgXVvNUPcWrJf
+	witness_program: fbb4db9d85fba5e301f4399e3038928e44e37d32
+	scriptPubKey: 0014fbb4db9d85fba5e301f4399e3038928e44e37d32
+	address: bcrt1qlw6dh8v9lwj7xq058x0rqwyj3ezwxlfjxsy7er
+
+```
+
+### Expected Opener's `tx_add_input` (input 0 above):
+```
+  num_inputs: 1
+  tx_add_input:[
+    {
+      channel_id: "xxx",
+      serial_id: 20,
+      prevtx_len: 353,
+      prevtx: "02000000000101f86fd1d0db3ac5a72df968622f31e6b5e6566a09e29206d7c7a55df90e181de800000000171600141fb9623ffd0d422eacc450fd1e967efc477b83ccffffffff0580b2e60e00000000220020fd89acf65485df89797d9ba7ba7a33624ac4452f00db08107f34257d33e5b94680b2e60e0000000017a9146a235d064786b49e7043e4a042d4cc429f7eb6948780b2e60e00000000160014fbb4db9d85fba5e301f4399e3038928e44e37d3280b2e60e0000000017a9147ecd1b519326bc13b0ec716e469b58ed02b112a087f0006bee0000000017a914f856a70093da3a5b5c4302ade033d4c2171705d387024730440220696f6cee2929f1feb3fd6adf024ca0f9aa2f4920ed6d35fb9ec5b78c8408475302201641afae11242160101c6f9932aeb4fcd1f13a9c6df5d1386def000ea259a35001210381d7d5b1bc0d7600565d827242576d9cb793bfe0754334af82289ee8b65d137600000000",
+      prev_vout: 0,
+      sequence: 4294967293
+    }
+  ]
+```
+
+### Expected Accepter's `tx_add_input` (input 2 above):
+```
+  num_inputs: 1
+  tx_add_input:[
+    {
+      channel_id: "xxx",
+      serial_id: 11,
+      prevtx_len: 353,
+      prevtx: "02000000000101f86fd1d0db3ac5a72df968622f31e6b5e6566a09e29206d7c7a55df90e181de800000000171600141fb9623ffd0d422eacc450fd1e967efc477b83ccffffffff0580b2e60e00000000220020fd89acf65485df89797d9ba7ba7a33624ac4452f00db08107f34257d33e5b94680b2e60e0000000017a9146a235d064786b49e7043e4a042d4cc429f7eb6948780b2e60e00000000160014fbb4db9d85fba5e301f4399e3038928e44e37d3280b2e60e0000000017a9147ecd1b519326bc13b0ec716e469b58ed02b112a087f0006bee0000000017a914f856a70093da3a5b5c4302ade033d4c2171705d387024730440220696f6cee2929f1feb3fd6adf024ca0f9aa2f4920ed6d35fb9ec5b78c8408475302201641afae11242160101c6f9932aeb4fcd1f13a9c6df5d1386def000ea259a35001210381d7d5b1bc0d7600565d827242576d9cb793bfe0754334af82289ee8b65d137600000000",
+      prev_vout: 2,
+      sequence: 4294967293
+    }
+  ]
+```
+
+### Outputs: (scriptPubKeys)
+```
+# opener's change address
+pubkey: 0206e626a4c6d4392d4030bc78bd93f728d1ba61214a77c63adc17d71e32ded3df
+# privkey: cSpC1KYEV1vsUFBwTdcuRkncbwfipY1m5zuQ9CjgAYwiVvbQ4fc1
+scriptPubKey: 00141ca1cca8855bad6bc1ea5436edd8cff10b7e448b
+address: bcrt1qrjsue2y9twkkhs022smwmkx07y9hu3ytshgjmj
+
+# accepter's change address
+pubkey: 028f3978c211f4c0bf4d20674f345ae14e08871b25b2c957b4bdbd42e9726278fc
+privkey: cQ1HXnbAE4wGhuB2b9rJEydV5ayeEmMqxf1dvHPZmyMTPkwvZJyg
+scriptPubKey: 001444cb0c39f93ecc372b5851725bd29d865d333b10
+address: bcrt1qgn9scw0e8mxrw26c29e9h55asewnxwcsdxdp50
+
+# the 2-of-2s
+pubkey1: 0292edb5f7bbf9e900f7e024be1c1339c6d149c11930e613af3a983d2565f4e41e
+pubkey2: 02e16172a41e928cbd78f761bd1c657c4afc7495a1244f7f30166b654fbf7661e3
+script_def: multi(2,0292edb5f7bbf9e900f7e024be1c1339c6d149c11930e613af3a983d2565f4e41e,02e16172a41e928cbd78f761bd1c657c4afc7495a1244f7f30166b654fbf7661e3)
+script: 52210292edb5f7bbf9e900f7e024be1c1339c6d149c11930e613af3a983d2565f4e41e2102e16172a41e928cbd78f761bd1c657c4afc7495a1244f7f30166b654fbf7661e352ae
+scriptPubKey: 0020297b92c238163e820b82486084634b4846b86a3c658d87b9384192e6bea98ec5
+address: bcrt1q99ae9s3czclgyzuzfpsggc6tfprts63uvkxc0wfcgxfwd04f3mzs3asq6l
+```
+
+### Expected Opener's `tx_add_output`:
+
+```
+  num_outputs: 2
+  tx_add_output[
+    {
+      channel_id:"xxx",
+      serial_id: 30,
+      sats: 49999845,
+      scriptlen: 22,
+      script: "1600141ca1cca8855bad6bc1ea5436edd8cff10b7e448b"
+    },{
+      channel_id: "xxx",
+      serial_id: 44,
+      sats: 400000000,
+      scriptlen: 34,
+      script: "220020297b92c238163e820b82486084634b4846b86a3c658d87b9384192e6bea98ec5"
+    }
+  ]
+```
+
+### Expected Accepter's `tx_add_output`:
+
+```
+  num_outputs: 1
+  tx_add_output[
+    {
+      channel_id: xxx,
+      serial_id: 33,
+      sats: 49999900,
+      scriptlen: 22,
+      script: 16001444cb0c39f93ecc372b5851725bd29d865d333b10
+    }
+  ]
+```
+
+### Expected Fee Calculation:
+
+Opener's fees and change:
+```
+    initiator_weight = (input_count, output_count, version, locktime) * 4
+                     + segwit_fields (marker + flag)
+                     + inputs (txid, vout, scriptSig, sequence) * number initiator inputs * 4
+                     + funding_output * 4
+                     + change_output * 4
+                     + max(number initiator inputs
+			       * minimum witness weight,
+			   actual witness weight of all inputs)
+
+    initiator_weight = (1 + 1 + 4 + 4) * 4
+                     + 2
+                     + (32 + 4 + 1 + 4) * 1 * 4
+                     + 43 * 4
+                     + 31 * 4
+                     + max(1 * 107, 71)
+
+    initiator_weight = 609
+
+    initiator_fees = initiator_weight * feerate
+    initiator_fees = 609 * 253 / 1000
+    initiator_fees = 155 sats
+
+    change = total_funding
+           - funding_sats
+           - fees
+
+    change = 2 5000 0000
+           - 2 0000 0000
+           -         155
+
+    change =   4999 9845
+
+    as hex: e5effa0200000000
+```
+
+### Accepter's fees and change:
+```
+    contributor_weight = inputs(txid, vout, scriptSig, sequence)
+			  * number contributor inputs * 4
+                       + change_output * 4
+		       + max(number contributor inputs
+			         * minimum witness weight,
+			     actual witness weight of all inputs)
+
+    contributor_weight = (32 + 4 + 1 + 4) * 1 *  4
+                       + 31 * 4
+                       + max(1 * 107, 99)
+
+    contributor_weight = 395
+
+    contributor_fees = contributor_weight * feerate
+    contributor_fees = 398 * 253 / 1000
+    contributor_fees = 100 sats
+
+    change = total_funding
+           - funding_sats
+           - fees
+
+    change = 2 5000 0000
+           - 2 0000 0000
+           -         100
+
+    change =   4999 9900
+
+    as hex: 1cf0fa0200000000
+```
+
+### Unsigned Funding Transaction:
+
+```
+0200000002b932b0669cd0394d0d5bcc27e01ab8c511f1662a6799925b346c0cf18fca03430200000000fdffffffb932b0669cd0394d0d5bcc27e01ab8c511f1662a6799925b346c0cf18fca03430000000000fdffffff03e5effa02000000001600141ca1cca8855bad6bc1ea5436edd8cff10b7e448b1cf0fa020000000016001444cb0c39f93ecc372b5851725bd29d865d333b100084d71700000000220020297b92c238163e820b82486084634b4846b86a3c658d87b9384192e6bea98ec578000000
+```
+
+### Expected Opener's `tx_signatures`:
+
+```
+  tx_signatures{
+      channel_id: xxx,
+      txid: "5ca4e657c1aa9d069ea4a5d712045d233a7d7c52738cb02993637289e6386057",
+      num_witnesses: 1,
+      witness_stack[{
+	num_input_witness: 2,
+	witness_element:[
+	{
+	  len: 32,
+	  witness: "68656c6c6f2074686572652c2074686973206973206120626974636f6e212121"
+	},{
+	  len: 39,
+	  witness: "82012088a820add57dfe5277079d069ca4ad4893c96de91f88ffb981fdc6a2a34d5336c66aff87"
+	}]
+     }]
+  }
+```
+
+### Expected Accepter's `tx_signatures`:
+
+```
+  tx_signatures{
+      channel_id: xxx,
+      txid: "5ca4e657c1aa9d069ea4a5d712045d233a7d7c52738cb02993637289e6386057",
+      num_witnesses: 1,
+      witness_stack[{
+	num_input_witness: 2,
+	witness_element:[
+	{
+	  len: 71,
+	  witness: "304402207de9ba56bb9f641372e805782575ee840a899e61021c8b1572b3ec1d5b5950e9022069e9ba998915dae193d3c25cb89b5e64370e6a3a7755e7f31cf6d7cbc2a49f6d01",
+	},{
+	  len: 33,
+	  witness: "034695f5b7864c580bf11f9f8cb1a94eb336f2ce9ef872d2ae1a90ee276c772484"
+	}]
+     }]
+  }
+```
+
+#### Signed Funding Transaction:
+
+Note locktime is set to 120.
+
+```
+02000000000102b932b0669cd0394d0d5bcc27e01ab8c511f1662a6799925b346c0cf18fca03430200000000fdffffffb932b0669cd0394d0d5bcc27e01ab8c511f1662a6799925b346c0cf18fca03430000000000fdffffff03e5effa02000000001600141ca1cca8855bad6bc1ea5436edd8cff10b7e448b1cf0fa020000000016001444cb0c39f93ecc372b5851725bd29d865d333b100084d71700000000220020297b92c238163e820b82486084634b4846b86a3c658d87b9384192e6bea98ec50247304402207de9ba56bb9f641372e805782575ee840a899e61021c8b1572b3ec1d5b5950e9022069e9ba998915dae193d3c25cb89b5e64370e6a3a7755e7f31cf6d7cbc2a49f6d0121034695f5b7864c580bf11f9f8cb1a94eb336f2ce9ef872d2ae1a90ee276c772484022068656c6c6f2074686572652c2074686973206973206120626974636f6e2121212782012088a820add57dfe5277079d069ca4ad4893c96de91f88ffb981fdc6a2a34d5336c66aff8778000000
+```
+
 # References
 
 # Authors
diff --git a/09-features.md b/09-features.md
index 730e6cd72..95c59e93a 100644
--- a/09-features.md
+++ b/09-features.md
@@ -44,6 +44,7 @@ The Context column decodes as follows:
 | 22/23 | `option_anchors_zero_fee_htlc_tx` | Anchor commitment type with zero fee HTLC transactions    | IN       | `option_static_remotekey` | [BOLT #3][bolt03-htlc-tx], [lightning-dev][ml-sighash-single-harmful] |
 | 24/25 | `option_route_blinding`           | Node supports blinded paths                               | IN9      | `var_onion_optin`         | [BOLT #4](bolt04-route-blinding)                                      |
 | 26/27 | `option_shutdown_anysegwit`       | Future segwit versions allowed in `shutdown`              | IN       |                           | [BOLT #2][bolt02-shutdown]                                            |
+| 28/29 | `option_dual_fund`                | Use v2 of channel open, enables dual funding              | IN       |                           | [BOLT #2](02-peer-protocol.md)                                        |
 | 38/39 | `option_onion_messages`           | Can forward onion messages                                | IN       |                           | [BOLT #7](04-onion-routing.md#onion-messages)                         |
 | 44/45 | `option_channel_type`             | Node supports the `channel_type` field in open/accept     | IN       |                           | [BOLT #2](02-peer-protocol.md#the-open_channel-message)               |
 | 46/47 | `option_scid_alias`               | Supply channel aliases for routing                        | IN       |                           | [BOLT #2][bolt02-channel-ready]                                       |
diff --git a/tools/spellcheck.sh b/tools/spellcheck.sh
index fb309315f..709913db3 100755
--- a/tools/spellcheck.sh
+++ b/tools/spellcheck.sh
@@ -68,7 +68,8 @@ do
 	    -e 's/0x[a-fA-F0-9 ]\+//g' \
 	    -e 's/[a-fA-F0-9]\{20,\}//g' \
 	    -e 's/^    .*_htlcs//g' \
-	    -e 's/ \(bc\|tb\)1[qpzry9x8gf2tvdw0s3jn54khce6mua7l]\+//g' \
+	    -e 's/ ln\(bc\|tb\)[0-9munp]*1[qpzry9x8gf2tvdw0s3jn54khce6mua7l]\+//g' \
+	    -e 's/ \(bc\|tb\|bcrt\)1[qpzry9x8gf2tvdw0s3jn54khce6mua7l]\+//g' \
 	    -e 's/pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0xqzpuyk0sg5g70me25alkluzd2x62aysf2pyy8edtjeevuv4p2d5p76r4zkmneet7uvyakky2zr4cusd45tftc9c5fh0nnqpnl2jfll544esqchsrny//' \
 	    -e 's/[123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz]\{20,\}//g' < $f | tee /tmp/`basename $f`.aspell | aspell -l en_US --home-dir ${homedir} list)
 	if [ -n "$WORDS" ]; then