In particular, 860990fa0afb55f839e882a5e9abe8abe6ccb981 reordered
channel_announcement and c93bf5cf8c48eab1b028e85214cb35feeeffcbb3
reordered the update_fail_malformed_htlc message.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can't run them in parallel, but we can at least have 'make check'
run them all.
Developers should be running "make check-source && make check".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Encodings are signed: we may need 5 bytes to encode giant u32s.
Reported-by: Fabrice Drouin <fabrice.drouin@acinq.fr>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We intend to ultimately no longer use the legacy `daemon/lightningd`
and instead use `lightningd/lightningd`, so I grouped the new RPC and
the legacy RPC and implemented stubs for the new daemon.
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 problem with wire headers not being generated in time before stuff
depended on it turns out to be related with inclusion order of
sub-makefiles. The inclusions must preceed the use of
LIGHTNINGD_HEADERS since they append to that variable.
Now we hand peers off to the gossip daemon, to do the INIT handshake and
re-transmit/receive gossip. They may stay there forever if neither we nor
them wants to open a channel.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's a bit messy, since some status messages are accompanied by an FD:
in this case, the handler returns STATUS_NEED_FD and we read that then
re-call the handler.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell
Christian Decker