db
This actor will synchronously make a backup of the database it was initialized with whenever it receives a ChannelPersisted event.
A minimal representation of a payment failure (suitable to store in a database).
A minimal representation of a hop in a payment route (suitable to store in a database).
An incoming payment received by this node.
An incoming payment received by this node. At first it is in a pending state once the payment request has been generated, then will become either a success (if we receive a valid HTLC) or a failure (if the payment request expires).
Bolt 11 payment request.
pre-image associated with the payment request's payment_hash.
distinguish different payment types (standard, swaps, etc).
absolute time in milli-seconds since UNIX epoch when the payment request was generated.
current status of the payment.
An outgoing payment sent by this node.
An outgoing payment sent by this node. At first it is in a pending state, then will become either a success or a failure.
internal payment identifier.
internal identifier of a parent payment, or id if single-part payment.
external payment identifier: lets lightning applications reconcile payments with their own db.
payment_hash.
distinguish different payment types (standard, swaps, etc).
amount that will be received by the target node, will be different from recipientAmount for trampoline payments.
amount that will be received by the final recipient.
id of the final recipient.
absolute time in milli-seconds since UNIX epoch when the payment was created.
Bolt 11 payment request (if paying from an invoice).
current status of the payment.
This database stores CMD_FULFILL_HTLC and CMD_FAIL_HTLC that we have received from downstream (either directly via UpdateFulfillHtlc or by extracting the value from the blockchain).
This database stores CMD_FULFILL_HTLC and CMD_FAIL_HTLC that we have received from downstream (either directly via UpdateFulfillHtlc or by extracting the value from the blockchain).
This means that this database is only used in the context of *relaying* payments.
We need to be sure that if downstream is able to pull funds from us, we can always do the same from upstream, otherwise we lose money. Hence the need for persistence to handle all corner cases.
Generic payment trait holding only the minimum information in the most plain type possible.
Generic payment trait holding only the minimum information in the most plain type possible. Notably, payment request is kept as a String, because deserialization is costly.
This object should only be used for a high level snapshot of the payments stored in the payment database.
Payment status should be of the correct type, but may not contain all the required data (routes, failures...).
This actor will synchronously make a backup of the database it was initialized with whenever it receives a ChannelPersisted event. To avoid piling up messages and entering an endless backup loop, it is supposed to be used with a bounded mailbox with a single item:
backup-mailbox { mailbox-type = "akka.dispatch.BoundedMailbox" mailbox-capacity = 1 mailbox-push-timeout-time = 0 }
Messages that cannot be processed will be sent to dead letters