The object file should not be built inside the submodule, as that can
confuse git.
Not everything depends on the libbase58 header (CCAN doesn't), so
move that to the everything-else depends line.
The BITCOIN_SRC etc should also move to bitcoin/Makefile, but that's
a bigger change.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
828eda61df5a7be27051c605f7808e4f690739e4, in particular, it has the
new address format for node_announcement.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For our internal CSV files, we can specify the type explicitly rather
than trying to guess (eg. bool).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Pretty! Takes an int instead of the enum directly, because in the
main daemon we call it via a function pointer, so want them all the
same type.
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>
We emit them into the generated code at appropriate points, but it
would be better if we simply preserved the order they were given in.
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>
The union still contains all the types, but we can only print
the ones which are linked in.
This makes it much easier to use type_to_string in different binaries
without pulling in the world.
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.
Christian Decker
Rusty Russell
Lucas Betschart