Use signed amounts in RBF messages

While dual funding only needs unsigned funding amounts, other protocols
that leverage interactive-tx may use signed funding amounts, for example
to take funds out of an existing channel (splice-out).

It is thus more future-proof to use signed amounts in `tx_init_rbf` and
`tx_ack_rbf`.

01-messaging.md

@@ -29,6 +29,7 @@ All data fields are unsigned big-endian unless otherwise specified.
   * [Appendix A: BigSize Test Vectors](#appendix-a-bigsize-test-vectors)
   * [Appendix B: Type-Length-Value Test Vectors](#appendix-b-type-length-value-test-vectors)
   * [Appendix C: Message Extension](#appendix-c-message-extension)
+  * [Appendix D: Signed Integers Test Vectors](#appendix-d-signed-integers-test-vectors)
   * [Acknowledgments](#acknowledgments)
   * [References](#references)
   * [Authors](#authors)
@@ -220,9 +221,16 @@ receiver to parse individual elements from `value`.
 Various fundamental types are referred to in the message specifications:
 
 * `byte`: an 8-bit byte
+* `i8`: an 8-bit signed integer
 * `u16`: a 2 byte unsigned integer
+* `i16`: a 2 byte signed integer
 * `u32`: a 4 byte unsigned integer
+* `i32`: a 4 byte signed integer
 * `u64`: an 8 byte unsigned integer
+* `i64`: an 8 byte signed integer
+
+Signed integers use standard big-endian two's complement representation
+(see test vectors [below](#appendix-d-signed-integers-test-vectors)).
 
 Inside TLV records which contain a single value, leading zeros in
 integers can be omitted:
@@ -968,6 +976,108 @@ Note that when messages are signed, the _extension_ is part of the signed bytes.
 Nodes should store the _extension_ bytes even if they don't understand them to
 be able to correctly verify signatures.
 
+## Appendix D: Signed Integers Test Vectors
+
+The following test vector show how signed integers (`i8`, `i16`, `i32`
+and `i64`) are encoded using big-endian two's complement.
+
+```json
+[
+    {
+        "value": 0,
+        "bytes": "00"
+    },
+    {
+        "value": 42,
+        "bytes": "2a"
+    },
+    {
+        "value": -42,
+        "bytes": "d6"
+    },
+    {
+        "value": 127,
+        "bytes": "7f"
+    },
+    {
+        "value": -128,
+        "bytes": "80"
+    },
+    {
+        "value": 128,
+        "bytes": "0080"
+    },
+    {
+        "value": -129,
+        "bytes": "ff7f"
+    },
+    {
+        "value": 15000,
+        "bytes": "3a98"
+    },
+    {
+        "value": -15000,
+        "bytes": "c568"
+    },
+    {
+        "value": 32767,
+        "bytes": "7fff"
+    },
+    {
+        "value": -32768,
+        "bytes": "8000"
+    },
+    {
+        "value": 32768,
+        "bytes": "00008000"
+    },
+    {
+        "value": -32769,
+        "bytes": "ffff7fff"
+    },
+    {
+        "value": 21000000,
+        "bytes": "01406f40"
+    },
+    {
+        "value": -21000000,
+        "bytes": "febf90c0"
+    },
+    {
+        "value": 2147483647,
+        "bytes": "7fffffff"
+    },
+    {
+        "value": -2147483648,
+        "bytes": "80000000"
+    },
+    {
+        "value": 2147483648,
+        "bytes": "0000000080000000"
+    },
+    {
+        "value": -2147483649,
+        "bytes": "ffffffff7fffffff"
+    },
+    {
+        "value": 500000000000,
+        "bytes": "000000746a528800"
+    },
+    {
+        "value": -500000000000,
+        "bytes": "ffffff8b95ad7800"
+    },
+    {
+        "value": 9223372036854775807,
+        "bytes": "7fffffffffffffff"
+    },
+    {
+        "value": -9223372036854775808,
+        "bytes": "8000000000000000"
+    }
+]
+```
+
 ## Acknowledgments
 
 [ TODO: (roasbeef); fin ]

02-peer-protocol.md

@@ -446,7 +446,7 @@ completed.
 2. types:
     1. type: 0 (`funding_output_contribution`)
     2. data:
-        * [`tu64`:`satoshis`]
+        * [`i64`:`satoshis`]
 
 #### Requirements
 
@@ -492,7 +492,7 @@ not contributing to the funding output.
 2. types:
     1. type: 0 (`funding_output_contribution`)
     2. data:
-        * [`tu64`:`satoshis`]
+        * [`i64`:`satoshis`]
 
 #### Requirements