As agreed at the previous meeting, we use the timestamp to prune,
so it does have to be a valid timestamp. We also suggest ignoring
if it's in the far future, too.
The minutes suggest we can prune for any reason, and that's really
true anyway; the requirements to keep it around are only SHOULD.
Note that this only applies to channel_update: node_announces
are not pruned (except, perhaps, by implication when all channels
are pruned)
Closes: #302
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
