Lightning Book of BOLTs

BOLT #11: Invoice Protocol for Lightning Payments

A simple, extendable, QR-code-ready protocol for requesting payments over Lightning.

Table of Contents

Encoding Overview

The format for a Lightning invoice uses bech32 encoding, which is already used for Bitcoin Segregated Witness. It can be simply reused for Lightning invoices even though its 6-character checksum is optimized for manual entry, which is unlikely to happen often given the length of Lightning invoices.

If a URI scheme is desired, the current recommendation is to either use ‘lightning:’ as a prefix before the BOLT-11 encoding (note: not ‘lightning://’), or for fallback to Bitcoin payments, to use ‘bitcoin:’, as per BIP-21, with the key ‘lightning’ and the value equal to the BOLT-11 encoding.

Requirements

A writer: - MUST encode the payment request in Bech32 (see BIP-0173) - SHOULD use upper case for QR codes (see BIP-0173) - MAY exceed the 90-character limit specified in BIP-0173.

A reader: - MUST parse the address as Bech32, as specified in BIP-0173 (also without the character limit). - Note: this includes handling uppercase as specified by BIP-0173 - if the checksum is incorrect: - MUST fail the payment.

Human-Readable Part

The human-readable part of a Lightning invoice consists of two sections: 1. prefix: ln + BIP-0173 currency prefix (e.g. lnbc for Bitcoin mainnet, lntb for Bitcoin testnet, lntbs for Bitcoin signet, and lnbcrt for Bitcoin regtest) 1. amount: optional number in that currency, followed by an optional multiplier letter. The unit encoded here is the ‘social’ convention of a payment unit – in the case of Bitcoin the unit is ‘bitcoin’ NOT satoshis.

The following multiplier letters are defined:

Requirements

A writer: - MUST encode prefix using the currency required for successful payment. - if a specific minimum amount is required for successful payment: - MUST include that amount. - MUST encode amount as a positive decimal integer with no leading 0s. - If the p multiplier is used the last decimal of amount MUST be 0. - SHOULD use the shortest representation possible, by using the largest multiplier or omitting the multiplier.

A reader: - if it does NOT understand the prefix: - MUST fail the payment. - if the amount is empty: - SHOULD indicate to the payer that amount is unspecified. - otherwise: - if amount contains a non-digit OR is followed by anything except a multiplier (see table above): - MUST fail the payment. - if the multiplier is present: - MUST multiply amount by the multiplier value to derive the amount required for payment. - if multiplier is p and the last decimal of amount is not 0: - MUST fail the payment.

Rationale

The amount is encoded into the human readable part, as it’s fairly readable and a useful indicator of how much is being requested.

Donation addresses often don’t have an associated amount, so amount is optional in that case. Usually a minimum payment is required for whatever is being offered in return.

The p multiplier would allow to specify sub-millisatoshi amounts, which cannot be transferred on the network, since HTLCs are denominated in millisatoshis. Requiring a trailing 0 decimal ensures that the amount represents an integer number of millisatoshis.

Note that non-largest multipliers have been encountered in the wild, and as such invoice parsers should handle them.

Data Part

The data part of a Lightning invoice consists of multiple sections:

  1. timestamp: seconds-since-1970 (35 bits, big-endian)
  2. zero or more tagged parts
  3. signature: compact ECDSA/secp256k1 signature of the above (520 bits: 64-byte R||S + 1-byte recovery id)

Requirements

A writer: - MUST set timestamp to the number of seconds since Midnight 1 January 1970, UTC in big-endian. - MUST set signature to a valid compact ECDSA signature over secp256k1 of the SHA-256 hash of: the human-readable part (as UTF-8 bytes) concatenated with the data part (excluding the signature), with 0 bits appended to pad to a byte boundary. The signature is encoded as 64 bytes (R || S), followed by a trailing 1-byte recovery id in {0,1,2,3}.

A reader: - MUST check that the signature is valid (see the n tagged field specified below).

Rationale

signature covers an exact number of bytes even though the SHA2 standard actually supports hashing in bit boundaries, because it’s not widely implemented. The recovery ID allows public-key recovery, so the identity of the payee node can be implied.

Tagged Fields

Each Tagged Field is of the form:

  1. type (5 bits)
  2. data_length (10 bits, big-endian)
  3. data (data_length x 5 bits)

Note that the maximum length of a Tagged Field’s data is constricted by the maximum value of data_length. This is 1023 x 5 bits, or 639 bytes.

Currently defined tagged fields are:

Requirements

A writer: - MUST include exactly one p field. - MUST include exactly one s field. - MUST set payment_hash to the SHA2 256-bit hash of the payment_preimage that will be given in return for payment. - MUST include either exactly one d or exactly one h field. - if d is included: - MUST set d to a valid UTF-8 string. - SHOULD use a complete description of the purpose of the payment. - if h is included: - MUST make the preimage of the hashed description in h available through some unspecified means. - SHOULD use a complete description of the purpose of the payment. - MAY include one x field. - if x is included: - MUST use the minimum data_length possible, i.e. no leading 0 field-elements. - SHOULD include one c field (min_final_cltv_expiry_delta). - MUST set c to the minimum cltv_expiry it will accept for the last HTLC in the route. - MUST use the minimum data_length possible, i.e. no leading 0 field-elements. - MAY include one n field. (Otherwise performing public-key recovery is required) - MUST set n to the public key used to create the signature. - MAY include one or more f fields. - for Bitcoin payments: - MUST set an f field to a valid witness version and program, OR to 17 followed by a public key hash, OR to 18 followed by a script hash. - if there is NOT a public channel associated with its public key: - MUST include at least one r field. - r field MUST contain one or more ordered entries, indicating the forward route from a public node to the final destination. - Note: for each entry, the pubkey is the node ID of the start of the channel; short_channel_id is the short channel ID field to identify the channel; and fee_base_msat, fee_proportional_millionths, and cltv_expiry_delta are as specified in BOLT #7. - MAY include more than one r field to provide multiple routing options. - if 9 contains non-zero bits: - MUST use the minimum data_length possible to encode the non-zero bits with no 0 field-elements at the start. - otherwise: - MUST omit the 9 field altogether. - MUST pad field data to a multiple of 5 bits, using 0s. - if a writer offers more than one of any field type, it: - MUST specify the most-preferred field first, followed by less-preferred fields, in order.

A reader: - MUST skip over f fields that use an unknown version. - MUST fail the payment if any field with fixed data_length (p, h, s, n) does not have the correct length (52, 52, 52, 53). - MUST fail the payment if neither a d field nor a h field is present, or if both are present. - if the 9 field contains unknown odd bits that are non-zero: - MUST ignore the bit. - if the 9 field contains unknown even bits that are non-zero: - MUST fail the payment. - SHOULD indicate the unknown bit to the user. - MUST check that the SHA2 256-bit hash in the h field exactly matches the hashed description. - if a valid n field is provided: - MUST use the n field to validate the signature instead of performing public-key recovery. - If the signature is not compliant with the low-S standard rulelow-S: - MUST fail the payment - otherwise: - MUST perform ECDSA public-key recovery and accept both high-S and low-S signatures. - if a valid s field is not provided: - MUST fail the payment. - otherwise: - MUST use the s field as payment_secret - if the c field (min_final_cltv_expiry_delta) is not provided: - MUST use an expiry delta of at least 18 when making the payment - if an m field is provided: - MUST use that as payment_metadata - if a c, x, or 9 field is provided which has a non-minimal data_length (i.e. begins with 0 field elements): - SHOULD treat the invoice as invalid.

Rationale

The type-and-length format allows future extensions to be backward compatible. data_length is always a multiple of 5 bits, for easy encoding and decoding.

The d field allows inline descriptions, but may be insufficient for complex orders. Thus, the h field allows a summary: though the method by which the description is served is as-yet unspecified and will probably be transport dependent.

The m field allows metadata to be attached to the payment. This supports applications where the recipient doesn’t keep any context for the payment.

The n field can be used to explicitly specify the destination node ID, instead of requiring public-key recovery.

The x field gives warning as to when a payment will be refused: mainly to avoid confusion. The default was chosen to be reasonable for most payments and to allow sufficient time for on-chain payment, if necessary.

The c field allows a way for the destination node to require a specific minimum CLTV expiry for its incoming HTLC. Destination nodes may use this to require a higher, more conservative value than the default one (depending on their fee estimation policy and their sensitivity to time locks). Note that remote nodes in the route specify their required cltv_expiry_delta in the channel_update message, which they can update at all times.

The f field allows on-chain fallback; however, this may not make sense for tiny or time-sensitive payments. It’s possible that new address forms will appear; thus, multiple f fields (in an implied preferred order) help with transition, and f fields with versions 19-31 will be ignored by readers.

The r field allows limited routing assistance: as specified, it only allows minimum information to use private channels, however, it could also assist in future partial-knowledge routing.

Security Considerations for Payment Descriptions

Payment descriptions are user-defined and provide a potential avenue for injection attacks: during the processes of both rendering and persistence.

Payment descriptions should always be sanitized before being displayed in HTML/Javascript contexts (or any other dynamically interpreted rendering frameworks). Implementers should be extra perceptive to the possibility of reflected XSS attacks, when decoding and displaying payment descriptions. Avoid optimistically rendering the contents of the payment request until all validation, verification, and sanitization processes have been successfully completed.

Furthermore, consider using prepared statements, input validation, and/or escaping, to protect against injection vulnerabilities in persistence engines that support SQL or other dynamically interpreted querying languages.

Don’t be like the school of Little Bobby Tables.

Feature Bits

Feature bits allow forward and backward compatibility, and follow the it’s ok to be odd rule. Features appropriate for use in the 9 field are marked in BOLT 9.

The field is big-endian. The least-significant bit is numbered 0, which is even, and the next most significant bit is numbered 1, which is odd.

Requirements

A writer: - MUST set the 9 field to a feature vector compliant with the BOLT 9 origin node requirements.

A reader: - if the feature vector does not set all known, transitive feature dependencies: - MUST NOT attempt the payment. - if the basic_mpp feature is offered in the invoice: - MAY pay using Basic multi-part payments. - otherwise: - MUST NOT use Basic multi-part payments.

Payer / Payee Interactions

These are generally defined by the rest of the Lightning BOLT series, but it’s worth noting that BOLT #4 specifies that the payee SHOULD accept up to twice the expected amount, so the payer can make payments harder to track by adding small variations.

The intent is that the payer recovers the payee’s node ID from the signature, and after checking that conditions such as fees, expiry, and block timeout are acceptable, attempts a payment. It can use r fields to augment its routing information, if necessary to reach the final node.

If the payment succeeds but there is a later dispute, the payer can prove both the signed offer from the payee and the successful payment.

Payer / Payee Requirements

A payer: - after the timestamp plus expiry has passed: - SHOULD NOT attempt a payment. - otherwise: - if a Lightning payment fails: - MAY attempt to use the address given in the first f field that it understands for payment. - MAY use the sequence of channels, specified by the r field, to route to the payee. - SHOULD consider the fee amount and payment timeout before initiating payment. - SHOULD use the first p field as the payment hash.

A payee: - after the timestamp plus expiry has passed: - SHOULD NOT accept a payment.

Implementation

https://github.com/rustyrussell/lightning-payencode

Examples

NB: all the following examples are signed with priv_key=e126f68f7eafcc8b74f54d269fe206be715000f94dac067d1c04a8ca3b2db734. All invoices contain a payment_secret=1111111111111111111111111111111111111111111111111111111111111111 unless otherwise noted. Signatures are deterministic and generated using RFC6979 (using HMAC-SHA256). Note that even though using a low R would save 1 byte in the DER-encoded signature (by avoiding the need for a leading zero byte when the most significant bit is set), it is not enforced in this specification.

Please make a donation of any amount using payment_hash 0001020304050607080900010203040506070809000102030405060708090102 to me @03e7156ae33b0a208d0744199163177e909e80176e55d97a2f221ede0f934dd9ad

lnbc1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpl2pkx2ctnv5sxxmmwwd5kgetjypeh2ursdae8g6twvus8g6rfwvs8qun0dfjkxaq9qrsgq357wnc5r2ueh7ck6q93dj32dlqnls087fxdwk8qakdyafkq3yap9us6v52vjjsrvywa6rt52cm9r9zqt8r2t7mlcwspyetp5h2tztugp9lfyql

Breakdown:

Please send $3 for a cup of coffee to the same peer, within one minute

lnbc2500u1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysxxatsyp3k7enxv4jsxqzpu9qrsgquk0rl77nj30yxdy8j9vdx85fkpmdla2087ne0xh8nhedh8w27kyke0lp53ut353s06fv3qfegext0eh0ymjpf39tuven09sam30g4vgpfna3rh

Breakdown:

Please send 0.0025 BTC for a cup of nonsense (ナンセンス 1杯) to the same peer, within one minute

lnbc2500u1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0xqzpu9qrsgqhtjpauu9ur7fw2thcl4y9vfvh4m9wlfyz2gem29g5ghe2aak2pm3ps8fdhtceqsaagty2vph7utlgj48u0ged6a337aewvraedendscp573dxr

Breakdown:

Now send $24 for an entire list of things (hashed)

lnbc20m1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqs9qrsgq7ea976txfraylvgzuxs8kgcw23ezlrszfnh8r6qtfpr6cxga50aj6txm9rxrydzd06dfeawfk6swupvz4erwnyutnjq7x39ymw6j38gp7ynn44

Breakdown:

The same, on testnet, with a fallback address mk2QpYatsKicvFVuTAQLBryyccRXMUaGHP

lntb20m1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygshp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqfpp3x9et2e20v6pu37c5d9vax37wxq72un989qrsgqdj545axuxtnfemtpwkc45hx9d2ft7x04mt8q7y6t0k2dge9e7h8kpy9p34ytyslj3yu569aalz2xdk8xkd7ltxqld94u8h2esmsmacgpghe9k8

Breakdown:

On mainnet, with fallback address 1RustyRX2oai4EYYDpQGWvEL62BBGqN9T with extra routing info to go via nodes 029e03a901b85534ff1e92c43c74431f7ce72046060fcf7a95c37e148f78c77255 then 039e03a901b85534ff1e92c43c74431f7ce72046060fcf7a95c37e148f78c77255

lnbc20m1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfpp3qjmp7lwpagxun9pygexvgpjdc4jdj85fr9yq20q82gphp2nflc7jtzrcazrra7wwgzxqc8u7754cdlpfrmccae92qgzqvzq2ps8pqqqqqqpqqqqq9qqqvpeuqafqxu92d8lr6fvg0r5gv0heeeqgcrqlnm6jhphu9y00rrhy4grqszsvpcgpy9qqqqqqgqqqqq7qqzq9qrsgqdfjcdk6w3ak5pca9hwfwfh63zrrz06wwfya0ydlzpgzxkn5xagsqz7x9j4jwe7yj7vaf2k9lqsdk45kts2fd0fkr28am0u4w95tt2nsq76cqw0

Breakdown:

On mainnet, with fallback (P2SH) address 3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX

lnbc20m1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygshp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqfppj3a24vwu6r8ejrss3axul8rxldph2q7z99qrsgqz6qsgww34xlatfj6e3sngrwfy3ytkt29d2qttr8qz2mnedfqysuqypgqex4haa2h8fx3wnypranf3pdwyluftwe680jjcfp438u82xqphf75ym

Breakdown:

On mainnet, with fallback (P2WPKH) address bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

lnbc20m1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygshp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqfppqw508d6qejxtdg4y5r3zarvary0c5xw7k9qrsgqt29a0wturnys2hhxpner2e3plp6jyj8qx7548zr2z7ptgjjc7hljm98xhjym0dg52sdrvqamxdezkmqg4gdrvwwnf0kv2jdfnl4xatsqmrnsse

On mainnet, with fallback (P2WSH) address bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3

lnbc20m1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygshp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqfp4qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q9qrsgq9vlvyj8cqvq6ggvpwd53jncp9nwc47xlrsnenq2zp70fq83qlgesn4u3uyf4tesfkkwwfg3qs54qe426hp3tz7z6sweqdjg05axsrjqp9yrrwc

On mainnet, with fallback (P2TR) address bc1pptdvg0d2nj99568qn6ssdy4cygnwuxgw2ukmnwgwz7jpqjz2kszse2s3lm

lnbc20m1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfp4pptdvg0d2nj99568qn6ssdy4cygnwuxgw2ukmnwgwz7jpqjz2kszs9qrsgqy606dznq28exnydt2r4c29y56xjtn3sk4mhgjtl4pg2y4ar3249rq4ajlmj9jy8zvlzw7cr8mggqzm842xfr0v72rswzq9xvr4hknfsqwmn6xd

Please send 0.00967878534 BTC for a list of items within one week, amount in pico-BTC

lnbc9678785340p1pwmna7lpp5gc3xfm08u9qy06djf8dfflhugl6p7lgza6dsjxq454gxhj9t7a0sd8dgfkx7cmtwd68yetpd5s9xar0wfjn5gpc8qhrsdfq24f5ggrxdaezqsnvda3kkum5wfjkzmfqf3jkgem9wgsyuctwdus9xgrcyqcjcgpzgfskx6eqf9hzqnteypzxz7fzypfhg6trddjhygrcyqezcgpzfysywmm5ypxxjemgw3hxjmn8yptk7untd9hxwg3q2d6xjcmtv4ezq7pqxgsxzmnyyqcjqmt0wfjjq6t5v4khxsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygsxqyjw5qcqp2rzjq0gxwkzc8w6323m55m4jyxcjwmy7stt9hwkwe2qxmy8zpsgg7jcuwz87fcqqeuqqqyqqqqlgqqqqn3qq9q9qrsgqrvgkpnmps664wgkp43l22qsgdw4ve24aca4nymnxddlnp8vh9v2sdxlu5ywdxefsfvm0fq3sesf08uf6q9a2ke0hc9j6z6wlxg5z5kqpu2v9wz

Breakdown:

Please send $30 for coffee beans to the same peer, which supports features 8, 14 and 99, using secret 0x1111111111111111111111111111111111111111111111111111111111111111

lnbc25m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5vdhkven9v5sxyetpdeessp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygs9q5sqqqqqqqqqqqqqqqqsgq2a25dxl5hrntdtn6zvydt7d66hyzsyhqs4wdynavys42xgl6sgx9c4g7me86a27t07mdtfry458rtjr0v92cnmswpsjscgt2vcse3sgpz3uapa

Breakdown:

Same, but all upper case.

LNBC25M1PVJLUEZPP5QQQSYQCYQ5RQWZQFQQQSYQCYQ5RQWZQFQQQSYQCYQ5RQWZQFQYPQDQ5VDHKVEN9V5SXYETPDEESSP5ZYG3ZYG3ZYG3ZYG3ZYG3ZYG3ZYG3ZYG3ZYG3ZYG3ZYG3ZYG3ZYGS9Q5SQQQQQQQQQQQQQQQQSGQ2A25DXL5HRNTDTN6ZVYDT7D66HYZSYHQS4WDYNAVYS42XGL6SGX9C4G7ME86A27T07MDTFRY458RTJR0V92CNMSWPSJSCGT2VCSE3SGPZ3UAPA

Same, but including fields which must be ignored.

lnbc25m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5vdhkven9v5sxyetpdeessp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygs9q5sqqqqqqqqqqqqqqqqsgq2qrqqqfppnqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqppnqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpp4qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqhpnqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqhp4qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqspnqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqsp4qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqnp5qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqnpkqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqz599y53s3ujmcfjp5xrdap68qxymkqphwsexhmhr8wdz5usdzkzrse33chw6dlp3jhuhge9ley7j2ayx36kawe7kmgg8sv5ugdyusdcqzn8z9x

Breakdown:

Please send 0.01 BTC with payment metadata 0x01fafaf0

lnbc10m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdp9wpshjmt9de6zqmt9w3skgct5vysxjmnnd9jx2mq8q8a04uqsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygs9q2gqqqqqqsgq7hf8he7ecf7n4ffphs6awl9t6676rrclv9ckg3d3ncn7fct63p6s365duk5wrk202cfy3aj5xnnp5gs3vrdvruverwwq7yzhkf5a3xqpd05wjc

Breakdown:

Public-key recovery with high-S signature

lnbc1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpl2pkx2ctnv5sxxmmwwd5kgetjypeh2ursdae8g6twvus8g6rfwvs8qun0dfjkxaq9qrsgq357wnc5r2ueh7ck6q93dj32dlqnls087fxdwk8qakdyafkq3yap2r09nt4ndd0unm3z9u5t48y6ucv4r5sg7lk98c77ctvjczkspk5qprc90gx

Breakdown:

Examples of Invalid Invoices

Same, but adding invalid unknown feature 100

lnbc25m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5vdhkven9v5sxyetpdeessp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygs9q4psqqqqqqqqqqqqqqqqsgqtqyx5vggfcsll4wu246hz02kp85x4katwsk9639we5n5yngc3yhqkm35jnjw4len8vrnqnf5ejh0mzj9n3vz2px97evektfm2l6wqccp3y7372

Breakdown:

Bech32 checksum is invalid.

lnbc2500u1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0xqzpuyk0sg5g70me25alkluzd2x62aysf2pyy8edtjeevuv4p2d5p76r4zkmneet7uvyakky2zr4cusd45tftc9c5fh0nnqpnl2jfll544esqchsrnt

Malformed bech32 string (no 1)

pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0xqzpuyk0sg5g70me25alkluzd2x62aysf2pyy8edtjeevuv4p2d5p76r4zkmneet7uvyakky2zr4cusd45tftc9c5fh0nnqpnl2jfll544esqchsrny

Malformed bech32 string (mixed case)

LNBC2500u1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0xqzpuyk0sg5g70me25alkluzd2x62aysf2pyy8edtjeevuv4p2d5p76r4zkmneet7uvyakky2zr4cusd45tftc9c5fh0nnqpnl2jfll544esqchsrny

Signature is not recoverable.

lnbc2500u1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysxxatsyp3k7enxv4jsxqzpusp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygs9qrsgqwgt7mcn5yqw3yx0w94pswkpq6j9uh6xfqqqtsk4tnarugeektd4hg5975x9am52rz4qskukxdmjemg92vvqz8nvmsye63r5ykel43pgz7zq0g2

String is too short.

lnbc1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpl2pkx2ctnv5sxxmmwwd5kgetjypeh2ursdae8g6na6hlh

Invalid multiplier

lnbc2500x1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysxxatsyp3k7enxv4jsxqzpusp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygs9qrsgqrrzc4cvfue4zp3hggxp47ag7xnrlr8vgcmkjxk3j5jqethnumgkpqp23z9jclu3v0a7e0aruz366e9wqdykw6dxhdzcjjhldxq0w6wgqcnu43j

Invalid sub-millisatoshi precision.

lnbc2500000001p1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysxxatsyp3k7enxv4jsxqzpusp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygs9qrsgq0lzc236j96a95uv0m3umg28gclm5lqxtqqwk32uuk4k6673k6n5kfvx3d2h8s295fad45fdhmusm8sjudfhlf6dcsxmfvkeywmjdkxcp99202x

Missing required s field.

lnbc20m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqs9qrsgq7ea976txfraylvgzuxs8kgcw23ezlrszfnh8r6qtfpr6cxga50aj6txm9rxrydzd06dfeawfk6swupvz4erwnyutnjq7x39ymw6j38gp49qdkj

Non canonical signature (high-S) with ‘n’ field defined

lnbc25m1p70xwfzpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpl2pkx2ctnv5sxxmmwwd5kgetjypeh2ursdae8g6twvus8g6rfwvs8qun0dfjkxaqnp4q0n326hr8v9zprg8gsvezcch06gfaqqhde2aj730yg0durunfhv66sp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygs9qrsgqsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygsp5cfzp9ugllvk03rltd6hvndxj26ux6gcxc5azyxk060rj9tzghct5zvjlps76gx8wpq5yuu79688k8gnm2c0al6v608s96l0xzrrlqqwnzxmu

Authors

[ FIXME: ]

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.