Liana x Payjoin Integration — Dev Update Call Notes

[arminsabouri]

This discussion consists of notes taken during the Liana Payjoin integration dev update calls.

[arminsabouri]

Thursday, May 15, 2025

Working POC Branch:
arturgontijo/liana#1

We currently have a working version where two Liana wallets can send multiple Payjoin transactions back and forth. This proof-of-concept branch acts as a fast-paced sketching environment for experimental and breaking changes. The goal is to break off smaller, reviewable chunks and open pull requests against Liana’s master branch.

Major blocker:
We’re running into issues with the finalize_proposal flow in lianad. Ideally, this logic should run inside the GUI, but to not block any of the GUI threads, the current architecture puts the resposibility of reading the proposal from the dir inside the daemon. The GUI needs BIP32 paths on the PSBT inputs at signing time, but lianad currently reads from the dir, persists the receiver, and pushes it through the state machine adding inputs in the process. After that, lianad reinserts the BIP32 paths so the GUI can re-process the state machine, skipping all states except finalize. Then, the GUI updates the receiver session, and lianad posts the finalized PSBT to the directory.

This flow is hacky! we’re essentially re-processing the same state machine three different times, each time skipping certain states. What we really want is the ability to drive the state machine up to a certain point in one part of the application (where the wallet context and bitcoind rpc interface exists), then continue processing it elsewhere (where we have access to keys!). The session event log would make this much more manageable.

There are still parts of the receiver state machine that need to be properly implemented, like skipping check_broadcast_suitability, but those aren’t blockers -- just work we haven’t finished yet. One remaining task is to expose testmempoolaccept via lianad using its bitcoind RPC wrapper. Again, not a blocker.

The 0.23 persister doesn’t allow us to persist metadata alongside the receiver in its initial state -- similar to the issue in the Boltz integration. Instead of trying to work around this, we are using the no-op persister and shifting to the session event log model as early as possible during development.

Open question:

• How can we finalize a single input in a PSBT that includes external (foreign) inputs? Other wallets we’re familiar with allow this more flexibly (bitcoin core , BDK). However rust-miniscript does not like foreign inputs during finalize() where it created witness for each input.

Action Items:

• Research how to finalize a partially signed PSBT with foreign inputs
  • Rust Miniscript doesn’t seem to support this directly -- we may need to hack around finalize_single_input, which might be acceptable if not other solution exsists.
• Complete receiver state machine processing with all required checks
• If we are blocked on lianad changes, start upstreaming commits from Artur’s rust-payjoin branch
• remove expects() and unwraps() and replace with proper error handling

[DanGould]

Ideally, this logic should run inside the GUI

Why is this ideal? I would assume GUI should handle presentation only and business logic should happen in the daemon.

• Research how to finalize a partially signed PSBT with foreign inputs
  • Rust Miniscript doesn’t seem to support this directly -- we may need to hack around finalize_single_input, which might be acceptable if not other solution exsists.

A solution exists in bdk_wallet, of course, since it supports this. Can that code be used?

[arminsabouri]

Why is this ideal? I would assume GUI should handle presentation only and business logic should happen in the daemon.

The backend does not have access to keys! Hot wallet and/or the interface to hardware wallets are only accessible via the GUI.
@arturgontijo correct me if I am wrong

[arminsabouri]

Wednesday, May 28 2025

Current Status

SEL is proving to be useful for saving and resuming the receiver state machine (see last update). Integration with the new SessionPersister trait is complete. Currently, all events are saved in a single table, but we should migrate to using separate tables for each event type, linked via foreign keys.

Built an ergonomic interface for accessing and updating application-specific session metadata. However, some metadata like the BIP21 URI and original PSBT should instead be reconstructed from session history rather than redundantly stored.

We’re still re-inserting BIP32 paths into the PSBT in Lianad. This step should be removed entirely, as we can now persist the session after contributing inputs and resume it in the GUI to call finalize_proposal.

TODO

• Complete the remaining receiver state machine closures.

• Remove BIP32 path reinsertion in Lianad. Persist the session state up to finalize_proposal, save the PSBT to the Psbt table, replay SEL, and sign.

• Move the finalize_proposal flow into the GUI. Persist the event, and have the Lianad looper extract and post the request.

