interactive-tx: Add dual-funding flow, using the interactive tx protocol

This commit adds the interactive transaction construction protcol, as
well as the first practical example of using it, v2 of channel
establishment.

Note that for v2 we also update the channel_id, which now uses the hash
of the revocation_basepoints. We move away from using the funding
transaction id, as the introduction of RBF* makes it such that a single
channel may have many funding transaction id's over the course of
its lifetime.

*Later, also splicing

.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

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.