This lets us have both IPv4 and IPv6 (and Tor etc in future) address,
while still preserving the ability to add other fields to the message
in future.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Inspired by Andrew Samokhvalov's PR, this makes the relationship
between the signatures in `channel_announcement` explicit.
Closes: #27
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We could spam the network with 64k announcements, and each node has to
rememeber them for rebroadcasting. There's a tradeoff between
allowing future expansions and this potential DoS, so allow nodes to
choose.
My current implementation thinking is: each extra byte reduces chance
of rebroadcast by a small amount, such that if you're twice the
minimum size your chance of rebroadcast hits 0.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The sending side says it needs to bitcoin-style sign double-SHA, but the
receiving side doesn't. Make it clear.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets us gain 7 more bits, but also as Christian points out, you need
to remember the padding for re-broadcast since the signature covers it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The MSG_XXX is trivially derived from the name of the message if
people want to do that, so just change it to the actual message name.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means they cover future fields as well (which may or may not be good!)
but also ensures they're naturally aligned in case anyone cares.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
