The Core devs decided to us the same bech32 HRP for Signet as is used
for the current Testnet3. This might be okay for on-chain addresses
since they are compatible in theory. But for invoices we want to use a
distinct HRP to distinguish testnet from signet.
Also see spec PR
https://github.com/lightningnetwork/lightning-rfc/pull/844 for more
information about the reasoning.
Modify the SignCompact function passed to invoice.Encode to receive the
message before it's hashed and hash it itself.
With this modification, the SignMessage rpc function from the signrpc
subserver can be used and an invoice can be encoded outside of lnd.
As a preliminary step to isolating zpay32 in migrations 01-11, we'll
split out the encoding and decoding logic into separate files. Migration
11 only requires invoice decoding, so this prevents us from needing to
copy in the encoding logic that would otherwise be unused.
This commit removes the unknown required feature bit check from the
invoice decoding logic. This allows greater utility to users of the
decodepayreq rpc since it can provide inspection of otherwise invalid
invoices. In the prior commit, this check moved into our path finding
logic, so invalid features taken from an invoice will instead cause a
failure when attempting to pay.
This commit updates the BOLT11 test vectors to use the updated versions
from the spec (with TLV bit set). This also pointed out that the
ordering was inconsistent with the spec, in that the payment secret
should be serialized before the feature vector.
This commit adds InvoiceExpryWatcher which is a separate class that
receives new invoices (and existing ones upon restart) from InvoiceRegistry
and actively watches their expiry. When an invoice is expired
InvoiceExpiryWatcher will call into InvoiceRegistry to cancel the
invoice and by that notify all subscribers about the state change.
This commit also consolidates the existing code duplication in parsing
payment hashes and description hashes into a single, combined method for
parsing 32-byte values. A similar change is made for encoding 32-byte
values.
zpay32/invoice: consolidate 32-byte encoding logic
This fixes an issue where the last tagged field of an invoice could get
broken due to the malleability of bech32 checksums.
The addition of a specific character in the second to last position of
the checksum could cause the previous signature field to mutate and thus
point to a different public node.
This commit checks that the size of the bech32 encoded invoice is not
greater than 7092 bytes, which is the maximum number of bytes that can
fit into a QR code. This mitigates a potential DoS vector where an attacker
could craft a very large bech32 invoice string containing an absurd amount
of route and/or hop hints. If sent to an application that processes
payment requests, this would allocate a burdensome amount of memory
due to the public key parsing for each route/hop hint.
For a 1.7MB payment request, this yielded about 38MB in allocations
from just parsing public keys:
```
45.51MB 7.31% 92.07% 45.51MB 7.31% math/big.nat.make
25.50MB 4.09% 96.16% 25.50MB 4.09% github.com/lightningnetwork/lnd/zpay32.bech32VerifyChecksum
1MB 0.16% 96.32% 39.50MB 6.34% github.com/lightningnetwork/lnd/zpay32.parseRouteHint
1MB 0.16% 96.48% 33.50MB 5.38% github.com/btcsuite/btcd/btcec.decompressPoint
0.50MB 0.08% 96.56% 7.50MB 1.20% crypto/elliptic.(*CurveParams).doubleJacobian
0.50MB 0.08% 96.64% 38MB 6.10% github.com/btcsuite/btcd/btcec.ParsePubKey
0 0% 96.64% 12MB 1.93% crypto/ecdsa.Verify
0 0% 96.64% 8MB 1.28% crypto/elliptic.(*CurveParams).ScalarBaseMult
0 0% 96.64% 12MB 1.93% crypto/elliptic.(*CurveParams).ScalarMult
```
With this change, memory usage will be far lower as decoding will exit
early with an error if the invoice is too large.
Since nilling the pubkey curve will lead to a nil-pointer exception if
the key is later used for signature verification, we make sure to make a
copy before nilling and spewing.
Before this commit, if an invoice encoded multiple `r` fields, we would
decode them as one single route. We fix this by allowing an invoice to
store multiple routes.
In this commit, we fix a logic error in our routine for converting a
uint64 to/from base32. Before this commit, we assumed that the max
number of groups was 12. However, the math.MaxUint64 (1<<64 - 1) can
actually consume more than 12 groups with an extra set of bits. Before
this commit, we would panic when attempting to parse an invoice
generated like so:
* addinvoice --amt 1337000 --expiry 99999999999999999
To fix this issue, we modify our logic to expect at most 13 groups.
Additionally, we've added a new test that would panic before applying
this commit.
Fixes#972.
New tests are added for creating, decoding, and re-encoding
litecoin invoices for both mainnet and testnet, as well as a test
that expects an error when the active network mismatches the
invoice.
This change fixes a bug when an invoice is decoded for a network
whose bech32 segwit prefix is longer than 2 characters. The length
of the Bech32HRPSegwit network parameter is used to determine
where in the human-readable portion of the invoice the amount
begins, rather than assuming it begins after the first four
characters.
Decode() now throws an error when the encoded invoice does
not match the active network.
Changes the minimum hrp length check to >= 3 instead of >= 4.
Also removes a redundant "if ...; err != nil check" that was raising
a warning in invoice.go.
When accessing a value from a byte slice, the value is returned as a
byte, which is just a uint8. When the first byte takes more than 3 bits
of space, shifting 5 bits left results in data loss.
This commit allows parseRoutingInfo to return an error when parsing a
routing info field whose length is not a multiple of 51 bytes, rather
than crash.
This commit refactors parsing each of the tagged fields of an invoice
into their own method. This makes the code easier to read and will allow
us to introduce unit tests for each parsing method.
