[WIP] Router payments persistence #2475
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
halseth
force-pushed
the
reliable-payments-router-persistence-rebased-on-pid-preimage-map
branch
from
75b0789 to
99991af
Compare
Give the switch access to the preimage cache, which we'll use to ensure we don't resend HTLCs that have already been settled.
As a step towards reliable tracking of preimages, we lookup the payment hash in the PreimageCache before attempting to forward the HTLC. This lays the foundation for repated sends of the same HTLC, as the caller doesn't have to know about the result of the previous send. If the previous send is still in flight, the preimage is not known, and the send will go on as before. If the payment already succeeded, the preimage will be in the cache, and we'll return early. This is important to not forward a payment that already succeeded, since it might lead to loss of funds. NOTE: This assumes that the preimage is ALWAYS added to the PreimageCache before the circuit is torn down. NOTE: The ControlTower currently doesn't allow reapeated sends to the same hash, but this will later be allowed.
As a step towards idempotent sends, we ignore any duplicate add message
when forwarding the HTLC. After a restart the caller can resend the
HTLC, and be sure that
1) if the payment already succeeded, the preimage will be
returned (see previous commit),
2) if the payment is already in flight, but no result is
available, the pending payment will be added and it will get
notified when the result comes back, and
3) if this is the first time this HTLC is sent it will continue
as before.
NOTE: The ControlTower currently doesn't allow us to re-send the HTLC,
but this will later be allowed.
To ensure atomicity between checking the PreimageCache and forwarding
the HTLC (committing the circuit), we aquire a multimutex for this
paymentID.
We use a multimutex so we can keep sending payments with unique
paymentIDs concurrently.
We need to ensure atomicity to avoid a few race cases arising from the
fact that operations are not done in the same db transaction. Without
the mutex we would risk to execute the order of operations
(LookupPreimage, AddPreimage, tear down circuit, commit circuit).
which made us forward an already settled payment. By ensuring there's a
lock around (LookupPreimage, commitCircuit) and (tearDown), the only
possible orders are
(AddPreimage, tearDown, LookupPreimage)
(AddPreimage, LookupPreimage, tearDown)
(LookupPreimage, commitCircuit, AddPreimage, tearDown)
(LookupPreimage, AddPreimage, commitCircuit, tearDown)
and we can recover even from restarts.
The same mutex functions as a lock around preimage lookup and adding the
pending payment. Without this mutex the operations
(LookupPreimage, AddPreimage, deliver preimage, add pending payment)
could occur, which would leave the preimage in limbo. With the lock
around (LookupPreimage, add pending payment), the possible orders are
(AddPreimage, LookupPreimage)
(LookupPreimage, add pending payment, AddPreimage, deliver preimage)
(LookupPreimage, AddPreimage, add pending payment, deliver preimage)
The (deliver preimage) operation cannot happen between (LookupPreimage)
and (add pending payment) since the lock will need to be acquired
sometime between (AddPreimage) and (deliver preimage).
This commit moves the responsibility of generating a unique payment ID from the switch to the router. This will make it easier for the router to keep track of which HTLCs were successfully forwarded onto the network, as it can replay the same HTLCs as long as the paymentIDs are kept.
define payAttemptStore
extract sendPayAttempt to switch
This commit makes SendHTLC in the switch async, making it return any encountered error or succcessfully retrieved preimage on the returned channels.
squash move vcontrol tower sq move control twer
2 tasks
halseth
force-pushed
the
reliable-payments-router-persistence-rebased-on-pid-preimage-map
branch
from
99991af to
a6a22ed
Compare
3 tasks
|
Replaced by #2761. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WIP
Builds on #2265