Some embarssing typos there! Anywho, here are you fixes.
I am out of town next week, but after I get back I will have some definite time on my schedule, and can draft an intro for the spec, if we're comfortable with all the terms here.
This is a big change to the glossary in BOLT-0.
The overarcing changes are:
1.) Reorganized glossary to be alphabetical
2.) Add copious "See also:" lines to cross-reference containers, contents, and other related entries.
*Changed Definitions:* Peer and node were revised based in on discussions with Rusty; commitment revocation secret key was changed to be commitment revocation private key based on #377.
*New Definitions:* New words added based on their usage in the bolts were: announcement, closing transaction, final node, hop, origin node, processing, node, receiving node, receiving peer, revoked commitment transaction, sending node, sending peer.
(I suspect the reorg will make the diffs almost useless, so this is the list of stuff to look at.)
Clarify the query semantics in BOLT #10 by briefly exemplifying how to pass the conditions to the DNS seed server.
Establish some rules for how a DNS seed is expected to parse conditions and handle possible conflicts (in case a key is repeated in multiple condition key-value pairs).
Even with push_msat, we need to make sure that funder can pay the fees,
so require that.
Also require that there be some funds above reserve on one side, otherwise
the channel is useless, and we risk that all outputs are dust.
Note: a side *may* reject the channel if funding_satoshis is too small
already, but this sets a clear minimum bar.
Fixes: #393
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Add requirements on accept_channel, so each side doesn't consider the
*other* reserve dust either.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
After more consideration, I believe that this is sufficient to ensure
one reserve is always non-dust.
The races which make us dig into the reserves can't currently take from
the fundee's reserve, so either the fundee has sufficient reserves, or
it can't add HTLCs which means no race.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 4: update sphinx packet test vector
In this commit, we update the test vector for the final onion packet. In
commit 068b0bccf9, the per-hop payloads
were updated to use 8 byte amounts everywhere. However, the test vectors
were not updated. In 578573f92f the test
vectors were updated to use the proper version prefix. However, this
assumed that the state of the vectors as is was correct.
To remedy this, we've updated the test vectors to reflect the final
result using the current format for encoding the per-hop payloads. This
final test vector was generated using the original tool that we used to
confirm compatibility between the C and Go versions.
The routing tagged field of one test vector was extracted from the
invoice incorrectly. The route included in the invoice has as base
fee of 1 resp. 2 msat (as described in the explanation), but the
extracted bech32 part had a 0 msat base fee.
Clarify that field `channel_reestablish`.`your_last_per_commitment_secret`
should be set to an all-zero array when no `per_commitment_secret` has
been received yet.
The description now suggests the use of an ephemeral private key, so
the reference code is simplified by using that concept. The reference
code is also updated to make fewer calls to undefined functions.
The new description introduces the concept of an ephemeral private key,
which I find easier to reason about and suggests a linear instead of
quadratic construction algorithm.
