I'm clearly showing my age, suggesting ASCII; obviously UTF-8 makes
more sense. We also didn't have a *requirement* that it be a valid
encoding, so add that.
We already have an example ASCII description ('Please consider
supporting this project'), so just modify the other one to UTF-8
as provided by Jonathan.
Reported-by: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
