Major changes:
1. Move crypto first, then cover contents
2. Use "lightning messages" explicitly to refer to upper layer, use
"packet" in the one case where we refer to the whole thing.
3. Collapse "Transport Message Exchange" and "Protocol Message Encapsulation"
into "Lightning Message Specification" which already contains much overlap.
Minor changes:
1. Put the big-endian requirement in the general overview, since the crypto
layer uses that too.
2. Say "is" instead of "should be" encrypted: it's not an option.
3. Note why we separate local and global features.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
They're really a blob of bytes, and we weren't aligning them correctly in
two cases anyway. This gets rid of gratuitous padding, too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since our cryptopacket limits us to 2 bytes, and since people will
send 1-message-per-crypto-packet and nobody will test the
multiple-messages-in-one-cryptopacket code, let's just restrict to
64k messages.
1. Make cryptopacket length not include the HMAC, so we can actually send
64k messages.
2. Remove len prefix from packet, make type 2 bytes, note alignment properties.
3. Change message internal lengths/counts from 4 to 2 bytes, since more
is nonsensical anyway, and this removes a need to check before allocating:
- init feature bitfield length
- error message length
- shutdown scriptpubkey length
- commit_sig number of HTLC signatures
- revoke_and_ack number of HTLC-timeout signatures
4. Change max-accepted-htlcs to two bytes, and limit it to 511 to ensure
that commit_sig will always be under 64k.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Bitcoin still uses feerate-per-kb, which needs to be multiplied by 4
in segwit. It's more than a little confusing.
Split the paragraphs, too, as it's a little overwhelming.
Reported-by: Olaoluwa Osuntokun <laolu32@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
This commit clarifies the current draft of the crypto spec in several areas by
making the steps more explicit. In addition a few errors in the prior version
of this draft have been fixed.
Thanks @EthanHeilman for pointing out several ambiguities in the prior draft of
the document.
A future commit will contain the addition of several test vectors to ensure
implementation parity.
1. Add a short paragraph on P2WSH (the witness script is omitted for brevity in all descriptions) and fix witness scripts for spending the different tx outputs.
2. use CHECK(MULTI)SIG instead of CHECK(MULTI)SIGVERIFY
3. Fix order and nulldummy for witness in HTLC transactions
4. Fix a minor typo (if -> it)
(Commits rebased and squashed together by Rusty)
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>
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>
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>
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>
This commit modifies BOLT 3 slightly to use a code block for the multi-sig script. Without this change, the script doesn't display correctly, as the angle brackets are interpreted as markdown syntax.
