implement payjoin (bip78)

[SomberNight]

We should implement payjoin (BIP-78).

Note that JoinMarket already has a python implementaion, although they use twisted instead of asyncio.

[DanGould]

The most robust way to integrate this might be by using BDK's approach to bindings to the rust-payjoin library

[SomberNight]

I assume you mean https://github.com/payjoin/rust-payjoin ?

I have several qualms about "just write bindings to this cool rust library and use that":

• we need python bindings for it, which somebody has to write and maintain
• we need to build the rust library for all platforms we release for, and integrate this in the build scripts
• the project would move even further from being "pure python": currently you ~only need libsecp (which is trivial to build, and is packaged anyway by distros) and you can just run the project with a python interpreter. Many people run from source on Linux, and some on other OSes.
• but most importantly, have you looked at how many dependencies these crates have? I just looked at what I assume to be your crate right now, and it has 248 (!!!) dependencies. Do you expect us to just package those and include it in the binaries that our users trust with their money? To review all that, and ideally in a continuous basis, seems to be an intractable problem to me.

Compare that with adding 500 lines of python code to our codebase.

Sorry but I am in general somewhat reluctant to add new dependencies. Even if it is just a standalone new python package we would want to depend on, we think three times before adding it, and consider how much that package would do for us versus how large it is. Your proposal simply looks extreme compared to that.

[DanGould]

I appreciate the feedback. I hope my one line suggestion didn't come off as flip. The vision for this crate is to be a central well-tested repository of the protocol, a sort of Payjoin Dev Kit, with a roadmap for adding FFI bindings in the same flavor as LDK and BDK, based on those used to deploy Mozilla's cross-platform password manager. Their Idea was to keep security-focused code in a central rust repository and use bindings to deliver it to end users. There are half a dozen people contributing behind the scenes to improve it.

Note the cargo.lock you've linked includes lots of packages outside of the main payjoin dependency which has very few dependencies beyond the extremely well vetted rust-bitcoin crate. Most of those are for payjoin-cli which does bring in lots of dependencies for convenience for cli and http. An electrum integration would not need those.

If the implementation were one of merely 500 lines of code and a few hours of hacking, I'm sure it would have been at least drafted in the past three years since this issue was created, especially considering python reference is available in JoinMarket. In my view, even the JoinMarket implementation is highly constrained in functionality while being tightly coupled to that codebase.

Perhaps an approach to balance the valid concerns you raise with user demand would be to distribute via an electrum plugin first. I do believe the concern that such an application would stray from "pure python" is valid. A plugin would keep the dependencies and bindings separate from the core of electrum and provide a platform to judge feedback from the community. Is this page the extent of the documentations? Are there minimal examples? I found this guide from 2018 too. Thank you for your careful consideration.