Implement PayJoin / Pay-to-EndPoint

[PastaPastaPasta]

PayJoin (also called pay-to-end-point or P2EP) is a special type of CoinJoin between two parties where one party pays the other. This coinjoin type has different (probably better) privacy properties. The transaction then doesn't have the distinctive multiple outputs with the same value, and so is not obviously visible as an equal-output CoinJoin.

An overview of PayJoin with additional information and links can be found here https://en.bitcoin.it/wiki/PayJoin

Implementing PayJoin would potentially need OpenSSL to communicate with the PayJoin server (unless I am misunderstanding how PayJoin works) as such, implementing this would have similar objections to BIP 70.

Looking forward to hearing thoughts.

[kristapsk]

Concept ACK

I'm looking forward to implement it as a shell script as a part of my bitcoin-scripts project. But native support in bitcoin-qt would be nice too. But I guess BIP needs to be finished first.

Related - CoinJoin and transaction privacy / fungibility megathreads.

[NicolasDorier]

@instagibbs worked on some script I think

[PastaPastaPasta]

BIP78 was merged on the 25th of June

Related: https://github.com/chaincase-app/payjoin/releases/tag/v0.1.0-alpha-client

Usage: ./binary_name port_number(bitcoin core) cookie_file_path(bitcoin core) bip21_uri

Cc: @DanGould

[Kenshiro-28]

Optional payments with Payjoin would be great, even if it requires both parties are online.

[DanGould]

The BIP-77: Payjoin V2 proposal gets rid of the requirement for both parties to be online and the requirement to use TLS. It's authenticated with Hybrid Public Key Encryption that depends on cryptographic primitives already in bitcoin instead (ChaCha20-Poly1305, Secp256k1, Sha256).

[Kenshiro-28]

Great, I hope it's implemented :)

[Kenshiro-28]

@DanGould while PayJoin offers improved privacy over traditional Bitcoin transactions, there's a concern about the potential exposure of UTXO balances. This is particularly risky for users with substantial BTC holdings, as the balance of the UTXOs used in a transaction is visible to the payee.

I propose an enhancement to PayJoin that involves using UTXOs below a certain threshold (e.g., 0.1 BTC). This would entail:

• Threshold Implementation: Automatically selecting UTXOs for PayJoin transactions that are below the specified threshold.
• UTXO Splitting: When a larger UTXO needs to be used, it could be split in a subsequent transaction. This could be done either in the next payment or through a controlled, self-directed PayJoin transaction.

Advantages:

• Enhanced Privacy: Reduces the risk of exposing large BTC balances in transactions.
• Flexibility: Offers users the ability to manage their UTXO sizes according to their privacy needs.

This could need higher fees, but for some people would be fine.

[kristapsk]

For payjoin receiver, IMHO it makes sense to always contribute smallest amount UTXO available. That way you likely don't expose some big value UTXOs (assuming they aren't the only ones in your wallet) and also it works as UTXO consolidation.

[achow101]

BIP 78 will not be implemented because of the TLS requirement. However, I think we could implement BIP 77 Async Payjoin, and have opened a tracking/brainstorming issue for that: #33684