mirrors/core-lightning
1
0
Fork 0
mirror of https://github.com/ElementsProject/lightning.git synced 2025-02-20 13:54:36 +01:00
Code Issues Projects Releases Wiki Activity

bolt: Update to latest bolt, including TLV onion format.

Browse source 
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2019-08-02 12:54:25 +09:30 • committed by Christian Decker
parent fafd5ed4b0
commit 8774070a31
4 changed files with 18 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
Makefile
View file

@ -15,7 +15,7 @@ CCANDIR := ccan
# Where we keep the BOLT RFCs
BOLTDIR := ../lightning-rfc/
BOLTVERSION := aa33af0c4d7ae0180c04ef98e61af49c1f876a36
BOLTVERSION := d23f4b056c8ccc5234494c2431c901c455fa877f
-include config.vars

24
common/sphinx.h
View file

@ -49,28 +49,12 @@ struct sphinx_path;
/* BOLT #4:
*
* The `hops_data` field is a structure that holds obfuscations of the
* next hop's address, transfer information, and its associated HMAC. It is
* 1300 bytes (`20x65`) long and has the following structure:
* ## Legacy `hop_data` payload format
*
* 1. type: `hops_data`
* 2. data:
* * [`byte`:`realm`]
* * [`32*byte`:`per_hop`]
* * [`32*byte`:`HMAC`]
* * ...
* * `filler`
* The `hop_data` format is identified by a single `0x00`-byte length,
* for backward compatibility. It's payload is defined as:
*
* Where, the `realm`, `per_hop` (with contents dependent on `realm`), and `HMAC`
* are repeated for each hop; and where, `filler` consists of obfuscated,
* deterministically-generated padding, as detailed in
* [Filler Generation](#filler-generation). Additionally, `hops_data` is
* incrementally obfuscated at each hop.
*
* The `realm` byte determines the format of the `per_hop` field; currently, only
* `realm` 0 is defined, for which the `per_hop` format follows:
*
* 1. type: `per_hop` (for `realm` 0)
* 1. type: `hop_data` (for `realm` 0)
* 2. data:
* * [`short_channel_id`:`short_channel_id`]
* * [`u64`:`amt_to_forward`]

13
wire/Makefile
View file

@ -70,17 +70,18 @@ wire/gen_peer_wire_csv wire/gen_onion_wire_csv: config.vars
# tlvs_n1 and n2 are used for test vectors, thus not referenced: expose them
# for testing and to prevent compile error about them being unused.
# This will be easier if test vectors are moved to separate files.
wire/gen_peer_wire.h: wire/gen_peer_wire_csv $(WIRE_BOLT_DEPS)
wire/gen_peer_wire.h: wire/gen_peer_wire_csv $(WIRE_BOLT_DEPS) wire/Makefile
$(BOLT_GEN) -s --expose-tlv-type=n1 --expose-tlv-type=n2 --page header $@ wire_type < $< > $@
wire/gen_peer_wire.c: wire/gen_peer_wire_csv $(WIRE_BOLT_DEPS)
wire/gen_peer_wire.c: wire/gen_peer_wire_csv $(WIRE_BOLT_DEPS) wire/Makefile
$(BOLT_GEN) -s --expose-tlv-type=n1 --expose-tlv-type=n2 --page impl ${@:.c=.h} wire_type < $< > $@
wire/gen_onion_wire.h: wire/gen_onion_wire_csv $(WIRE_BOLT_DEPS)
$(BOLT_GEN) -s --page header $@ onion_type < $< > $@
# The tlv_payload isn't parsed in a fromwire, so we need to expose it.
wire/gen_onion_wire.h: wire/gen_onion_wire_csv $(WIRE_BOLT_DEPS) wire/Makefile
$(BOLT_GEN) -s --expose-tlv-type=tlv_payload --page header $@ onion_type < $< > $@
wire/gen_onion_wire.c: wire/gen_onion_wire_csv $(WIRE_BOLT_DEPS)
$(BOLT_GEN) -s --page impl ${@:.c=.h} onion_type < $< > $@
wire/gen_onion_wire.c: wire/gen_onion_wire_csv $(WIRE_BOLT_DEPS) wire/Makefile
$(BOLT_GEN) -s --expose-tlv-type=tlv_payload --page impl ${@:.c=.h} onion_type < $< > $@
check-source: $(WIRE_SRC:%=check-src-include-order/%) $(WIRE_HEADERS_NOGEN:%=check-hdr-include-order/%)

6
wire/extracted_onion_wire_csv
View file

@ -1,4 +1,10 @@
#include <wire/onion_defs.h>
tlvtype,tlv_payload,amt_to_forward,2
tlvdata,tlv_payload,amt_to_forward,amt_to_forward,tu64,
tlvtype,tlv_payload,outgoing_cltv_value,4
tlvdata,tlv_payload,outgoing_cltv_value,outgoing_cltv_value,tu32,
tlvtype,tlv_payload,short_channel_id,6
tlvdata,tlv_payload,short_channel_id,short_channel_id,short_channel_id,
msgtype,invalid_realm,PERM|1
msgtype,temporary_node_failure,NODE|2
msgtype,permanent_node_failure,PERM|NODE|2