Explore integration of Payjoin/PDK

[moneyball]

There is an opportunity to use Payjoin to make deposits into LDK Node use 1 txn instead of 2 when an on-chain txn funds a LN wallet/channel. Mutiny is doing this. We should explore it on LDK Node (probably medium priority behind LSP client, VSS, Electrum support).

[tnull]

Yeah, I agree that, while not being an immediate priority, it would be a nice-to-have in the future. This would probably also depend on/go hand in hand with #178.

[DanGould]

Payjoin V2 in PDK eliminates the need for tor #178

[tnull]

Payjoin V2 in by PDK eliminates the need for tor #178

That's good to know! Is my impression correct that v2 is still work-in-progress in PDK? Or is it already useable?

[DanGould]

It's been released as a usable alpha with feature flag v2

[tnull]

It's been released as a usable alpha with feature flag v2

Great! Do you mind pointing me to some code that roughly shows how v2 integration looks like? I think I got confused before as the only reference to v2 I could find in the docs are the module-level docs here, which don't seem to indicate that it's ready/how it could be used: https://docs.rs/payjoin/latest/payjoin/v2/index.html

[DanGould]

v1 an v2 are backwards compatible so you should be able to use the instructions in send and receive modules. Receive has it's own v2 module Follow the payjoin-cli reference implementation's v2 feature codepath. The evolving mutiny-node implementation is another reference.

Once you construct send's RequestContext from the builder you can poll the directory by repeatedly calling extract_v2

The top level v2 module ought to be private in the next update.

[DanGould]

Now with the payjoin-1.0.0-rc.0 release, it might be time for this issue since persistence is standardized, which afair was the big blocker. I've heard that you'd like a "batteries included" rusqlite persistence crate, and this integration might be the one to first duplicate the code and then see what can be abstracted between it and the reference payjoin-cli tool to make it.

Let's talk about this at the Rust summit

[tnull]

Now with the payjoin-1.0.0-rc.0 release, it might be time for this issue since persistence is standardized, which afair was the big blocker.

Cool!

I've heard that you'd like a "batteries included" rusqlite persistence crate

Not quite sure if I understand this right, but no, we'd prefer to find a way to persist and payjoin-related data via our async KVStore trait, so that users can freely choose their backend implementation.

Let's talk about this at the Rust summit

Yes, let's talk about it more next week!