lukechilds/lightning - lightning - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Rusty Russell	45a6f81c3c	protocol: remove ack fields. As per lightning-rfc commit 8ee09e749990a11fa53bea03d5961cfde4be4616, we remove the acks from the protocol now they're no longer needed (and all the infrastructure). We also place the commit number in the commit_info where it logically belongs, removing it from the peer struct. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>	9 years ago
Rusty Russell	0f35441a29	protocol: move `ack` out of header into specific packets. This reflects the BOLT #1/#2 protocol change, as suggeted by Pierre. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>	9 years ago
Rusty Russell	afedf0e8ac	cryptopkt: implement ack callbacks. For the change to asynchronous updates as specified by BOLT #2, we need to know when the other side acknowledged a packet. This creates a simple callback mechanism for it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>	9 years ago
Rusty Russell	74f294e36c	daemon: encrypted communication (version 3) After useful feedback from Anthony Towns and Mats Jerratsch (of thunder.network fame), this is the third version of inter-node crypto. 1) First, each side sends a 33-byte session pubkey. This is a bitcoin-style compressed EC key, unique for each session. 2) ECDH is used to derive a shared secret. From this we generate the following transmission encoding parameters for each side: Session AES-128 key: SHA256(shared-secret \|\| my-sessionpubkey \|\| 0) Session HMAC key: SHA256(shared-secret \|\| my-sessionpubkey \|\| 1) IV for AES: SHA256(shared-secret \|\| my-sessionpubkey \|\| 2) 3) All packets from then on are encrypted of form: /* HMAC, covering totlen and data / struct sha256 hmac; / Total data transmitted (including this). / le64 totlen; / Encrypted contents, rounded up to 16 byte boundary. */ u8 data[]; 4) The first packet is an Authenticate protobuf, containing this node's pubkey, and a bitcoin-style EC signature of the other side's session pubkey. 5) Unknown protobuf fields are handled in the protocol as follows (including in the initial Authenticate packet): 1) Odd numbered fields are optional, and backwards compatible. 2) Even numbered fields are required; abort if you get one. Currently both sides just send an error packet "hello" after the handshake, and make sure they receive the same. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>	9 years ago