This encapsulates proposals more cleanly, and is important when we change
the protocol to have more than one outstanding at a time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is only for the simple case where there are no HTLCs.
We group the current commit information together in the struct;
this involves a trivial transform from peer->cur_commit_theirsig to
peer->cur_commit.theirsig.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We abort when this happens, but still worth testing.
This involves a refactor so we can allocate watches off a specific context,
for easy freeing when they're no longer wanted.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We do the simplest thing: a timer goes off, and we check all HTLCs for
one which has expired more than 30 seconds ago.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When the only commands are via JSON, you might argue that we should
simply insist the user not operate on the same peer in parallel. That
would suck, and also we need to handle the case of a command from
a timer (eg. HTLC expiry!) or a bitcoin event.
So, we need a queue for commands, but also we need to do some of the
command checking just before the command runs: the HTLC we're dealing
with might have vanished for example.
The current command is wrapped in an anonymous "curr_cmd" struct
for extra clarity.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets us implement accept_pkt_anchor().
Also had to predeclare sha256 in commit_tx.h, revealed by the new
includes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
Rusty Russell