• Address sign_p2wsh failures by filtering out inputs not owned by the signer. Use the presence of BIP32 derivation paths as a filter before signing.

• Expose additional fields from the session history object:

  • Original PSBT
  • Proposed PSBT

Current Blocker

We're stuck in the sender state machine when reading from the directory (V2GetContext). POST requests are timing out. This likely isn’t a networking issue, since both sender and receiver are able to communicate with the directory via the same OHTTP relay. Instead the issue is likely related to using the wrong dir url or ohttp keys.

[arminsabouri]

Why the v2::Sender GET request was timing out:
In rust-payjoin we were not saving the reply key as part of any session event. When we replay, session context would have e (the reply key) is set to None. If the reply key is None when the receiver extracts the finalized Pj request then we fallback to a v1 payload and "PUT". The sender was not expecting this behavior and timed out instead of falling back to v1.

CC'ing people I mentioned this problem to
cc @nothingmuch @DanGould

[arminsabouri]

Thur June 5 2025

What was done

• Resolved sender hanging issue:
  The sender was not saving the session context in the session event log. As a result, the receiver sent a v1 fallback payload that the sender did not expect.

• Witness UTXO workaround:
  When finalizing the PSBT as the receiver, we call miniscript::finalize_inp_mut. This method fails if not all inputs have a witness_utxo. For inputs we do not own, we fill the witness_utxo field with dummy data. This approach is a hack but acceptable under the circumstances. If we find this hack unacceptable, we can always retrieve witness_utxo from bitcoin core rpc.

• Implemented test mempool accept and broadcast suitability check:
  Added a new RPC method to the bespoke RPC interface.

• Rebased sketch branch with Liana master.

• Integrated OHTTP keys into the database:
  OHTTP keys will rotate eventually. Currently, they expire after seven days. Updated internals to allow users to change OHTTP relays and revoke saved OHTTP keys.

• e2e Payjoins are working reliably against two Liana wallets and the reference payjoin-cli implementation

Action Items

• (When idle) Develop a new settings GUI to configure the BIP77 directory URL and OHTTP relay.
• Continue laying the groundwork for Payjoin integration:
  • Submit a smaller PRs to remove restrictions on foreign inputs against Liana Master.
  • Upstream a change to rust-payjoin to calculate weight for p2wsh inputs Input weight prediction for P2WSH inputs #659

Open Questions

• How should we represent payjoin transactions in the current PSBTs view?

• We don't have to have a strong answer now. This is something we can hold off on until the core implementation is finished.

Blockers

• Current Liana implementation is being built against the SEL sketch branch. This integration now depends strongly on the rust-payjoin 0.24 release.
• Fixing Input weight prediction for P2WSH inputs #659

cc @arturgontijo

[arturgontijo]

Artur's Update on Liana Integration (July 2nd)

PDK:

As of today the PDK master (commit c3f1ce2) does not support P2WSH as an InputPair even having the method new_p2wsh() core/receive/mod.rs#L175.

