Bitcoin: Wiederherstellung und Lightning
BOLT 11 invoices: what a Lightning payment request actually says
A signed invoice carries payment conditions; it is neither a reusable bank account nor proof of delivery.
Artikeltexte und technische Grafiken sind auf Englisch. Die Navigation ist in 7 Sprachen verfügbar.
Fachartikel
A structured request
A BOLT 11 invoice encodes a Lightning payment request with a network prefix, timestamp, tagged fields and a signature. Fields can include a payment hash, amount, description or description hash, expiry and routing hints. Not every invoice has a fixed amount. The payer’s wallet must interpret the actual fields instead of relying on the surrounding webpage’s label. 1
Expiry and destination
Expiry tells the payer how long the request is intended to remain usable; it does not reserve a route or liquidity. Routing hints can help reach a recipient whose channels are not fully public. An invoice’s cryptographic signature is useful for validating the request’s structure and origin key, but does not establish that the key belongs to a trustworthy merchant or that goods will arrive.
Invoice, address and receipt
An invoice is not an on-chain Bitcoin address. Nor is it the same as a Lightning address, which is a human-readable way to ask a service for payment information. A settled payment is another object again. Payment hashes and their preimages help the protocol coordinate completion; a wallet’s history and relevant payment details support later reconciliation. Do not reuse old invoice screenshots as new payment requests. 2
Practical review
Before paying, compare the decoded amount, network, description and expiry with what you intended to purchase. A description hash commits to supplied description material; the wallet needs that material to make it meaningful to a person. A valid invoice can still be unaffordable to route, expired by the time you act, or supplied by an impostor. Treat invoice decoding as one check in a broader payment decision.
Konkretes Beispiel
A store shows a price of 20,000 sats, but the decoded request has no amount. The payer must set and confirm the intended value. The website’s text is not a substitute for the wallet’s decoded payment request. No real invoice or payment destination is included in this example.