This is what it actually is (and how it's documented): you can't control
the total since both sides can add at the same time, you can only tell
the other side how many *it* can add, and control how many you add.
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>
We need to supply a pair (a signature using our bitcoin key which signs the
node id, and a signature using our node key which signs the announce message),
and the length was wrong. Move them to make alignment nicer, too (though
it probably doesn't matter, they're 4-byte aligned everywhere else).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And make it channel-index not channel_index to match the others (markdown
doesn't treat - specially, unlike _).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Make the fee amount by kiloweight, not by kilobyte, and spell out how
to calculate it. Note that we have to trim HTLCs outputs whose second-stage
would also fall below dust limit, and we also make some reasonable
approximations on transaction size (which is unknowable before signatures
anyway).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The fact that a revocation response also serves to acknowledge the
pending changes (and thus indicate the sender should apply them
to itself) is documented in the desciption, but still terribly
subtle. Joseph suggested making it clearer, I think this
does that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
After much discussion with Tadge and Laolu, I think we have something
which is nicely outsourcable, and yetnot insanely complex.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Calculations are put in 05-onchain.md, and referred to by 02-peer-protocol.
The number is 600, comfortably under the 626 theoretical limit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
