d6d9ec6aa5
Previously the invoice registry wasn't aware of replayed htlcs. This was dealt with by keeping the invoice accept/settle logic idempotent, so that a replay wouldn't have an effect. This mechanism has two limitations: 1. No accurate tracking of the total amount paid to an invoice. The total amount couldn't just be increased with every htlc received, because it could be a replay which would lead to counting the htlc amount multiple times. Therefore the total amount was set to the amount of the first htlc that was received, even though there may have been multiple htlcs paying to the invoice. 2. Impossible to check htlc expiry consistently for hodl invoices. When an htlc is new, its expiry needs to be checked against the invoice cltv delta. But for a replay, that check must be skipped. The htlc was accepted in time, the invoice was moved to the accepted state and a replay some blocks later shouldn't lead to that htlc being cancelled. Because the invoice registry couldn't recognize replays, it stopped checking htlc expiry heights when the invoice reached the accepted state. This prevents hold htlcs from being cancelled after a restart. But unfortunately this also caused additional htlcs to be accepted on an already accepted invoice without their expiry being checked. In this commit, the invoice registry starts to persistently track htlcs so that replays can be recognized. For replays, an htlc resolution action is returned early. This fixes both limitations mentioned above. |
||
|---|---|---|
| .. | ||
| addr_test.go | ||
| addr.go | ||
| channel_cache_test.go | ||
| channel_cache.go | ||
| channel_test.go | ||
| channel.go | ||
| codec.go | ||
| db_test.go | ||
| db.go | ||
| doc.go | ||
| error.go | ||
| fees.go | ||
| forwarding_log_test.go | ||
| forwarding_log.go | ||
| forwarding_package_test.go | ||
| forwarding_package.go | ||
| graph_test.go | ||
| graph.go | ||
| invoice_test.go | ||
| invoices.go | ||
| legacy_serialization.go | ||
| log.go | ||
| meta_test.go | ||
| meta.go | ||
| migration_09_legacy_serialization.go | ||
| migration_10_route_tlv_records.go | ||
| migration_11_invoices_test.go | ||
| migration_11_invoices.go | ||
| migrations_test.go | ||
| migrations.go | ||
| nodes_test.go | ||
| nodes.go | ||
| options.go | ||
| payment_control_test.go | ||
| payment_control.go | ||
| payments_test.go | ||
| payments.go | ||
| README.md | ||
| reject_cache_test.go | ||
| reject_cache.go | ||
| waitingproof_test.go | ||
| waitingproof.go | ||
| witness_cache_test.go | ||
| witness_cache.go | ||
channeldb
The channeldb implements the persistent storage engine for lnd and
generically a data storage layer for the required state within the Lightning
Network. The backing storage engine is
boltdb, an embedded pure-go key-value store
based off of LMDB.
The package implements an object-oriented storage model with queries and mutations flowing through a particular object instance rather than the database itself. The storage implemented by the objects includes: open channels, past commitment revocation states, the channel graph which includes authenticated node and channel announcements, outgoing payments, and invoices
Installation and Updating
$ go get -u github.com/lightningnetwork/lnd/channeldb