[WIP] Payjoin receiver by benalleng · Pull Request #2011 · wizardsardine/liana

benalleng · 2026-02-10T15:05:48Z

This adds support for payjoin receive in liana.

This is currently WIP and has the following TODOs

Move bip21 to be created at runtime instead of at the time of receiver creation in lianad allowing us to not need to store bip21
Ensure that the expiry is properly handled as it currently panics when an incomplete session expires

xstoicunicornx

I know this is still a WIP and my comments may be a bit premature but just wanted to brain dump some of the notes I took as part of the BOSS Payjoin Showcase session.

Some additional general comments:

should amount be added to URI?
should adjusting expiration will be added to settings?
when I ran this PR Liana panicked with this error when I tried to send a payjoin to the receiver:2026-04-09T16:19:40.194941Z ERROR liana_gui:82: panic occurred at line 508 of file lianad/src/database/sqlite/mod.rs: Some("database must be available: SqliteFailure(Error { code: Unknown, extended_code: 1 }, Some(\"table payjoin_outpoints has no column named added_at\"))") 0: backtrace::backtrace::libunwind::trace
in the GUI when payjoin is listed under previously generated addresses it shows the address rather than URI (I'm guessing this is related to this comment)

xstoicunicornx · 2026-04-09T16:48:23Z

+/* Payjoin OHttpKeys */
+CREATE TABLE payjoin_ohttp_keys (
+    id INTEGER PRIMARY KEY NOT NULL,
+    relay_url TEXT UNIQUE NOT NULL,


Should this be the payjoin directory url instead? Aren't OHttpKeys specific to a payjoin directory, not relay?

If sopayjoin_save_ohttp_keys and payjoin_get_ohttp_keys also would need to be updated.

Bumping this, aren't the ohttp keys specific to the payjoin directory?

xstoicunicornx · 2026-04-09T16:59:29Z

+    }
+}
+
+pub(crate) fn fetch_ohttp_keys(


Is it possible to reuse PDK's implementation of fetch_ohttp_keys?

Yes, but the current PDK impl is async so we would need to add some blocking capability and without it the async stuff would cascade. So i think its best to keep it manually re-implemented. though It might be nice to add sync versions for situations like this

xstoicunicornx · 2026-04-09T17:00:31Z

+    db_conn: &mut Box<dyn DatabaseConnection>,
+    secp: &secp256k1::Secp256k1<secp256k1::VerifyOnly>,
+) -> Result<(), Box<dyn Error>> {
+    let proposal = proposal.apply_fee_range(None, None).save(persister)?;


No fee range actually being applied.

benalleng · 2026-04-09T19:31:43Z

Thanks for the feedback,

Regarding the UI notes.

should amount be added to URI?

Since it is not a mandatory addition in the payjoin spec I thought that for a desktop on-chain only wallet the UX of adding an amount on the receive side is sort of unfamiliar, especially given the current liana receiver UI

should adjusting expiration will be added to settings?

I think again perhaps this is worth some user research but with the ability to do a fallback tx at any point I am not sure that extending the expiration as an option is great to put in the user's direct control

in the GUI when payjoin is listed under previously generated addresses it shows the address rather than URI (I'm guessing this is related to this comment)

This was something we landed on due wanting to discourage reuse of payjoin sessions. I could share this bip21 with as many people as I want similar to address reuse but instead of just bad privacy you would get a bunch of payjoin failures

The method again is a holdout as the last time I gave this some serious focus I transitioned from storing the bip21 to the session ID directly and I previously wanted to have access to the bip21 in the db where I just generate it in the gui now and don't store it directly

benalleng · 2026-04-09T19:33:12Z

when I ran this PR Liana panicked with this error when I tried to send a payjoin to the receiver:2026-04-09T16:19:40.194941Z ERROR liana_gui:82: panic occurred at line 508 of file lianad/src/database/sqlite/mod.rs: Some("database must be available: SqliteFailure(Error { code: Unknown, extended_code: 1 }, Some("table payjoin_outpoints has no column named added_at"))") 0: backtrace::backtrace::libunwind::trace

This is definitely an artifact of me playing in the database between naming the timestamp added_at vs created_at https://github.com/wizardsardine/liana/pull/2011/changes#diff-4f33457fe83ad075401f91984457b7503d757068fcb26def0e090c584fd8439dR1146

yashrajd · 2026-04-10T19:48:55Z

should amount be added to URI?

Since it is not a mandatory addition in the payjoin spec I thought that for a desktop on-chain only wallet the UX of adding an amount on the receive side is sort of unfamiliar, especially given the current liana receiver UI

Familiarity might not be an issue IMO, since Liana users presumably also use other (esp mobile) wallets that have this. IMO it's more about the use case or user type: how often do they want to receive an specific exact amount? That said, this seems like a reasonable starting point.

should adjusting expiration will be added to settings?

I think again perhaps this is worth some user research but with the ability to do a fallback tx at any point I am not sure that extending the expiration as an option is great to put in the user's direct control

My hunch is, Liana users are likely to be sophisticated enough to use such a feature properly. Perhaps there could be appropriate messaging/guidance about using the feature.
From user research side, I'd say we have zero/little data to go on with, but you can always survey users to know their preferences (albeit with the "faster horse-carriages" caveat) (again without existing user base it is hard to rely on stated user preferences).

xstoicunicornx

I didn't re-review the code yet, just tried to complete receiving a payjoin and was still not completing successfully. See details below.

xstoicunicornx · 2026-04-19T05:27:10Z

+    let txid = psbt.unsigned_tx.compute_txid();
+    if let Some(psbt) = db_conn.spend_tx(&txid) {
+        let mut is_signed = false;
+        for psbtin in &psbt.inputs {
+            if !psbtin.partial_sigs.is_empty() {
+                log::debug!("[Payjoin] PSBT is signed!");
+                is_signed = true;
+                break;
+            }
+        }
+
+        if is_signed {
+            let proposal = proposal
+                .finalize_proposal(|_| {
+                    let mut psbt = psbt.clone();
+                    finalize_psbt(&mut psbt, secp);
+                    Ok(psbt)
+                })
+                .save(persister)?;
+
+            send_payjoin_proposal(proposal, persister)?;
+        }


I couldn't quite figure out what the intention was here with is_signed, however during my testing is_signed never gets set to true and the proposal never gets finalized. Can you explain what validation is being done here?

~~Also, when I replaced |_| with |psbt| in the finalize_psbt closure it was still possible to clone as mut, whats the rationale for calling psbt_to_sign outside of this closure?~~

Something else that may be related is that currently psbt_to_sign doesn't return a psbt with sender sigs removed, this is something I am fixing in payjoin/rust-payjoin#1446. Let me know if it would good for me to create a separate smaller PR for this just to get this fixed sooner.

I did also try hardcoding is_signed to true so the receiver does send out a psbt proposal, but its then erroring on the sender side during validation. So the finalize_psbt isn't quite working right, but that may be because the psbt thats being finalized has the leftover sender sigs still.

Apologies this was due to my incomplete understanding of the PSBT signing workflow

pythcoiner · 2026-06-09T07:29:45Z

in GUI settings, it should have validation on url, at least a ping:

benalleng · 2026-06-19T20:40:37Z

I need to address the payjoin tx identification being locked behind the feature gate, this is not really payjoin related logic so should not really be behind a cfg flag

Instead of relying on the DB for this critical method in the state machine we should instead create a map up to a set amount to better ensure that there is correct validation on owned inputs for the receiver.

bc1cindy · 2026-07-07T17:03:58Z

                .update_change_psbt_out(&mut psbt_out);
        }

        // TODO: shuffle once we have Taproot


this TODO ties output shuffle to Taproot, but the two are independent: shuffling output position is a pure reorder, no Taproot needed, shippable now. Taproot only helps change script-type indistinguishability, a separate fingerprint.

suggest shuffling

ref: payjoin comment

ping @darosior , I guess it was a real reason even it it's not obvious now

I guess if we add shuffling we should have a way to opt out, as I think our integrations tests rely on ordering for many cases, and imo it's good to keep this logic deterministicaly testable.

bc1cindy · 2026-07-08T16:22:55Z

+) -> Result<(), Box<dyn Error>> {
+    let coins = db_conn.coins(&[CoinStatus::Confirmed], &[]);
+
+    let mut candidate_inputs_map = HashMap::<OutPoint, (Coin, TxIn, Input, Weight)>::new();


makes sense to use BTreeMap here so the contributed input is deterministic, aligning with payjoin/rust-payjoin#1597 (comment) ?

can you open a separate issue for this?

done! #2191

benalleng mentioned this pull request Feb 10, 2026

Add bip21 receive display support #1922

Closed

benalleng force-pushed the payjoin-receiver branch 4 times, most recently from 6c93104 to 943eb03 Compare February 20, 2026 19:58

benalleng mentioned this pull request Feb 23, 2026

Standup Input: Week of 2026-02-23 payjoin/rust-payjoin#1352

Closed

DanGould mentioned this pull request Feb 25, 2026

Liana x Payjoin Tracking Issue payjoin/rust-payjoin#1204

Open

5 tasks

arminsabouri reviewed Mar 3, 2026

View reviewed changes

Comment thread lianad/src/database/sqlite/schema.rs Outdated

Comment thread lianad/src/database/sqlite/schema.rs Outdated

Comment thread lianad/src/database/sqlite/schema.rs Outdated

Comment thread lianad/src/database/sqlite/utils.rs Outdated

benalleng force-pushed the payjoin-receiver branch from f24e841 to 00c9c51 Compare March 4, 2026 20:24

benalleng mentioned this pull request Mar 9, 2026

Standup Input: Week of 2026-03-09 payjoin/rust-payjoin#1396

Closed

benalleng force-pushed the payjoin-receiver branch 4 times, most recently from b6b17ff to f53d60a Compare March 10, 2026 13:49

benalleng marked this pull request as ready for review March 12, 2026 18:06

DanGould mentioned this pull request Mar 16, 2026

Standup Input: Week of 2026-03-16 payjoin/rust-payjoin#1417

Closed

benalleng force-pushed the payjoin-receiver branch 5 times, most recently from d0f60d0 to da7ff64 Compare March 18, 2026 20:06

xstoicunicornx reviewed Apr 9, 2026

View reviewed changes

benalleng force-pushed the payjoin-receiver branch 2 times, most recently from aac7f6e to 06623c7 Compare April 16, 2026 13:52

benalleng requested a review from xstoicunicornx April 16, 2026 16:27

benalleng mentioned this pull request Apr 16, 2026

Should we expose a sync version of fetch_ohttp_keys? payjoin/rust-payjoin#1489

Open

xstoicunicornx reviewed Apr 19, 2026

View reviewed changes

pythcoiner reviewed Jun 9, 2026

View reviewed changes

Comment thread lianad/src/payjoin/helpers.rs Outdated

pythcoiner reviewed Jun 9, 2026

View reviewed changes

Comment thread lianad/src/payjoin/receiver.rs Outdated

pythcoiner reviewed Jun 9, 2026

View reviewed changes

Comment thread lianad/src/payjoin/receiver.rs Outdated

benalleng force-pushed the payjoin-receiver branch from 3c14fca to 075355f Compare June 10, 2026 18:25

benalleng force-pushed the payjoin-receiver branch 9 times, most recently from a010c72 to cd348bf Compare June 19, 2026 19:15

Add payjoin dependency, feature flags, and reqwest setup

ec0b02e

benalleng force-pushed the payjoin-receiver branch 4 times, most recently from ad2a6ab to 6cb8dcf Compare June 19, 2026 20:35

benalleng added 5 commits June 19, 2026 16:50

Add payjoin support within lianad

fcaf0f5

Create address map for check_inputs_not_owned

767c234

Instead of relying on the DB for this critical method in the state machine we should instead create a map up to a set amount to better ensure that there is correct validation on owned inputs for the receiver.

Add payjoin styles in liana-ui

f303013

Add payjoin support in liana-gui

abd0c29

Add payjoin integration tests

9be334c

benalleng force-pushed the payjoin-receiver branch from 6cb8dcf to 9be334c Compare June 19, 2026 20:51

bc1cindy reviewed Jul 7, 2026

View reviewed changes

bc1cindy reviewed Jul 8, 2026

View reviewed changes

This was referenced Jul 8, 2026

Tracking: chain-observable transaction-level fingerprinting payjoin/rust-payjoin#1597

Open

Non-deterministic coin selection #2191

Open

Uh oh!

Conversation

benalleng commented Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

xstoicunicornx left a comment

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!

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!

benalleng commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

benalleng commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yashrajd commented Apr 10, 2026

Uh oh!

xstoicunicornx left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xstoicunicornx Apr 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pythcoiner commented Jun 9, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

benalleng commented Jun 19, 2026

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

benalleng commented Feb 10, 2026 •

edited

Loading

benalleng commented Apr 9, 2026 •

edited

Loading

benalleng commented Apr 9, 2026 •

edited

Loading

xstoicunicornx left a comment •

edited

Loading

xstoicunicornx Apr 19, 2026 •

edited

Loading