Christian assumed first bit was 1, I assumed 0. And we should generally
assign in pairs (so an optional understanding can later become compulsory),
though for the initial draft it's unnecessary.
By giving names we avoid smearing values over the spec, containing them in
BOLT 9.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 2&7: Cleaner separation of concerns wrt announcement signatures
So far we did not have any indication on what to do if a node does not
allow announcing the channel and we had a mix of concerns in the
`funding_locked` message, which would also transfer the signatures
needed for the announcement. This is a proposal about splitting the
signatures into their own message, so that simple omission is an
opt-out of announcements, and it does not mix announcement/gossip
stuff into the peer-protocol.
(It also ended up adding a localfeatures flag to opt-into the channel-announcement, and thus creating BOLT 9)
Reorders the `channel-id` and `bitcoin-signature-x` fields so that the
signed part of the message is contiguous. Simplifies the signing logic
not to just simple signatures of a contiguous region of the message,
no need to sign signatures, they all commit to the same payload. This
also removes the chicken and egg problem @pm47 reported in #92.
Furthermore it specifies that the signed payload also includes any
future appended fields.
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>
