Conversation
6c93104 to
943eb03
Compare
f24e841 to
00c9c51
Compare
f39de07 to
b6b17ff
Compare
b6b17ff to
f53d60a
Compare
bf50b25 to
244c5df
Compare
244c5df to
31b32f6
Compare
31b32f6 to
44b658c
Compare
f5ce076 to
93db05b
Compare
d0f60d0 to
da7ff64
Compare
xstoicunicornx
left a comment
There was a problem hiding this comment.
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)
| let bip21 = session.pj_uri().to_string(); | ||
|
|
||
| let mut db_conn = self.db.connection(); | ||
| db_conn.update_payjoin_receiver_bip21(new_index.into(), &bip21); |
There was a problem hiding this comment.
Since this is now no-op this call is probably no longer needed?
| Ok(GetAddressResult::new(address, new_index, Some(bip21))) | ||
| } | ||
|
|
||
| /// Get Payjoin URI (BIP21) and its sender/receiver status by txid |
There was a problem hiding this comment.
| /// Get Payjoin URI (BIP21) and its sender/receiver status by txid | |
| /// Get receiver session ID and its sender/receiver status by txid |
| } | ||
|
|
||
| /// Get all active payjoin receiver sessions with their derivation indexes | ||
| pub fn get_active_payjoin_sessions(&self) -> Result<Vec<u32>, CommandError> { |
There was a problem hiding this comment.
I believe that the plan is to also support sending payjoin in liana correct? Should this fn name maybe be get_active_receiver_payjoin_sessions instead to remove ambiguity in future when there may also be active payjoin sender sessions?
| /* Payjoin OHttpKeys */ | ||
| CREATE TABLE payjoin_ohttp_keys ( | ||
| id INTEGER PRIMARY KEY NOT NULL, | ||
| relay_url TEXT UNIQUE NOT NULL, |
There was a problem hiding this comment.
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.
| } | ||
|
|
||
| /// Get bip21 for a receiver session by derivation index | ||
| pub fn get_payjoin_receiver_bip21(&mut self, derivation_index: u32) -> Option<String> { |
There was a problem hiding this comment.
This seems to just return a normal address and not a bip21?
| } | ||
| } | ||
|
|
||
| pub(crate) fn fetch_ohttp_keys( |
There was a problem hiding this comment.
Is it possible to reuse PDK's implementation of fetch_ohttp_keys?
| 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)?; |
There was a problem hiding this comment.
No fee range actually being applied.
|
Thanks for the feedback, Regarding the UI notes.
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
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
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 |
This is definitely an artifact of me playing in the database between naming the timestamp |
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.
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. |
This adds support for payjoin receive in liana.
This is currently WIP and has the following TODOs