It misrenders on GitHub. Matt had a patch which changed the actual
form of the requiremnt, this uses ``` instead.
Based-on-Patch-By: Matt Corallo @TheBlueMatt
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