If a user contribute that kind of InputPair (as Receiver) PDK will reject it whith InputWeightError::NotSupported error (core/psbt/mod.rs#L209) at InternalInputPair::expected_input_weight().

That also happens when starting the workflow as a Sender via SenderBuilder::build_recommended().

Here is a simple diagram of important pipelines that end up calling expected_input_weight() (Receiver = green, Sender = yellow):

There is an open PR that tries to fix that (for Receiver) but it seems that it is not a simple change as the PR touches an important part of the PDK core codebase. Add expected_weight field to InputPair #772

Even with that PR merged we will still need to change the Sender pipeline to allow P2WSH too.

Liana:

Assuming PDK allows P2WSH, here are some important points for Liana codebase:

1 - We need to get the weights of the given PSBT's inputs (as Sender and Receiver) so we need access to the descriptors::LianaDescriptor so we can call desc.max_sat_weight(use_primary_path) to pass the weight to PDK.

2 - Liana does signing on its GUI so we need to "stop" the PDK workflow, give the PSBT to the GUI so it can sign it and the "resume" the PDK sessioin using the signed PSBT.
Using the current Session Event Log that "stop-resume" logic can be easily achieved but we still have, as the final step of the Receiver pipeline, the call to finalize_proposal().
Here is its current code core/receive/v1/mod.rs#L747:

    pub fn finalize_proposal(
        mut self,
        wallet_process_psbt: impl Fn(&Psbt) -> Result<Psbt, ImplementationError>,
        min_fee_rate: Option<FeeRate>,
        max_effective_fee_rate: Option<FeeRate>,
    ) -> Result<PayjoinProposal, ReplyableError> {
        // Note(arturgontijo): PSBT with final fee
        let mut psbt = self.apply_fee(min_fee_rate, max_effective_fee_rate)?.clone();
        // Remove now-invalid sender signatures before applying the receiver signatures
        for i in self.sender_input_indexes() {
            log::trace!("Clearing sender input {i}");
            psbt.inputs[i].final_script_sig = None;
            psbt.inputs[i].final_script_witness = None;
            psbt.inputs[i].tap_key_sig = None;
        }
        let psbt = wallet_process_psbt(&psbt).map_err(ReplyableError::Implementation)?;
        let payjoin_proposal = self.prepare_psbt(psbt);
        Ok(payjoin_proposal)
    }

As the code is now is not possible to "inject" an external (signed by Liana's GUI) PSBT to that function, even if we try something like:

// Example
let signed_and_finalized_by_gui_psbt = liana_gui::finalize_psbt(&mut psbt, secp);

let proposal = proposal
    .finalize_proposal(
        |_| Ok(signed_and_finalized_by_gui_psbt.clone()),
        None,
        Some(FeeRate::from_sat_per_vb(5).unwrap()),
    )
    .save(persister)?;

That code works as I'm using it in the current PoC but the issue is that we are not giving the "PSBT with fee" to Liana's GUI here, we are using a previous version of that PSBT (without proper fee calculation) and then forcing PDK to use it, ignoring the right PSBT.

I've tried to use this current logic (using wallet_process_psbt) in Liana but wasn't able to use its GUI workflows inside that function parameter.

I'd recommend split this workflow into 2, so users can extract the PSBT with fees, sign/finalize it and send it back to PDK.

3 - At DaemonControl::broadcast_spend() (lianad/src/commands/mod.rs#L896) they call finalize_mut() on the whole PSBT (signed_psbt) and that breaks because PDK cleans up some fields that must be present during the finalization with (assuming input at index 1 is not ours):

PSBT is missing witness script at index 1

A workaround would be using something like:

for index in 0..spend_psbt.inputs.len() {
    match spend_psbt.finalize_inp_mut(&self.secp, index) {
        Ok(_) => log::info!("Finalizing input at: {}", index),
        Err(e) => log::warn!("Not finalizing input at: {} | {}", index, e),
    }
}

4 - Throwing LianaDescError::InconsistentPsbt at LianaDescriptor::partial_spend_info() (liana/src/descriptors/mod.rs#L481).
This method calls LianaDescError::partial_spend_info_txin() that does what it describes ((liana/src/descriptors/mod.rs#L378-L382)[https://github.com/wizardsardine/liana/blob/master/liana/src/descriptors/mod.rs#L378-L382]):

    /// Get some information about a PSBT input spending Liana coins.
    /// This analysis assumes that:
    /// - The PSBT input actually spend a Liana coin for this descriptor. Otherwise the analysis will be off.
    /// - The signatures contained in the PSBT input are valid for this script.
    pub fn partial_spend_info_txin( ... )

That method does not allow not owned "coins" (external inputs).

[DanGould]

Even with that PR merged we will still need to change the Sender pipeline to allow P2WSH too.

Yes, IMO they should be changed at the same time. Should we not change the Sender to estimate weights using script spend in P2wsh? Is the PR useful otherwise?

2 - Liana does signing on its GUI so we need to "stop" the PDK workflow, give the PSBT to the GUI so it can sign it and the
...
is not possible to "inject" an external (signed by Liana's GUI) PSBT to that function

Do you know what the fundamental constraint is? Why is it not possible for liana_gui::finalize_psbt to be called in the .finalize_proposal function as a closure? Is it possible to do so with an additional thread or mpsc channels? or with tokio tasks? If we know the fundamental constraint we can design a solution around this. I think we ran into this problem all the way back at the hackathon.

Were there any attempts already that we know do not work because of some constraints? If so, what were they?

That code works as I'm using it in the current PoC but the issue is that we are not giving the "PSBT with fee" to Liana's GUI here, we are using a previous version of that PSBT (without proper fee calculation) and then forcing PDK to use it, ignoring the right PSBT.

Could this not be changed to :

fn call_to_liana_gui_(psbt: &mut Psbt) {
     let secp = Secp256k1::new();
     liana_gui::finalize_psbt(&mut psbt, secp)
}

let proposal = proposal
     .finalize_proposal(
         |psbt| call_to_liana_gui(psbt),
        None,
        Some(FeeRate::from_sat_per_vb(5).unwrap()),
     )
     .save(persister)?;

And if not, by what constraint?

I've tried to use this current logic (using wallet_process_psbt) in Liana but wasn't able to use its GUI workflows inside that function parameter.

Is it because there is some RPC constraint? How might we write a new function in liana_gui to get around this?

3 - At DaemonControl::broadcast_spend() ([lianad/src/commands/mod.rs#L896](https://github.com/wizardsardine/liana/blob/

master/lianad/src/commands/mod.rs#L896)) they call finalize_mut() on the whole PSBT (signed_psbt) and that breaks because PDK cleans up some fields that must be present during the finalization with (assuming input at index 1 is not ours):

Seems like the workaround works. Any issue with it?

4 - Throwing LianaDescError::InconsistentPsbt at LianaDescriptor::partial_spend_info() ([liana/src/descriptors/mod.rs#L481]

(https://github.com/wizardsardine/liana/blob/master/liana/src/descriptors/mod.rs#L481)).
This method calls LianaDescError::partial_spend_info_txin() that does what it describes ((liana/src/descriptors/mod.rs#L378-L382)[https://github.com/wizardsardine/liana/blob/master/liana/src/descriptors/mod.rs#L378-L382]):

/// Get some information about a PSBT input spending Liana coins.
/// This analysis assumes that:
/// - The PSBT input actually spend a Liana coin for this descriptor. Otherwise the analysis will be off.
/// - The signatures contained in the PSBT input are valid for this script.
pub fn partial_spend_info_txin( ... )

That method does not allow not owned "coins" (external inputs).

I don't think there's an open issue in Liana. Have there been attempts to work around this or otherwise fix the problem in Liana? What does the liana team think might be a solution? I think this has been a known problem since the hackathon also.

[arturgontijo]

Were there any attempts already that we know do not work because of some constraints? If so, what were they?

Haven't tried with the current SEL implementation, pretty sure it should be more easy to do that.
The methods we want to use inside finalize_proposal() should be:

sign_psbt(self.wallet.clone(), device.clone(), psbt)
sign_psbt_with_hot_signer(self.wallet.clone(), tx.psbt.clone())

Both are async so we also would need to add some tokio "block_on" logic there, if I not missing anything here.

I will implement that and post a code snippet here about how it looks like so we have a better picture of it.

Meanwhile, my doubt still stands:

I'd recommend split this workflow into 2, so users can extract the PSBT with fees, sign/finalize it and send it back to PDK.

Wouldn't it be more useful (not only for Liana) to have an extra way to finalize_proposal(), that is split into 2 workflows, eg:

    pub fn ready_to_sign_psbt(
        mut self,
        min_fee_rate: Option<FeeRate>,
        max_effective_fee_rate: Option<FeeRate>,
    ) -> Result<Psbt, ReplyableError> {
        let mut psbt = self.apply_fee(min_fee_rate, max_effective_fee_rate)?.clone();
        Ok(psbt)
    }

// And

    pub fn finalize_proposal_with_signed_psbt(
        mut self,
        psbt: Psbt,
    ) -> Result<PayjoinProposal, ReplyableError> {
        // NOTE(arturgontijo): Compare the given PSBT against the current PSBT (maybe a check in txids)
        // Remove now-invalid sender signatures before applying the receiver signatures
        for i in self.sender_input_indexes() {
            log::trace!("Clearing sender input {i}");
            psbt.inputs[i].final_script_sig = None;
            psbt.inputs[i].final_script_witness = None;
            psbt.inputs[i].tap_key_sig = None;
        }
        let payjoin_proposal = self.prepare_psbt(psbt);
        Ok(payjoin_proposal)
    }

I must be missing some caveats here but posting it just to hear from you guys.

[arminsabouri]

Brain dump of current Liana integration progress. This is a non-exaustive list of what has been done what needs to be done. Anything that is actionable should get ticketed here.

High-Level Codebase Changes and Remaining Work

PDK

• Implemented receiver-side support for p2wsh inputs in Add expected_weight field to InputPair #772 ✅
• Implemented sender-side support for p2wsh inputs in Derive weight from witness for p2wsh inputs #862 (under review)
• Tracking weight prediction for p2tr script spends Incorrectly estimating taproot satisfiability weights #788. This is not a blocker but it does throw off weight calculation and consequently validating fee contribution.

Foreign Input Support

• Liana currently signs PSBTs only when they contain wallet-owned inputs and explicitly rejects PSBTs with foreign inputs.
• Lifting this restriction can be handled as a standalone separate PR. I need to create an issue with the liana team and see if can get help on this one. We have lifted this restriction in our integration branch but we probably have not done an exaustive job.

GUI

Send Panel

• Added support for BIP21 URIs. When the user provides a valid URI, we extract and validate the amount and address, then populate the send form fields. The BIP21 field remains optional. This feature is shippable as an independent PR.
• After sending, users require clear instructions to proceed to the PSBT tab and finalize the signature. This still needs design input. I would recommend we get in contact with the bitcoin-design + Liana product mgmt community and demo what we have built so far.

Receive Panel

• When the user initiates a Payjoin receive, the app generates a BIP21 URI with Payjoin parameters filled. However, the URI omits the amount field, which most implementations expect. We should introduce an optional amount input. An amount and bip21 field could be shipped as an independent PR.
• Once a user accepts a Payjoin receive, we must guide them to sign the proposal in the PSBT tab. This interaction needs more design work.
• Currently when the user signs a og payjoin proposal they have no way of knowing if this was a payjoin or where in the process it is. May need some design and UI help here.

Transaction Page

• The UI currently groups Payjoin transactions as generic batch payments. We should explicitly mark them as Payjoins, possibly using the Payjoin-specific color and indicate the status of the payjoin. Status should be one of [pending, waiting_to_sign, fallbacked, failed, succeeded]. This status should be derivable after we repaly the session logs. This is being worked on here
• The page displays the total input sum rather than isolating the sender or receiver’s contribution. This creates confusion, as it may appear the wallet sent or received more than it actually did.

PSBT Page

• Introduce a visual indicator for Payjoin PSBTs and potentially display the session status.
• Add a toggle to always fallback to non-Payjoin behavior, regardless of the current status.

Bitcoind

• Added support for testmempoolaccept (to check broadcast suitability). This can be delivered in an independent PR.

Lianad

• Implemented three new RPC endpoints: sendpayjoin, receivepayjoin, and getpayjoininfo. The purpose of getpayjoininfo remains ambigious. It appears that payjoin status conditionalizes certain UI flows. But more research is needed here.
• Liana supports multiple backend communication methods. So far, we’ve integrated the embedded and lianad backends. The remaining backends are stubbed with todo!() and need review.
• The receiver state machine currently bypasses critical checks (e.g., verifying ownership of inputs or whether they’ve been seen). We need to enforce these state transitions properly.

Database

• The current schema mirrors payjoin-cli, with a table for receivers and servers where each row stores serialized event data. We should instead normalize the schema by storing session events in a separate table, ordered by created_at. This is being worked on here Db refactor liana#5
• We cache OHTTP keys for faster startup.
• Both sender and receiver implementations store session metadata, but we can re-derive these fields from the event logs. We should remove the metadata tables and their corresponding fields. Being worked on here: Db refactor liana#5
• We need to implement test utils for our new database methods and write unit tests.

Error Handling

The current impl does not introduce novel error types. Instead it uses Box which doesn't seem like a standard used anywhere else in the Liana codebase.

Misc. notes

The current priority is to get Liana to payjoin-cli smoke tests working without any workaround or hacks introduced into pdk or liana. The Liana sender to pdk-cli recv flow is working after applying some fixes however the liana recv seems to have a contraint. Mainly that we cannot finalize the psbt in the GUI due to one major limitation: we dont have access to the DB and the session persister. Currently lianad picks up on the fact that the recv has signed the og psbt and injects the finalized psbt BUT the psbt that was signed did not apply the correct recv fees. So the sender will complain and close their side of the session. As of writing this I don't have a great solution but I will follow up when I do.

[arminsabouri]

As of writing this I don't have a great solution but I will follow up when I do.

Follow up. I ended up making apply_fees() pub on the payjoin side. This allows Liana to save a psbt with the receiver fees applied. When the GUI signs it pulls the psbt with fee's applied. From the prespective of the api the way we would like to see this done is to apply the fees in the gui, sign and persist. Then send the request on lianad. This unfortunately is untenable. Liana-gui does not have access to the db and it signs in an async runtime.

[yashrajd]

sorry am late to the party boys, sorry if it is stale, but my responses below:

##Send Panel
After sending, users require clear instructions to proceed to the PSBT tab and finalize the signature.

##Receive panel
Once a user accepts a Payjoin receive, we must guide them to sign the proposal in the PSBT tab. This interaction needs more design work.

Not sure what is meant here, but a PSBT tab does not sound like a good idea, user might not even know what that is!

##Transaction page
We should explicitly mark them as Payjoins, possibly using the Payjoin-specific color and indicate the status of the payjoin.

Sounds like a good idea. Need to see Liana UI and design system to make sure.

##Transaction page
Status should be one of [pending, waiting_to_sign, fallbacked, failed, succeeded]

The status shown to user should understandable to them. Where can I find what the statuses mean exactly? Txns that need action should be easily identifiable. For e.g. in"waiting to sign", if it's waiting for the other party to sign, I don't need to do anything. But if I need to sign, the transaction list item should be easily identifiable as such (first thoughts)

##Transaction page
The page displays the total input sum rather than isolating the sender or receiver’s contribution. This creates confusion, as it may appear the wallet sent or received more than it actually did.

This is super-important, and should always be accurate, as users might be startled, panicked, confused etc.

##PSBT Page

haven't thought a lot about it, but ideally such a page should not exist. Only case I can think of is if there are large number of transactions regularly, and a waiting pj transaction gets obscured.Things should be visible & actionable from in the txn list page or txn details page.

[arminsabouri]

but a PSBT tab does not sound like a good idea, user might not even know what that is!

I should have been more clear. The psbt tab is a page that already exists in the Liana application. This is not somethign we are introducing with out integration. However, the user will need to sign for the payjoins -- both as a receiver and sender -- in the psbt page.

The status shown to user should understandable to them. Where can I find what the statuses mean exactly? Txns that need action should be easily identifiable. For e.g. in"waiting to sign", if it's waiting for the other party to sign, I don't need to do anything. But if I need to sign, the transaction list item should be easily identifiable as such (first thoughts)

All good points. These status are derived from the state of the payjoin session. My plan is to tag each transaction / psbt with an optional payjoin status. If there action that needs to be taken then the status should ideally be a CTA. Note that some of the statuses are purely informational. Such as, Failed or "fallbacked".

[benalleng]

A note on my end the environment to start liana-gui on my machine has been particularly arduous. I finally created a very basic Ubuntu VM to have an OS that could finally get it up and running and have begun implementing the unimplemented receiver state checks.

[arturgontijo]

Hey Ben, I use Mac and had just to run:

cargo run -p liana-gui -- --datadir /tmp/liana_sender
cargo run -p liana-gui -- --datadir /tmp/liana_receiver

[benalleng]

I am running nixos and I am unable to get the libudev-dev dependency for the liana-gui working on my machine properly. I am hoping to sync up with @thebrandonlucas to work through possibly creating some sort of nix flake/shell to allow us nixos users to reliably spin up and environment

[benalleng]

The receiver state machine currently bypasses critical checks (e.g., verifying ownership of inputs or whether they’ve been seen). We need to enforce these state transitions properly.

In attempting to get these receiver state checks implemented we have found that because liana has direct access to these closures and is not working through an ffi layer like other integrations. As a result we need to find a different path for implementing these closures in liana.

The issue is arising because the database calls in liana all use &mut self making the closure not able to compile when referencing the upstream rust-payjoin code within the closure without also either creating some sort of mutex or changing something upstream in those functions.

We are presented with a few options going forward

1. Change rust-payjoin state check closures to use FnMut or FnOnce as the database calls in question in liana would then be able to work together.
2. create an Arc or mutex around the database call within the closure preventing the mutability requirement from being extended to rust-payjoin.
3. Keep the closures similar to their current format and instead rely on some fields made available from within liana to do these checks.

At the moment I think that we can avoid changing anything in rust-payjoin as liana does make some fields accesible from within the db that allows us to do these checks within the wallet. Long term, however, it would be good to at least make a decision on how much we should limit these closures whether we feel giving wallets the ability to work with some mutability or not by changing the rust-payjoin functions to accept something more permissive with FnMut

[benalleng]

We opted to go with down-streaming a requirement within rust-payjoin to use FnMut in the relevant closures, we have yet to decide on whether all state checks should use mutable closures but this would be the least opinionated from the framework creation standpoint.

[benalleng]

Some bugs/ bad ux I found in the payjoin-flow

GUI

• if the bip21 is input incorrectly the error remains even after it is corrected
• the broadcast button in a payjoin psbt should not be so accessible or confusing, perhaps "broadcast fallback" with a yellow button instead of green is sufficient, though we could find some other ways to make pressing it a dark pattern for the user unless they need to
• should the PSBT be removed after the transaction is complete?

lianad

• liana panics and crashes if the fee rate is too high though it does not panic after restarting the app

[arminsabouri]

One more to add to this list before I forget.

• After the reciever sign the proposal they are only presented with a broadcast option. Which IIRC broadcasts the fallback. Ideally we see two options: Respond to sender and fallback.

[benalleng]

Also the bip21 field should probably be just merged with address in the send tab

[arminsabouri]

This week:

• @arminsabouri needs to review Use FnMut closures for receiver typestate checks #883
• We've reach out the the Liana devs to go over our design and UX so we can gather feedback. Looking to set that meeting up this week.
• Allowing foreign inputs liana issue has been created but we havent heard anything yet. Dm devs and let them know we are looking for concept ack/nack

• Refactor how we are getting payjoin status when signing PSBTs. Payjoin status is used to conditionalized parts of the UI when signing. As of now there is a payjoins status json rpc that accepts a txid. However this endpoint isn't working as expected after we refactoed the db and introduced SEL. We'd prefer to keep our rpc footprint low and include this payjoin status in the response of get PSBTs.

Error handling:

• Prioritize any user facing errors: Bip21 related errors, errors when initilaizing either the sender or reciever.
• There are still lingering unwraps in the gui and lianad. They need to be replaced with proper error types

[arminsabouri]

Attendees: Manuel Gatti (liana), Armin (PDK), Ben Allen (PDK), Yashraj (Bitcoin Design Community)
Date: 25th July, 2025

• Payjoin team conducted a receiver and sender pj demo against the refrence implementation. We highlighted areas that we need UI/UX help:
  • CTA for the user to finish their payjoin session. This is relevant for both sender and reciever. Note that Liana gui framework is quite limited in capability. For the sender its recieving a payjoin proposal that they need to sign and broadcast to the Bitcoin network. For the receiver it is the original PSBT which they need to contribute inputs to, sign and reply back to the sender.
  • Best way to display legible Bip21's
  • We need to add a new amount field on the reciever flow which will then populate then be populated in the bip21
  • When a receiver finishes signing the proposal how do we indicate they are responding to the sender? And how do we make it known that they can fallback if needed?
  • How can we highlight payjoin status and txs being part of a payjoins?
  • How can we indicate the progress of a payjoin session? And what actions need to be taken by a user (similar to the first point)
  • What is the best way to display an option to fallback?
• @yashrajd will begin wireframing and addressing our UX concerns in collaboration with the Liana team. The output will be shared in a GitHub discussion on the Bitcoin Design Community repository.
• The Liana team works in two-month sprints. In the next sprint, they are available to assist with foundational PRs such as enabling external inputs and may also take on additional tickets.