Add Payjoin support

[notmandatory]

Description

Implement (optional) BIP-0078 PayJoin support in the bdk-cli wallet using the rust bip78 project. PayJoin transactions provides a way to collaboratively create a transaction with a receiver in a way that prevents on-chain surveillance from using the common input ownership heuristic. Adding this feature to the bdk-cli project will demonstrate to other wallet builders using bdk how to add PayJoin support.

Expected Outcomes

• Integrate BIP-0078 functionality as an optional feature in bdk-cli using the rust bip78 crate
• Contribute upstream to the rust bip78 project if any bugs or other issues are found
• Document how to use new PayJoin functionality with bdk-cli and common services such as BTCPayServer

Resources

• bdk and bdk-cli projects
• rust-payjoin project and PayJoin
• The Rust Book
• PayJoin adoption

Skills Required

• Rust language development, or similar language with willingness to learn rust
• Be able to send and receive bitcoin transactions on testnet with bdk-cli and other wallets
• Basic understanding bitcoin transaction building

Mentor(s)
@notmandatory

Difficulty
Hard

Competency Test

• Install rust
• Clone and run bdk-cli, create single signature descriptor wallet, receive and send testnet bitcoin
• Demonstrate rust coding skill:
  • via simple rust program
  • OR by completing rustlings exercises: variables, functions, if, primitive types

[notmandatory]

Moving this to bdk-cli since this doesn't need to be part of the core bdk library, but still useful to have an example using bdk in the bdk-cli tool.

[DanGould]

Could this be reviewed in separate send / receive portions? There is a CLI tool based on the bip78, actively maintained payjoin crate that would be straightforward to add to bdk-cli at this point.

[notmandatory]

Hi yes since this will be done by a summer of bitcoin student new to rust and bitcoin I'd like the idea of focusing on an easy win of adding send first. Then we can separately work on the receive side, and/or work on any open issues in the bip78 crate or the payjoin bin.

[DanGould]

To get started on a sender CLI integration, check out this bitcoind payjoin-client cli based using the payjoin crate and this bdk + payjoin sender that's working in wasm at https://bitmask.app

[rajarshimaitra]

Thanks @DanGould for the pointer to the new payjoin repo.

@notmandatory I think we should update the description to refer to https://github.com/payjoin/rust-payjoin, as that seemed more current.

I went through the payjoin-client briefly, and it seems the send and recv logic is already there. The payjoin sending and receiving should be more involved than regular send/recv as it requires interaction with the sender. So makes sense to add a new send function.

This can be done as a separate send_payjoin and recv_payjoin function which takes in a bip21 URL and follows the logic of payjoin-client of the reference crate.

We can then feature gate it under a new payjoin feature and optional dependency on rust-payjoin.

This could be an extensive but achievable project for SOB. Pretty excited for this one. 😃

[DanGould]

I'm working on in-depth step-by-step documentation for both sender and receiver integrations. I figure it is appropriate to share here.

https://github.com/payjoin/rust-payjoin/pull/52/files?short_path=6a88930#diff-6a889308600e4d0b66f543c0d55b7b6238d10a6203f68ff79701f7cbaf8bbcad

[tusharxoxoxo]

@DanGould Thank you for sharing this here. It will be very beneficial in implementation of Payjoin support

[BullishNode]

I'm working on in-depth step-by-step documentation for both sender and receiver integrations. I figure it is appropriate to share here.

https://github.com/payjoin/rust-payjoin/pull/52/files?short_path=6a88930#diff-6a889308600e4d0b66f543c0d55b7b6238d10a6203f68ff79701f7cbaf8bbcad

Extremely helpful. Thank you

[willowenss]

So far have set up local dev environment (using visual studio code) and have cloned both bdk-cli and rust-payjoin. I then installed bitcoind+bitcoin-cli locally. Also set up local regtest bitcoind wallet. I moved the Bitcoin directory onto my desktop and created a bitcoin.conf file to specify my rpc credentials in order to interact w bitcoin core. I set rpcuser+password and then set restnet=1 in the configuration to file to configure regtest mode. I can now use the bitcoind command to run my own node, but I'm going to use bitcoind -regtest to start bitcoin core in regtest mode (I think creates a local private network).

