Add offer manager #2566
Merged
Add offer manager #2566
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
thomash-acinq
force-pushed
the
bolt12-option-db
branch
4 times, most recently
from
d3dc04b
to
fee48ff
Compare
thomash-acinq
force-pushed
the
bolt12-option-db
branch
6 times, most recently
from
558ebaf
to
bcf72e0
Compare
thomash-acinq
force-pushed
the
bolt12-option-db
branch
2 times, most recently
from
4cc0fc0
to
e915059
Compare
thomash-acinq
force-pushed
the
bolt12-option-db
branch
2 times, most recently
from
0c19ff8
to
4250061
Compare
Because offers are a very generic mechanism, handling them can require interacting with an inventory system (do we actually have the quantity that the payer is requesting) or other such systems which do not have their place inside eclair. For this reason offer handlers must be implemented as plugins that communicate with the offer manager. On startup, the offer handlers must register their offers with the offer manager, the offer manager will then forward the invoice requests and blinded payments to the relevant offer handler for approval.
thomash-acinq
force-pushed
the
bolt12-option-db
branch
from
4250061
to
4db3e31
Compare
t-bast
reviewed
Feb 24, 2023
eclair-core/src/main/scala/fr/acinq/eclair/db/sqlite/SqlitePaymentsDb.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/payment/receive/MultiPartHandler.scala
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/payment/receive/MultiPartHandler.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/offer/OfferManager.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/offer/OfferManager.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/offer/OfferManager.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/offer/OfferManager.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/offer/OfferManager.scala
Outdated
Show resolved
Hide resolved
t-bast
reviewed
Feb 24, 2023
eclair-core/src/test/scala/fr/acinq/eclair/integration/OfferIntegrationSpec.scala
Outdated
Show resolved
Hide resolved
t-bast
reviewed
Mar 17, 2023
eclair-core/src/main/scala/fr/acinq/eclair/payment/receive/MultiPartHandler.scala
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/db/sqlite/SqlitePaymentsDb.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/message/OnionMessages.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/payment/offer/OfferManager.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/payment/offer/OfferManager.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/payment/offer/OfferManager.scala
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/payment/offer/OfferManager.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/payment/offer/OfferManager.scala
Outdated
Show resolved
Hide resolved
- remove unnecessary `Try` - rename `GetIncomingPaymentActor` commands - restore standard -> blinded failure check
…s on OnionMessages.scala
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## master #2566 +/- ##
==========================================
+ Coverage 85.50% 85.72% +0.22%
==========================================
Files 211 212 +1
Lines 16827 16992 +165
Branches 725 714 -11
==========================================
+ Hits 14388 14567 +179
+ Misses 2439 2425 -14
|
Dummy is usually used for test or invalid data, whereas here we're just storing a minimal version of the Bolt 12 invoice, so we rename it MinimalBolt12Invoice. We also add an explicit constructor for it that forces callers to provide the data we expect to store. Note that we remove the `features` field: using `nodeParams.features` could be incorrect if the invoice_request's features don't include some of our node's optional features. This is unused now anyway, but more future-proof this way.
This commit refactors the offer manager without any meaningful change in the business logic itself: - move types to a separate file to isolate codec details - make plugin data optional - add debug logs in failure cases - let plugin specify the `invoice_error` message - avoid repeated calls to `Behaviors.setup`
- split OfferManager tests - add more tests to the OfferManager - remove test duplication in MultiPartHandlerSpec - refactor BlindedPaymentSpec
|
Thank you for the refactoring. It looks very nice now. |
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.
Because offers are a very generic mechanism, handling them can require interacting with an inventory system (do we actually have the quantity that the payer is requesting) or other such systems which do not have their place inside eclair. For this reason offer handlers must be implemented as plugins that communicate with the offer manager. On startup, the offer handlers must register their offers with the offer manager, the offer manager will then forward the invoice requests and blinded payments to the relevant offer handler for approval.
Because offer invoices can be requested by any node, we do not store them in DB when they are created (which could be a DoS vector) but only when they are paid. To do that, we store some metadata about the invoice (offer id, preimage, payer id, created at, quantity, amount, features and extra data from the offer handler) in the pathId of the blinded route to use for the payment. This data is encrypted and signed by us so that it can't be forged by the payer. By default, this is not enough to fully reconstruct the invoice, so what is eventually stored in the DB once the payment succeeds does not exactly match the invoice that was sent to the payer, if that's a requirement for some use case, all of it can be put in the extra data passed by the offer handler.