Most obviously, we want this for BASE AMP, but it's useful in future.
Even though even bits won't cause existing implementations to know
they can't pay the invoice, it will allow it in future once everyone
has upgraded.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I was trying to compactly indicate that the considered alternative to
multiplier postfixes was just express everything in millisatoshi, but
it's just confusing, and anyway there are other notations we didn't use
so it seems like a weird thing to explain.
Reported-by: @cdecker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
a.k.a. landonmutch style, where requirements are explicit and bullet-pointed.
This also tightens requirements:
1. New requirement (previously implied) that writer use correct prefix.
2. Reader MUST rather than SHOULD fail malformed `amount`.
It also makes it clear that writer can omit the multiplier.
Fixes: #442
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
Our 10-bit length means up to 1023 5-bit words, or 639 bytes. But `h`
is horribly underspecified since we don't have a general solution: using
a URL is a privacy problem, for example. It might make sense for a future
transport standard (eg. lightning over HTML, or lightning-over-NFC), but
it's fairly unusable at the moment.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
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.
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>
Added an optional `c` field in the payment request specifying the
minimum `cltv_expiry` to use for the last htlc in the route. If
not provided, default value is 9.
This commit also clarifies how `channel_update` messages are only
to be used in the context of relaying payments, and how both htlc
amounts and expiries are to be calculated backwards from the values
provided in the payment request.
Not needing the `channel_update` for the first channel in a route also
means that it is possible to make a payment through a channel which
hasn't had any announcements yet.
This is unofficial, since we don't have IANA tag, but it doesn't
clash with any existing one. We'll see if this turns out to be something
people want.
Closes: #206
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 11: fix formatting typo, and `r` length value.
The r field is 408 bytes long, which is 82 characters encoded;
this should have been updated when the fee and cltv sizes were
updated (prior to merge into repo).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 11: `channel_id`->`short_channel_id`
