This commit updates the opening paragraph in the channel establishment
section. The messages referenced are were from the prior iteration of
the funding messages and naming scheme. The section has been updated to
properly reference the latest messages and also to give a bit more
context to the reader to start with.
Further separating the two specs by pointing to bolt08 for transport
details and deduplicating some of the information. Also fixed some
markup while I'm at it :-)
So far we had both the transport layer, with its initialization details,
and part of the base protocol, with some generic messages like `init`
and `error` in a single spec. I propose we split the spec into two, one
for the transport layer and one for the communication on top of that
layer. This should make the independence of the two layers even clearer.
This commit is the first step towards that goal and simply moves blocks
of text into the new spec file. It should not change any semantics.
There was talk of using a simple increment, but it was removed after
Tadge educated me. Somehow this didn't get updated.
Reported-by: Tadge Dryja <tdryja@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Inspired by Andrew Shvv's work, this expands the HTLC weight calculation
and fixes the gross errors (the witness program itself wasn't counted in
the weights!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Commit a0c4f7cfd1 "BOLT 3: add more detailed commitment transaction
estimation (#26)" simplified the weight formula to assume there was a
to-remote output.
This worst-case 18% error, but it's simple. Document it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
