Conversation
pm47
commented
Oct 23, 2024
t-bast
reviewed
Oct 24, 2024
Member
t-bast
left a comment
t-bast
left a comment
There was a problem hiding this comment.
Looks good to me, this is a good clean-up! It's simpler than I thought, the hard part is probably the DB part on the Phoenix side?
I don't see any issue on the lightning-kmp side, everything is much clearer now.
t-bast
previously approved these changes
Oct 24, 2024
Member
t-bast
left a comment
t-bast
left a comment
There was a problem hiding this comment.
LGTM as far as backwards-compatibility doesn't create any issue for Phoenix!
pm47
force-pushed
the
model-rework-incoming
branch
from
77db5b6 to
d50f720
Compare
pm47
force-pushed
the
model-rework-incoming
branch
from
5450bb3 to
600c04d
Compare
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`
Instead, the `parts` are a direct member of `LightningIncomingPayment`. It makes the object simpler to manipulate and update. Each of them has a `receivedAt` timestamp, offering more precision.
pm47
force-pushed
the
model-rework-incoming
branch
from
a110612 to
bad4ec3
Compare
This was referenced Dec 17, 2024
t-bast
reviewed
Dec 18, 2024
t-bast
approved these changes
Dec 19, 2024
pm47
added a commit
to ACINQ/phoenixd
that referenced
this pull request
Feb 4, 2025
This is a major rework, downstream of: - ACINQ/lightning-kmp#722 - ACINQ/lightning-kmp#738 - ACINQ/lightning-kmp#739 - ACINQ/lightning-kmp#749 Both the database schema and the serialization method have been completely reworked: - The database schema moves from one table per payment type to one table for all incoming payments and one table for all outgoing payments. We also move from a multi-column model with custom handling of polymorphism to a single column containing the whole serialized data. - The serialization moves from json (with serialization classes managed in phoenixd) to a binary format (managed in lightning-kmp). This removes a lot of boiler plate code, allows for factorization between phoenix/phoenixd and makes updating the model a lot easier. Legacy serialization code has been isolated as much as possible in a `migrations` package. The channels and payments db are now pretty similar.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.