Introduces happy-path static test vectors

Messaging.md

@@ -66,7 +66,6 @@ The following convenience types are also defined:
 * `x_point`: a 32-byte x-only public key with implicit y-coordinate being even as in [BIP 340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design)
 * `point`: a 33-byte Elliptic Curve point (compressed encoding as per [SEC 1 standard](http://www.secg.org/sec1-v2.pdf#subsubsection.2.3.3))
 * `spk`: A bitcoin script public key encoded as ASM prefixed with a `u16` value indicating its length.
-* `script_sig`: A bitcoin script signature encoded as ASM prefixed a `u16` value indicating its length.
 * `short_contract_id`: an 8 byte value identifying a contract funding transaction on-chain (see [BOLT #7](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#definition-of-short-channel-id))
 * `bigsize`: a variable-length, unsigned integer similar to Bitcoin's CompactSize encoding, but big-endian.  Described in [BigSize](https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#appendix-a-bigsize-test-vectors).
 
@@ -116,16 +115,20 @@ This type contains information about a specific input to be used in a funding tr
    * [`u32`:`prevtx_vout`]
    * [`u32`:`sequence`]
    * [`u16`:`max_witness_len`]
-   * [`script_sig`:`redeemscript`]
+   * [`spk`:`redeemscript`]
 
 `prevtx_tx` is the serialized transaction whose `prevtx_vout` output is being spent.
 The transaction is used to validate this spent output's value and to validate that it is a SegWit output.
 
 `max_witness_len` is the total serialized length of the witness data that will be supplied
 (e.g. sizeof(varint) + sizeof(witness) for each) in `funding_signatures`.
 
-`redeemscript` is the script signature field for the input. Only applicable for P2SH-wrapped inputs.
-In all native Segwit inputs, `redeemscript` will be a `0` byte (from the `script_sig` size prefix).
+`redeemscript` the witness script public key to be revealed for P2SH spending.
+Only applicable for P2SH-wrapped inputs.
+In all native Segwit inputs, `redeemscript` will be a `u16` zero (from the `spk` size prefix).
+Note that when doing fee computation, `script_sig_len` is either zero in the case that
+`redeemscript` is empty or else it is equal to `1 + len(redeemscript)` where the added
+byte is for pushing `redeemscript` onto the stack in the script signature.
 
 ### The `cet_adaptor_signatures` Type
 

Transactions.md

@@ -146,7 +146,7 @@ Note that if a CET occurs in which one party's output is below the dust limit of
 
 ### Computation of `max_witness_len`
 
-The `max_witness_len` should be computed to be an upper bound on the byte size of all elements on the witness stack (and no other data). For example, a P2WPKH funding input should have a `max_witness_len` of `108`: 
+The `max_witness_len` should be computed to be an upper bound on the byte size of all elements on the witness stack (and no other data). For example, a P2WPKH funding input should have a `max_witness_len` of `107` or `108` depending on if you use low-R signing (which takes a byte off the sig), below is the computation for non-low-R where wallets implementing low-R can use `sig: 71 bytes` below to save a byte: 
 
 ```
 p2wpkh witness: 108 bytes