This seems rather easy to fix, the only case we do not want to set
`STATE_SHUTDOWN` us when we have updates which we have not committed
yet, which is handled separately in the other IF-branch.
The `dstate` reference was only an indirection to the `timers`
sub-structure anyway, so removing this indirection allows us to reuse
the timers in the subdaemon arch.
We used to have a permutation map; this reintroduces a variant which
uses the htlc pointers directly.
We need this because we have to send the htlc-tx signatures in output
order as part of the protocol: without two-stage HTLCs we only needed
to wire them up in the unilateral spend case so we simply brute-forced
the ordering.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If type and tag match, then we replace any existing message in the
queue. This allows us to drop old announcements. Special care needs to
be taken so that dependent messages are not reordered, but for gossip
this is the case, since the `channel_announcement` cannot be updated.
Moved the broadcast functionality to broadcast.[ch]. So far this
includes only the enqueuing side of broadcasts, the dequeuing and
actual push to the peer is daemon dependent. This also adds the
broadcast_state to the routing_state and the last broadcast index to
the peer for the legacy daemon.
This was the only time we actually reference non-routing structs in
routing, so moving this out should allow us to get it working in the
new subdaemons.
This allows us to move some legacy functions closer to where they are
actually used, and not worry about them when including routing.h into
the new subdaemons. `struct peer` is the main culprit here.
This used to be part of `lightningd_state` which is being split up for
the various subdaemons. The main change is the addition of the `struct
routing_state` in `routing.h` and the addition of `rstate` in `struct
lightningd_state` for backwards compatibility.
We had a hack for 'struct rval' in protobuf_convert.h; make an
explicit header and put it in bitcoin/preimage.h. It's not really
bitcoin-specific, but it's better than having bitcoin/script depend on
an external header.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In particular, 860990fa0afb55f839e882a5e9abe8abe6ccb981 reordered
channel_announcement and c93bf5cf8c48eab1b028e85214cb35feeeffcbb3
reordered the update_fail_malformed_htlc message.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is needed for the new testing framework since we wait for
messages to be printed on stdout. Buffering delays this
arbitrarily. Flushing so often should not have much of a performance
impact.
`awaitinvoice` can be used to wait on a specific invoice to be
completed. If the invoice was previously paid, then the command
returns immediately, otherwise it'll block until the invoice is
paid. This complements `waitinvoice` which uses a highwatermark and
waits for the next invoice. I found waitinvoice a bit hard to use
since it doesn't allow waiting for a specific invoice to be completed,
just the next in the insertion order.
So far this was simply set to a zero-length end-to-end payload. We
don't have any plans of re-adding it for the moment, so let's get rid
of the unused code.
The spec says that we use the libsecp256k1 style ECDH, which uses the
full compressed pubkey from the scalar multiplication which is then
hashed. This is in contrast to the btcsuite implementation which was
only using the hashed X-coordinate.
The API formalizes how daemons should report their statuses back to
the main lightningd. It's a simple write API, which includes tracing
support (currently it always sends traces, later it could send iff
there's a failure, for example).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Before we had a global secp256k1_ctx we needed to hold this to print
out pubkeys, now it's completely orthogonal.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
So far it was failing silently, now it diffs the Makefile state
against the directory listing. This also fixes a bug when the locale
was not set the sort order would not match.
828eda61df5a7be27051c605f7808e4f690739e4, in particular, it has the
new address format for node_announcement.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It implies tal_count() gives the length. Great for almost all callers which
don't care if there are extra bytes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This removes some redundancy in creating messages, but also allows
a lazy form or parsing without explicitly checking the type.
A helper fromwire_peektype() is added to look up the type and handle
the too-short-for-type problem.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a bit more awkward for large structures, but avoids
indirection for the simpler ones (I copied the structures for the test
code, however). We also remove explicit padding.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Other than being neater (no more global list to edit!), this lets the
new daemon and old daemon have their own separate routines.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Keeping a pointer to the peer that initially sent us a message
could (actually will!) result in dangling pointers. Removing this
results in some additional messages, which will be discarded by the
recipient, so that should not be a problem.
Connections are in a half-open state after receiving the
`channel_announcement` and before the `channel_update` makes them
usable, so we need to ignore channels that are not yet fully open.
The gossip protocol spec refers to channels by their `channel_id` and
a direction. Furthermore, inbetween the `channel_announcement` and the
`channel_update` for either direction, the channel direction is in an
undefined state and cannot be used, so added the `half_add_connection`
function and an `active` flag to differentiate usable connections from
unusable ones.
When we support the Milan protocol, we'll use a default port. But
for now, don't listen at all unless a port is specified.
Fixes: #54
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our HMACs are truncated to 20 byte, but sodium still generates 32 byte
HMACs and we were handing in a buffer that was too small, so we
overflowing the buffer by 12 bytes. This manifested itself only in the
32 bit variant because of different alignment in the 64bit version.
Fixes#94.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