[willowenss]

My next action item is to start bitcoin core in regtest mode and use the regtest wallet+bitcoin-cli to interact with the network and test bdk-cli and payjoin. I will need to generate two separate wallets in order to test payjoin

[willowenss]

Have finished testing bdk-cli in regtest. I used electrs in Rust and made a regtest wallet then tested the functionality after specifying the bitcoind regtest instance. If anyone has ideas on how to test the functionality/behavior of bdk-cli in the most thorough way possible, I would love to know (I'm sure I didn't test everything I could have). I still need to test payjoin in regtest

[notmandatory]

You should also try testing with the new Mutiny signet network and faucent. See: https://blog.mutinywallet.com/mutinynet/

bdk-cli -n signet wallet -s https://mutinynet.com/api -d "tr(tprv8ZgxMBicQKsPe67zv5U9x6u1ZY2rLayXm365byTL4fYj3HGxe2SpQ6jjF8TRuFekexLP7HdTzxbTBZ2iNszfE7Gwyd8j1ebASTFybu2iQdX/*)" get_balance
{
  "satoshi": {
    "confirmed": 100000,
    "immature": 0,
    "trusted_pending": 0,
    "untrusted_pending": 0
  }
}

[willowenss]

Successfully tested payjoin-cli today - the main barrier was me figuring out the configuration. I need to get more comfortable using bitcoin-cli tool

[notmandatory]

A little trick I do when I'm working with the bitcoin-cli is do a --help command and copy/paste the output to a local note since the docs on the web are often out of date with what ever version I'm running

[willowenss]

Opened a pull request to add my README to payjoin-cli:
https://github.com/payjoin/rust-payjoin/pull/79/commits

[willowenss]

Proposed BDK send-payjoin command that accepts a BIP21 URI

• One thing to note is that I was wondering whether or not to have the user parse the bip21 (command takes the address and payjoin endpoint, then generates a BIP21 + can send after). Perhaps make a different command to create the bip21?

Syntax:
bdk-cli wallet send-payjoin <bip21_uri> --amount= [number of sats]
This command proposal accepts a BIP21 including payjoin details (address of the contributor and secure endpoint). It also supports the --amount option to specify the desired amount in satoshis for the payjoin transaction.

Options:

• <bip21_uri>: The complete BIP21 URI containing the payjoin details.
• -- [number of sats] : Specifies the desired amount in satoshis for the payjoin transaction. If not provided, the generated payjoin transaction will use the amount specified in the BIP21 URI. This option can override the number of sats specified in the BIP21.

Example usage:
bdk-cli wallet send-payjoin "BITCOIN:1PvMqxFQv3q8v1e9JtMKk2j5wvGveWGNp5?amount=0.0005&pj=https://localhost:3010/" --amount=50000

This command takes a payjoin-capable BIP21 URI and sends the payjoin transaction with the desired amount of satoshis using the bip21 or --amount option.

[DanGould]

A look at Bitcoin Design Guide's case study might lend some inspiration. BlueWallet requires a bip21 to initiate a send no matter what and then prompts to confirm / change the amount. That user story could apply here as well.

I think Signal is an application design success story, so I find their contributing guidelines/development idology compelling. The first truth they find self evident is

The answer is not more options. If you feel compelled to add a preference that's exposed to the user, it's very possible you've made a wrong turn somewhere.

Reading in the required bip21 amount otherwise prompting seems to align with this philosophy.

[notmandatory]

@willowenss API looks good, but I agree with @DanGould we shouldn't need a required --amount option. Another way to handle confirmation in the case you don't want to be prompted is to have an optional -y option that skips the user confirmation prompt about the amount, without that option it would require the user to confirm.

This is how an option like that is documented for the apt-get command:

-y, --yes, --assume-yes
           Automatic yes to prompts; assume "yes" as answer to all prompts and run non-interactively.

EDIT: But for now no need for a -y option, can add it later if needed, best to keep it simple if we can.