Rework IncomingPayment model
#722
Draft
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
This allows for a unified identifier for all payments that affect the balance. For `IncomingPayment`, the `payment_hash` is currently abusively used as a primary key, which is hacky in the context of swap-ins. To minimize integration effort, the payment id simply derived from that existing key, with no other changes.
We move from a flat model with a single `IncomingPayment` class and a
combination of `Origin` + `ReceivedWith` parts to a hierarchical model.
This new model:
- makes incoming/outgoing databases symmetrical
- removes impossible combinations allowed in the previous model (e.g. an
on-chain origin with a fee-credit part)
- removes hacks required for the handling of on-chain deposits, which
were shoe-horned in what was originally a lightning-only model
Before:
```
Origin
|
`--- Invoice
|
`--- Offer
|
`--- SwapIn
|
`--- OnChain
ReceivedWith
|
`--- LightningPayment
|
`--- AddedToFeeCredit
|
`--- OnChainIncomingPayment
|
`--- NewChannel
|
`--- SpliceIn
```
After:
```
IncomingPayment
|
`--- LightningIncomingPayment
| |
| `--- Bolt11IncomingPayment
| |
| `--- Bolt12IncomingPayment
|
`--- OnChainIncomingPayment
|
`--- NewChannelIncomingPayment
|
`--- SpliceInIncomingPayment
|
`--- LegacySwapInIncomingPayment
|
`--- LegacyPayToOpenIncomingPayment
LightningIncomingPayment.Part
|
`--- LightningPayment
|
`--- AddedToFeeCredit
```
The handling of backward compatible data is tricky, especially for
legacy pay-to-open/pay-to-splice, which can be a mix of lightning parts
and on-chain parts, and either Bolt11 or Bolt12. Note that `Legacy*`
classes are not used at all within `lightning-kmp`, they are just meant
to handle pre-existing data in the database.
(Simple rename, no functional changes) Also: - `ReceivedWith.LightningPayment` -> `Part.Htlc` - `ReceivedWith.AddedToFeeCredit` -> `Part.FeeCredit`
pm47
commented
Oct 23, 2024
src/commonMain/kotlin/fr/acinq/lightning/payment/IncomingPaymentHandler.kt
Show resolved
Hide resolved
t-bast
reviewed
Oct 24, 2024
| @@ -139,7 +139,7 @@ data class SendOnTheFlyFundingMessage(val message: OnTheFlyFundingMessage) : Pee | |||
| sealed class PeerEvent | |||
|
|
|||
| @Deprecated("Replaced by NodeEvents", replaceWith = ReplaceWith("PaymentEvents.PaymentReceived", "fr.acinq.lightning.PaymentEvents")) | |||
| data class PaymentReceived(val incomingPayment: IncomingPayment, val received: IncomingPayment.Received) : PeerEvent() | |||
| data class PaymentReceived(val incomingPayment: LightningIncomingPayment, val received: LightningIncomingPayment.Received) : PeerEvent() | |||
There was a problem hiding this comment.
Can we remove this one entirely? It has been deprecated for a while.
src/commonTest/kotlin/fr/acinq/lightning/payment/IncomingPaymentHandlerTestsCommon.kt
Outdated
Show resolved
Hide resolved
t-bast
previously approved these changes
Oct 24, 2024
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.
We move from a flat model with a single
IncomingPaymentclass and a combination ofOrigin+ReceivedWithparts to a hierarchical model.This new model:
Before:
After:
The handling of backward compatible data is tricky, especially for legacy pay-to-open/pay-to-splice, which can be a mix of lightning parts and on-chain parts, and either Bolt11 or Bolt12. Note that
Legacy*classes are not used at all withinlightning-kmp, they are just meant to handle pre-existing data in the database.