Send payjoin

[DanGould]

Draft logic for sending payjoin. This is NOT a complete design by any means, just a PoC draft to start a conversation and demonstrate the parameters of an integration.

@icota how feasible does payjoin seem too pursue?

Regarding the design

First, create_payjoin makes an http request which should proxy through http_tor. Payjoin endpoints are often .onion services. Should payjoin functions rather be exposed to a Dart file which then consumes the logic to create the request? native wallet ffi should probably not have a reqwest dependency.

Second, errors are handled with panics here. I see an error_return Psbt dummy used for data transport. Is this for the c bindings? Production code should obviously not panic like this PoC does.

I'm curious too hear any feedback you may have

[icota]

This is awesome, thank you @DanGould. Obviously we'd love to have BIP78 in Envoy.

I think it makes sense to have payjoin in a separate (Dart) package/(Rust) crate combo, especially cause, from a UI perspective, I think this is a two step process that can be separate from wallet.

1. After scanning the BIP21 we'd use the payjoin "bindings" to payjoin::Uri::try_from() and, if we have a winner, surface some info about the payjoin to the user.
   Some stuff needs to be handled: like if the PJ server is an .onion address and we're not connected to Tor we can offer the user the option to enable it (maybe just for this payment?)
2. If the user decides to PJ we'd use use payjoin to fetch the PSBT. We'd pass the Tor proxy address if need be and probably talk to the server with something blocking from http_tor (it uses reqwest internally)

We can get away with blocking in Rust cause a payjoin can be instantiated in a separate Dart isolate (threads basically).

[icota]

FWIW I think UI and "backend" work here can be totally decoupled.

I see an error_return Psbt dummy used for data transport. Is this for the c bindings? Production code should obviously not panic like this PoC does.

On the FFI boundary instead of panicking we return some sentinel value (not very Rusty but it's FFI). We check for that value on Dart side and handle it in the UI. We also use last_error_message which is a string representation of the Rust error.

[Jacksonearl2468]

Assigned

[ConorOkus]

Hi @icota @Jacksonearl2468 does it make sense to have everything run at the application layer using - https://github.com/LtbLightning/payjoin-flutter cc @BitcoinZavior?

[BitcoinZavior]

Hi @icota @Jacksonearl2468 does it make sense to have everything run at the application layer using - https://github.com/LtbLightning/payjoin-flutter cc @BitcoinZavior?

Payjoin-flutter can be decoupled from the UI logic and used selectively, every user may not want to use PayJoin.

[icota]

We are in the midst of a migration to BDK 1.0 so Payjoin will have to wait until after that is done. We prefer to use PDK directly rather than go through Flutter bindings

[securitybrahh]

migration to BDK 1.0

where can I track this migration, do the bdk guys call this "wallet".

little Confusion regarding the vocab they using 👇

https://github.com/bitcoindevkit/bdk/releases

[icota]

where can I track this migration, do the bdk guys call this "wallet".

@securitybrahh you can track it here: https://crates.io/crates/bdk_wallet

We will release an Envoy beta this week with (our fork of) the above. Unfortunately still no Payjoin but it's on the roadmap.