BOLT#2 says we MUST NOT send out commit messages with no changes (and
we drop the connection if the peer does). But that's harder than it
sounds: we can have changes in theory which cancel out (eg. fee
adjustments, not yet implemented) or others which don't change the
commit tx (eg. dust outputs). Simplest is to have a generation count,
which also allows us to simply show number of pending changes in RPC.
It's 32 bit, but you can only use it to screw yourself really (each
side can only add 1500 htlcs, so the rest would have to be fee
changes; wrapping will only make us hang up on you).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rather than creating packets then queueing them, call out to functions
which do both. This moves us towards doing more work in those functions
where we send out a request, which is sometimes clearer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And divide fees as specified there.
We still use fixed values rather than floating, and we don't send or
handle update_fee messages.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We used to have a hacky close timeout which would immediately fire
when we'd closed because the connection was down. Far better to have
a specific "connection lost" input, and have it respond like CMD_CLOSE.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't actually implement closing when we have HTLCs (we should
allow it, as that's what the clearing phase is for), since soon we'll
rewrite HTLC to match the async HTLC protocol of BOLT #2.
Note that this folds the close paths, using a simple check if we have
a close transaction. That's a slight state layer violation, but
reduces code duplication.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
This uses libsodium (we could use openssl, but the required primitives
are only in 1.1.0 which is still in alpha).
It doesn't handle reconnections yet, either.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means we send the first two revocation hashes; this is important
once we move to a commit model as we need to send (unsolicited) the
signature for the *next* commit tx so we need its commit hash.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
We're going to change the protocol to send multiple changes at once, so
disable this compilation and testing for now.
We can revisit it afterwards once the protocol is stable again.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The channel funding code needs to know who offered the anchor, as they
are responsible for paying fees until the other side is able to. This
is actually a hack, but at least now it's internal to funding and not
passed in at every funding_delta() call.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If something goes wrong after we've broadcast the anchor tx, we need to use
the commit tx to spend it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We're about to change the protocol again, and I don't want to do the
grunt work to update these. They were useful for pre-build protocol
testing, though.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It currently points into freed memory once we've make_commit_txs; we
don't currently dereference it after that, but I did in some test code
and got a surprise. Make a copy in all cases where we set it, so
there can't be lifetime problems.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell
Braydon Fuller