[Part 1|3] Introduce SQL Payment schema into LND #9147

ziggie1984 · 2024-10-01T13:48:17Z

This implements the SQL backend for the payments subsystem of LND.

The following parts will focus on:

Refactoring the attemptID out of the switch package
Migration of old payment data (including duplicate payments which will be separate compared to the kv implementation. This is ok because there shouldn't be many nodes with this old behaviour plus we reduce complexity.
Add performance tests

coderabbitai · 2024-10-01T13:48:26Z

Important

Review skipped

Auto reviews are limited to specific labels.

🏷️ Labels to auto review (1)

llm-review

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>, please review it.
- Generate unit testing code for this file.
- Open a follow-up GitHub issue for this discussion.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
- @coderabbitai generate unit testing code for this file.
- @coderabbitai modularize this function.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @coderabbitai read src/utils.ts and generate unit testing code.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
- @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai full review to do a full review from scratch and review all the files again.
@coderabbitai summary to regenerate the summary of the PR.
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai configuration to show the current CodeRabbit configuration for the repository.
@coderabbitai help to get help.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (`.coderabbit.yaml`)

You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
Please see the configuration documentation for more information.
If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

Visit our Documentation for detailed information on how to use CodeRabbit.
Join our Discord Community to get help, request features, and share feedback.
Follow us on X/Twitter for updates and announcements.

ziggie1984 · 2024-10-01T13:52:11Z

ziggie1984 · 2024-10-01T14:11:04Z

Some questions I already had:

I connected most of the tables via the payment id (primary key) however does it make sense to also include a foreign key which points to the payment hash or even have 2 foreign keys for tables (or is the lookup cost very low so we can go with 1 and from the payment id just get the payment hash from the mpp_payment table.
I removed the need to have a separate table for PaymentCreationInfo but put everything into mpp_payment record this will probably force use to also change the interface of the control_tower for example:

	InitPayment(lntypes.Hash, *channeldb.PaymentCreationInfo) error

I think this is ok and we just include an interface for the channeldb.PaymentCreationInfo type.

Roasbeef · 2024-10-07T15:33:19Z

) however does it make sense to also include a foreign key which points to the payment hash or even have 2 foreign keys for tables (or is the lookup cost very low so we can go with 1 and from the payment id just get the payment hash from the mpp_payment table.

As in a composite foreign key? That should be fine, though if there's a way we can avoid it in practice to simplify queries or instead add a UNIQUE index, then that might be desirable.

Roasbeef · 2024-10-07T15:33:49Z

@ziggie1984 I think the image upload on that last comment failed.

Roasbeef · 2024-10-07T15:36:31Z

I used Claude to create an mermaid diagram of the schema so far (zero shot, and first pass, might have some errors). This is nice, as we can check it into the repo, and the markdown updates will be shown in the git diff:

erDiagram
    mpp_payment ||--o{ first_hop_custom_records : has
    mpp_payment ||--|| payment_status_types : has
    mpp_payment ||--|| mpp_state : has
    mpp_payment ||--o{ htlc_attempt : has
    htlc_attempt ||--o| htlc_settle_info : has
    htlc_attempt ||--o| htlc_fail_info : has
    htlc_fail_info ||--|| htlc_fail_reason_types : has
    htlc_fail_info ||--o| failure_msg_types : has
    htlc_attempt ||--o| route : has
    route ||--o{ hop : contains
    hop ||--o| blinded_data : has
    hop ||--o| mpp_record : has
    hop ||--o| amp_record : has
    hop ||--o{ hop_custom_records : has

    mpp_payment {
        integer id PK
        integer payment_status FK
        blob payment_hash
        bigint amount_msat
        blob payment_request
        timestamp created_at
    }
    first_hop_custom_records {
        bigint key FK
        blob value
        text payment_id
    }
    payment_status_types {
        integer id PK
        text description
    }
    mpp_state {
        integer payment_id FK
        integer num_attempts_in_flight
        bigint remaining_amt
        bigint FeesPaid
        boolean has_settled_htlc
        boolean payment_failed
    }
    htlc_attempt {
        integer id PK,FK
        blob session_key
        timestamp attempt_time
        integer payment_id FK
    }
    htlc_settle_info {
        integer id PK
        integer attempt_id FK
        blob preimage
        timestamp settle_time
    }
    htlc_fail_info {
        integer id PK
        integer attempt_id FK
        integer failure_source_index
        integer htlc_fail_reason FK
        integer failure_msg FK
    }
    htlc_fail_reason_types {
        integer id PK
        text description
    }
    failure_msg_types {
        integer id PK
        text description
        text error_msg
    }
    route {
        integer id PK
        integer htlc_attempt_id FK
        integer total_timeLock
        bigint total_amount
        blob source_key
        bigint first_hop_amount
    }
    hop {
        integer id PK
        integer route_id FK
        blob pub_key
        text chan_id
        integer outgoing_time_lock
        bigint amt_to_forward
        blob meta_data
    }
    blinded_data {
        integer hop_id FK
        blob encrypted_data
        blob blinding_point
        bigint total_amt
    }
    mpp_record {
        integer hop_id FK
        blob payment_addr
        bigint total_msat
    }
    amp_record {
        integer hop_id FK
        blob root_share
        blob set_id
        integer child_index
    }
    hop_custom_records {
        bigint key FK
        blob value
        integer hop_id FK
    }

Roasbeef · 2024-10-07T16:02:12Z

sqldb/sqlc/migrations/000005_payments.up.sql

+    amount_msat BIGINT NOT NULL,
+
+    -- payment_request is the payment request of the payment.
+    payment_request BLOB UNIQUE NOT NULL,


I wonder if we should split this out, as in the future we'll have more than one type of payment request encoding. I think it's also possible to actually have duplicates here: someone pays a zero value invoice multiple times.

might be considered, current version does not separate it out.

sqldb/sqlc/migrations/000005_payments.up.sql

Roasbeef · 2024-10-07T16:05:52Z

sqldb/sqlc/migrations/000005_payments.up.sql

+CREATE TABLE legacy_payments (
+    payment_id INTEGER PRIMARY KEY REFERENCES payments(id) ON DELETE CASCADE,
+
+    payment_hash BLOB UNIQUE NOT NULL


I think there were instances of duplicate payment hashes in the past?

yes this will be handled separately to keep the unique constraint requirement.

yes duplicate payments are handled separately in a followup PR.

sqldb/sqlc/migrations/000005_payments.up.sql

Roasbeef · 2024-10-07T16:10:58Z

sqldb/sqlc/migrations/000005_payments.up.sql

+
+   value BLOB NOT NULL,
+
+   payment_id INTEGER REFERENCES payments(id) ON DELETE CASCADE


Seems we could further denormalize this with another layer of indirection. So we store a table of TLV KV pairs, then an associative table that relates a payment_id to an entry in the TLV KV table.

hmm can be considered current version creates a TLV table for all the related parts separately

Roasbeef · 2024-10-07T16:15:21Z

sqldb/sqlc/migrations/000005_payments.up.sql

+CREATE INDEX IF NOT EXISTS amp_record_set_id_idx ON amp_record(set_id);
+
+CREATE TABLE "hop_custom_records" (
+   key BIGINT NOT NULL,


Yeah so if we go with the suggestion above, then this would become another associative table (dedup the KV pairs, then one table to map a given hop_id to the set of KV pairs).

let's see what the other reviewers think.

Roasbeef · 2024-10-07T16:19:11Z

Updated version:

erDiagram
    payments {
        BIGINT id PK
        INTEGER payment_status FK
        INTEGER payment_type FK
        BIGINT amount_msat
        BLOB payment_request
        TIMESTAMP created_at
    }
    payment_status_types {
        INTEGER id PK
        TEXT description
    }
    payment_types {
        INTEGER id PK
        TEXT description
    }
    legacy_payments {
        INTEGER payment_id PK,FK
        BLOB payment_hash
    }
    mpp_payments {
        INTEGER payment_id PK,FK
        INTEGER mpp_record_id FK
    }
    amp_payments {
        INTEGER payment_id PK,FK
        INTEGER amp_record_id FK
    }
    mpp_state {
        INTEGER payment_id PK,FK
        INTEGER num_attempts_in_flight
        BIGINT remaining_amt
        BIGINT FeesPaid
        BOOLEAN has_settled_htlc
        BOOLEAN payment_failed
    }
    first_hop_custom_records {
        BIGINT key
        BLOB value
        INTEGER payment_id FK
    }
    htlc_attempt {
        INTEGER id PK
        BLOB session_key
        TIMESTAMP attempt_time
        INTEGER payment_id FK
    }
    route {
        INTEGER htlc_attempt_id PK,FK
        INTEGER total_timeLock
        BIGINT total_amount
        BLOB source_key
        BIGINT first_hop_amount
    }
    hop {
        INTEGER id PK
        INTEGER route_id FK
        BLOB pub_key
        TEXT chan_id
        INTEGER outgoing_time_lock
        BIGINT amt_to_forward
        BLOB meta_data
    }
    mpp_record {
        INTEGER hop_id PK,FK
        BLOB payment_addr
        BIGINT total_msat
    }
    amp_record {
        INTEGER hop_id PK,FK
        BLOB root_share
        BLOB set_id
        INTEGER child_index
    }
    hop_custom_records {
        BIGINT key
        BLOB value
        BIGINT hop_id FK
    }
    blinded_data {
        INTEGER hop_id PK,FK
        BLOB encrypted_data
        BLOB blinding_point
        BIGINT total_amt
    }
    htlc_settle_info {
        INTEGER htlc_attempt_id PK,FK
        BLOB preimage
        TIMESTAMP settle_time
    }
    htlc_fail_info {
        INTEGER htlc_attempt_id PK,FK
        INTEGER htlc_fail_reason FK
        TEXT failure_msg
    }
    htlc_fail_reason_types {
        INTEGER id PK
        TEXT description
    }

    payments ||--o{ legacy_payments : has
    payments ||--o{ mpp_payments : has
    payments ||--o{ amp_payments : has
    payments ||--o{ mpp_state : has
    payments ||--o{ first_hop_custom_records : has
    payments ||--o{ htlc_attempt : has
    payments }|--|| payment_status_types : references
    payments }|--|| payment_types : references
    mpp_payments }|--|| mpp_record : references
    amp_payments }|--|| amp_record : references
    htlc_attempt ||--o| route : has
    route ||--o{ hop : contains
    hop ||--o| mpp_record : has
    hop ||--o| amp_record : has
    hop ||--o{ hop_custom_records : has
    hop ||--o| blinded_data : has
    htlc_attempt ||--o| htlc_settle_info : has
    htlc_attempt ||--o| htlc_fail_info : has
    htlc_fail_info }|--|| htlc_fail_reason_types : references

ziggie1984 · 2024-10-08T08:45:44Z

Updated graph:

erDiagram
    payments {
        BIGINT id PK
        INTEGER payment_status FK
        INTEGER payment_type FK
        BIGINT amount_msat
        TIMESTAMP created_at
    }
    payment_requests {
        INTEGER id PK
        INTEGER payment_id FK
        BLOB payment_request
    }
    payment_status_types {
        INTEGER id PK
        TEXT description
    }
    payment_types {
        INTEGER id PK
        TEXT description
    }
    legacy_payments {
        INTEGER payment_id PK,FK
        BLOB payment_hash
    }
    mpp_payments {
        INTEGER payment_id PK,FK
        INTEGER mpp_record_id FK
    }
    amp_payments {
        INTEGER payment_id PK,FK
        INTEGER amp_record_id FK
    }
    payment_state {
        INTEGER payment_id PK,FK
        INTEGER num_attempts_in_flight
        BIGINT remaining_amt
        BIGINT fees_paid
        BOOLEAN has_settled_htlc
        BOOLEAN payment_failed
    }
    htlc_attempt {
        INTEGER id PK
        BLOB session_key
        TIMESTAMP attempt_time
        INTEGER payment_id FK
    }
    route {
        INTEGER htlc_attempt_id PK,FK
        INTEGER total_timeLock
        BIGINT total_amount
        BLOB source_key
        BIGINT first_hop_amount
    }
    hop {
        INTEGER id PK
        INTEGER route_id FK
        BLOB pub_key
        TEXT chan_id
        INTEGER outgoing_time_lock
        BIGINT amt_to_forward
        BLOB meta_data
    }
    mpp_record {
        INTEGER hop_id PK,FK
        BLOB payment_addr
        BIGINT total_msat
    }
    amp_record {
        INTEGER hop_id PK,FK
        BLOB root_share
        BLOB set_id
        INTEGER child_index
    }
    tlv_records {
        INTEGER id PK
        BIGINT key
        BLOB value
    }
    custom_records {
        INTEGER tlv_record_id PK,FK
        INTEGER hop_id FK
    }
    first_hop_custom_records {
        INTEGER tlv_record_id PK,FK
        INTEGER payment_id FK
    }
    blinded_data {
        INTEGER hop_id PK,FK
        BLOB encrypted_data
        BLOB blinding_point
        BIGINT total_amt
    }
    htlc_settle_info {
        INTEGER htlc_attempt_id PK,FK
        BLOB preimage
        TIMESTAMP settle_time
    }
    htlc_fail_info {
        INTEGER htlc_attempt_id PK,FK
        INTEGER htlc_fail_reason FK
        TEXT failure_msg
    }
    htlc_fail_reason_types {
        INTEGER id PK
        TEXT description
    }

    payments ||--o{ payment_requests : has
    payments ||--o| legacy_payments : has
    payments ||--o| mpp_payments : has
    payments ||--o| amp_payments : has
    payments ||--o| payment_state : has
    payments ||--o{ htlc_attempt : has
    payments }o--|| payment_status_types : has
    payments }o--|| payment_types : has
    htlc_attempt ||--o| route : has
    route ||--o{ hop : has
    hop ||--o| mpp_record : has
    hop ||--o| amp_record : has
    hop ||--o{ custom_records : has
    hop ||--o| blinded_data : has
    htlc_attempt ||--o| htlc_settle_info : has
    htlc_attempt ||--o| htlc_fail_info : has
    htlc_fail_info }o--|| htlc_fail_reason_types : has
    mpp_record ||--|| mpp_payments : references
    amp_record ||--|| amp_payments : references
    tlv_records ||--o{ custom_records : has
    tlv_records ||--o{ first_hop_custom_records : has
    payments ||--o{ first_hop_custom_records : has

ziggie1984 · 2024-10-25T13:14:28Z

Currently creating the whole change into the one draft PR and then if it all works together will split all the different parts into separate PRs.

ziggie1984 · 2024-10-25T14:27:17Z

List of ideas to include during refactor (in progress):

garbage collector for failed payments on startup

sqldb/sqlc/migrations/000005_payments.up.sql

ziggie1984 · 2025-04-14T14:15:44Z

fix the nil hash patch properly via SQL: #9703 (comment)

ziggie1984 · 2025-05-20T15:18:01Z

New updated Diagram:
https://dbdiagram.io/d/Payment-Schema-66fbb44df9b1444815012417

docs/sql-schemas/payments_sql_schema.mermaid

ziggie1984 · 2025-09-29T16:19:39Z

I created a refined schema which is more optimzed:

https://dbdiagram.io/d/Payment-Schema-66fbb44df9b1444815012417

ziggie1984 · 2025-09-29T16:22:47Z

ziggie1984 · 2025-09-29T17:09:02Z

OK so I broke the whole PR into pieces and will use a side branch instead to merge those PRs until the whole feature is ready. The tests which use the nativesql-experiment will fail currently because the backend is not implemented yet.

Couple of words regarding the new schema and the design choices:

Differences to the old design:

Removed the Legacy_Payload bit because it is not necessary, will only use the tlv payload and if we still have some old payload which uses the legacy payload format we will deserialize it and move it into the proper table, so there is no need flagging legacy payload.
Moved the payment request into its own table to account for Bolt12 offers which will have a offer instead of and invoice we would initiate the payment to.
Also decouple the resolution from the attempt table to have them properly separated. I decided against splitting the settle and fail information into its own tables because then we would not have an easy way to check for consitency meaning that either the failure reason for this attempt or the settle info is set.
Now a short word to the CustomHop data, we have custom hop data on 3 levels: the payment level (which carries the custom tlv data for the first hop), the attempt/route level tlv custom payload (which is very similar to the payment level tlv custom record payload, but for the custom channels we add additional information via the AuxUnit so we have to persist it as well) and the hop level custom record payload which has the tlv custom record data for all other hops except the first hop. I dedided to keep them separate for now, because having a centralized TLV table and only link tables from the payment,route,hop might save us some data but comes with more complexity.
We separated the MPP, AMP and BLinded information into its own tables, because for the MPP and AMP case it only effects the last hop so we would have a lot of waste stored if we integrated it into the. hops table. For the blinded data I also separated it out, because most payment will not have it. and a small join will not effect much the speed in fetching the blinded data.
Also what is important to note: The extra attemptIndex in the attempts table will be removed later down the road before the feature lands into master, as soon as the circuit map dependency is removed, this will happen after the basic SQL functionality is merged into the side branch. It does not hurt much currently and it is a bit of a refactor to remove the dependency to the switch to that we can just use the primary key of the attempt.

ellemouton

lgtm!

config_builder.go

lightninglabs-deploy · 2025-10-08T15:19:19Z

@yyforyongyu: review reminder
@ziggie1984, remember to re-request review from reviewers when ready

We prepare the code for the sql payment backend. However no payment db interface method for the sql backend is implemented yet. This will be done in the following commits. They currently use the embedded KVStore to satify the build environment.

This does not include duplicate payments yet. They will be added when the migration code is introduced for payments.

We allow the migration of the payment schema to be applied when the test_native_sql is active to make sure the tables are properly contructed.

yyforyongyu

Still doing a final round review, and found this panic from the CI,

2025-10-13 07:07:15.700 [DBG] CRTR router.go:1419: Scanning for inflight payments
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x48 pc=0x1bed372]

goroutine 23608 [running]:
github.com/lightningnetwork/lnd/kvdb.View(...)
	/home/runner/go/pkg/mod/github.com/lightningnetwork/lnd/[email protected]/interface.go:27
github.com/lightningnetwork/lnd/payments/db.(*KVStore).FetchInFlightPayments(0xc0006437c0)
	/home/runner/work/lnd/lnd/payments/db/kv_store.go:750 +0x172
github.com/lightningnetwork/lnd/routing.(*controlTower).FetchInFlightPayments(0x7f51ee812c28?)
	/home/runner/work/lnd/lnd/routing/control_tower.go:287 +0x1b
github.com/lightningnetwork/lnd/routing.(*ChannelRouter).resumePayments(0xc001e7bd70)
	/home/runner/work/lnd/lnd/routing/router.go:1420 +0x66
github.com/lightningnetwork/lnd/routing.(*ChannelRouter).Start(0xc001d69998?)
	/home/runner/work/lnd/lnd/routing/router.go:359 +0x85
github.com/lightningnetwork/lnd.(*server).Start.func1()
	/home/runner/work/lnd/lnd/server.go:2320 +0x1ec5
sync.(*Once).doSlow(0xc000651508?, 0xf?)
	/opt/hostedtoolcache/go/1.24.6/x64/src/sync/once.go:78 +0xab
sync.(*Once).Do(...)
	/opt/hostedtoolcache/go/1.24.6/x64/src/sync/once.go:69
github.com/lightningnetwork/lnd.(*server).Start(0xc000651508, {0x29be1b0, 0xc000123a90})
	/home/runner/work/lnd/lnd/server.go:2170 +0xb6
github.com/lightningnetwork/lnd.Main.func12()
	/home/runner/work/lnd/lnd/lnd.go:761 +0x28
created by github.com/lightningnetwork/lnd.Main in goroutine 1
	/home/runner/work/lnd/lnd/lnd.go:760 +0x4a25

ziggie1984 · 2025-10-13T11:27:07Z

2025-10-13 07:07:15.700 [DBG] CRTR router.go:1419: Scanning for inflight payments
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x48 pc=0x1bed372]

yes that's expected, we embed the kvstore for the sqlstore for now so that we can compile it, but for the sql tests they will fail because I never initialize this value because it would not work anyways if we partly implement each function because then parts will live in the kvstore and parts in the sql store, thats why for now these itests will fail for the test_native_sql run.

yyforyongyu

saubyk assigned ziggie1984 Oct 3, 2024

saubyk added sql payments Related to invoices/payments database Related to the database/storage of LND backend Related to the node backend software/interface (e.g. btcd, bitcoin-core) labels Oct 3, 2024

saubyk added this to the v0.19.0 milestone Oct 3, 2024

Roasbeef requested changes Oct 7, 2024

View reviewed changes

ziggie1984 force-pushed the introduce-sql-schema-payments branch 2 times, most recently from 616b851 to 9817290 Compare October 8, 2024 09:01

saubyk modified the milestones: v0.19.0, 0.20.0 Dec 5, 2024

feelancer21 reviewed Feb 27, 2025

View reviewed changes

sqldb/sqlc/migrations/000005_payments.up.sql Outdated Show resolved Hide resolved

saubyk added this to lnd v0.20 Mar 27, 2025

saubyk moved this to In progress in lnd v0.20 Mar 27, 2025

This was referenced Apr 17, 2025

[bug]: very slow to locate in flight HTLC on startup and poor logging messages informing what is going on #9729

Open

[bug]: listpayments hangs node and eats RAM when lots of payments in the DB #9709

Open

Roasbeef reviewed May 20, 2025

View reviewed changes

docs/sql-schemas/payments_sql_schema.mermaid Outdated Show resolved Hide resolved

ziggie1984 mentioned this pull request May 25, 2025

[feature]: Introduce Payment SQL storage #9863

Open

8 tasks

saubyk moved this to In review in v0.21 Sep 24, 2025

ziggie1984 changed the base branch from master to elle-payment-sql-series September 29, 2025 16:40

ziggie1984 force-pushed the introduce-sql-schema-payments branch from 7bf09e0 to e9d0a4f Compare September 29, 2025 16:47

ziggie1984 changed the base branch from elle-payment-sql-series to elle-payment-sql-series-new September 29, 2025 16:50

ziggie1984 force-pushed the introduce-sql-schema-payments branch from e9d0a4f to 3d9090b Compare September 29, 2025 16:51

ziggie1984 requested review from ellemouton and yyforyongyu September 29, 2025 16:57

ziggie1984 force-pushed the introduce-sql-schema-payments branch from 3d9090b to 7e3b327 Compare September 30, 2025 06:59

ziggie1984 mentioned this pull request Sep 30, 2025

Make verifyAttempt more robust #10257

Merged

ziggie1984 force-pushed the introduce-sql-schema-payments branch from 7e3b327 to ca3b10b Compare September 30, 2025 19:05

ellemouton approved these changes Oct 1, 2025

View reviewed changes

config_builder.go Outdated Show resolved Hide resolved

ziggie1984 force-pushed the introduce-sql-schema-payments branch from ca3b10b to af52e5d Compare October 8, 2025 17:37

ziggie1984 force-pushed the introduce-sql-schema-payments branch 2 times, most recently from 28f9815 to 752af81 Compare October 12, 2025 12:26

ziggie1984 added 3 commits October 12, 2025 19:16

sqldb: add payment sql tables

07c350d

This does not include duplicate payments yet. They will be added when the migration code is introduced for payments.

lnd: make the payment schema migration available for testing

8e9f457

We allow the migration of the payment schema to be applied when the test_native_sql is active to make sure the tables are properly contructed.

docs: add release-notes

75b3a35

ziggie1984 mentioned this pull request Oct 12, 2025

[Part 2|*] Implement First Part for SQL Backend functions #10287

Merged

ziggie1984 force-pushed the introduce-sql-schema-payments branch from 752af81 to 75b3a35 Compare October 13, 2025 06:30

yyforyongyu reviewed Oct 13, 2025

View reviewed changes

yyforyongyu approved these changes Oct 13, 2025

View reviewed changes

yyforyongyu merged commit a0044ba into lightningnetwork:elle-payment-sql-series-new Oct 13, 2025
37 of 39 checks passed

github-project-automation bot moved this from In review to Done in v0.21 Oct 13, 2025

ziggie1984 deleted the introduce-sql-schema-payments branch October 17, 2025 09:23


		value BLOB NOT NULL,

		payment_id INTEGER REFERENCES payments(id) ON DELETE CASCADE

[Part 1|3] Introduce SQL Payment schema into LND #9147

[Part 1|3] Introduce SQL Payment schema into LND #9147

Uh oh!

Conversation

ziggie1984 commented Oct 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

coderabbitai bot commented Oct 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Chat

CodeRabbit Commands (Invoked using PR comments)

Other keywords and placeholders

CodeRabbit Configuration File (.coderabbit.yaml)

Documentation and Community

Uh oh!

ziggie1984 commented Oct 1, 2024

Uh oh!

ziggie1984 commented Oct 1, 2024

Uh oh!

Roasbeef commented Oct 7, 2024

Uh oh!

Roasbeef commented Oct 7, 2024

Uh oh!

Roasbeef commented Oct 7, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Roasbeef commented Oct 7, 2024

Uh oh!

ziggie1984 commented Oct 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ziggie1984 commented Oct 25, 2024

Uh oh!

ziggie1984 commented Oct 25, 2024

Uh oh!

Uh oh!

ziggie1984 commented Apr 14, 2025

Uh oh!

ziggie1984 commented May 20, 2025

Uh oh!

Uh oh!

ziggie1984 commented Sep 29, 2025

Uh oh!

ziggie1984 commented Sep 29, 2025

Uh oh!

ziggie1984 commented Sep 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ellemouton left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

lightninglabs-deploy commented Oct 8, 2025

Uh oh!

yyforyongyu left a comment

Choose a reason for hiding this comment

ziggie1984 commented Oct 1, 2024 •

edited

Loading

coderabbitai bot commented Oct 1, 2024 •

edited

Loading

CodeRabbit Configuration File (`.coderabbit.yaml`)

Roasbeef commented Oct 7, 2024 •

edited

Loading

ziggie1984 commented Oct 8, 2024 •

edited

Loading

ziggie1984 commented Sep 29, 2025 •

edited

Loading