This is a consequence of commit d1fbfd30f8: we now only use *outgoing* `channel_update` messages to build a route.
Basically the node publishing the `channel_update` says: I can only send htlcs > `htlc_minimum_msat` through this channel.
I think this is consistent with the current definition of the `amount_below_minimum` error (BOLT 4):
> If the HTLC does not reach the current minimum amount, we tell them the amount of the incoming HTLC and the current channel setting for the outgoing channel:
I regularized the descriptions in the localfeatures table, so keep a careful eye on the accuracy of those. Otherwise, fairly standard editing in this very short section.
Added text for lack of globalfeatures flags.
* BOLT 7: mention Tor hidden service.
This is a common term to search for, rather than onion address (which is
what Tor hidden services use).
Reported-by: Alan Manuel K. Gloria <almkglor@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This would have saved me a lot of time and pain. Sure, I should have realized that the document says something paradoxical (signature of the data part.... but the data part includes the signature..... so I should have guessed it meant "excluding the signature"...)
Explicit mention of the signature part might help people. Might not. But helps to be explicit.
Usually the counterparty would only hurt itself if it chooses too low a `dust_limit`, but in the specific scenario of a data loss, we want the counterparty's commitment tx to be relayed and confirmed on the network.
Doesn't take any more space (we could actually reduce millionths to 24 bits,
but that starts to look silly), but it's simpler and allows for cases where
there's no payment amount.
Closes: #296
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In this commit, we modify the cooperative closing transaction to use
version 2. Currently eclair and lnd already use version 2, while
c-lightning uses version 1. The commitment transaction already uses
version 2, so making this additional transaction (which spends the
funding output) also use version 2 would be consistent. Additionally,
as a best practice, we should be using the highest currently
defined/use transaction version.
HTLC outputs can be resolved by (1) using revocation key,
(2) timeout/preimage use if that's possible, or (3) the cheating party's
HTLC-success/HTLC-timeout tx (which we also specify that you have to
spend using revocation key).
Hopefully this is now clearer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This got a little messy as some changes now needed to be applied in
two places, and other wording has been completely removed. Another
pass on top will be required.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The proof-readers rightly noted how confusing the current treatment of
HTLCs is. There are four different cases, but I tried to address them
in two separate sections, with conditionals.
This expands it out, separating sections for Our Commitment Tx and
Their Commitment Tx, then subsections for our HTLCs and their HTLCs
in each one.
It means some duplicated requirements and rationales, but it should now
be very clear.
As a side effect, we no longer refer to A and B at all: it's all US and THEM.
This needs further clearing up, but for now makes it clear what *we* need to do
for all cases.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
second pass copy edit to line 253, according to stylesheet
update node terminology to remove ambiguity; update conventions section and implement consistent usage of terms: origin node, final node, processing node, hop, sending peer, and receiving peer
