fc9af92dd9
Prior to AMP, there could only be one HTLC set. Now that there can be multiple, we introduce the inherent risk that we might be persisting a settle/accept of the wrong HTLC set. To migitigate this risk, we add a check to assert that an invoice can only be transitioned into an Accepted or Settled state if the specified HTLC set is non-empty, i.e. has accepted HTLCs. To do this check, we unroll the loops in UpdateInvoice to first process any added or canceled HTLCs. This ensures that the set of accepted HTLCs is up-to-date when we got to transition the invoice into a new state, at which point we can accurately check that the HTLC set is non-empty. Previously this sort of check wasn't possible because a newly added HTLC wouldn't be populated on the invoice when going to call updateInvoiceState. Once the invoice-level transition checks have completed, we complete a final pass to move the HTLCs into their final states and recompute the amount paid. With this refactor, it is now possible to make stronger assertions about the invoice and the state transitions being made by the invoiceregistry before those changes are ultimately persisted. |
||
|---|---|---|
| .. | ||
| kvdb | ||
| migration | ||
| migration_01_to_11 | ||
| migration12 | ||
| migration13 | ||
| migration16 | ||
| migration20 | ||
| migration21 | ||
| migtest | ||
| 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 | ||
| duplicate_payments.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 | ||
| mp_payment.go | ||
| nodes_test.go | ||
| nodes.go | ||
| options_test.go | ||
| options.go | ||
| paginate.go | ||
| payment_control_test.go | ||
| payment_control.go | ||
| payments_test.go | ||
| payments.go | ||
| peers_test.go | ||
| peers.go | ||
| README.md | ||
| reject_cache_test.go | ||
| reject_cache.go | ||
| reports_test.go | ||
| reports.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