Coinjoin is currently the most effective method of introducing uncertainty into the tracing of UTXOs in a chain analysis. As we have seen in previous chapters, to obtain a high-performance mix, inputs and outputs must be as homogeneous as possible. In addition, it's important that UTXOs are integrated into as large a group as possible to maximize anonsets. So, for coinjoins to be effective, they must involve a large number of uniform UTXOs. This multitude of requirements means that coinjoin transactions have a very rigid structure: the amounts are fixed in advance, and all participants must adhere to them to guarantee the uniformity of the process. In addition, coinjoins require synchronization between all participants and the coordinator during transaction construction.

These requirements make coinjoin unsuitable for direct payments. For example, if you have a 1M-sat coin in a coinjoin pool, using it directly as a payment would be complex. It would require synchronization with the other participants and the coordinator to build the collaborative transaction precisely at the moment you need to make a payment, and the purchase amount would have to correspond exactly to the value of your coin, which is virtually unfeasible. The coinjoin transaction, therefore, is by its very nature a collaborative sweep transaction, i.e., it typically involves the same owners of the inputs that are found in the outputs.

However, it would be interesting to have transaction structures that allow payments to be made in a practical way, while simultaneously introducing doubt into chain analysis. This is precisely what we'll be looking at in this chapter and the next.

The payjoin is a specific Bitcoin transaction structure that enhances user privacy when spending by collaborating with the payment recipient.

It was in 2015 that LaurentMT first discussed this method under the name "steganographic transactions", according to a document available here. This technique was later adopted by the Samourai Wallet, which in 2018 became the first client to implement it using the Stowaway tool. The concept of payjoin is also found in BIP79, BIP78, and BIP77. Several terms are thus used to refer to a payjoin:

The special feature of PayJoin lies in its ability to generate a transaction that appears ordinary at first glance but is, in fact, a mini CoinJoin between two people. To achieve this, the transaction structure involves the payment recipient in the inputs alongside the actual sender. The recipient thus includes a payment to himself in the middle of the transaction, which itself enables him to be paid.

Let's take an example to better understand this process. Alice buys bread for 4,000 sats using a UTXO of 10,000 sats and opts for a payjoin. Her baker, Bob, adds a UTXO of 15,000 sats belonging to him as input, which he recovers in full as output, in addition to Alice's 4,000 sats.

In this example, Bob the baker enters 15,000 sats in input and exits with 19,000 sats, the difference being exactly 4,000 sats, i.e., the price of the baguette. On Alice's side, she enters 10,000 sats and ends up with 6,000 sats in output, which represents a balance of -4,000 sats, i.e., the price of the baguette. To simplify the example, I've deliberately omitted the mining costs in this transaction.

The payjoin transaction fulfils two objectives, enabling users to enhance the confidentiality of their payment.

Firstly, Payjoin aims to mislead an outside observer by creating a lure in the chain analysis. This is made possible by the CIOH heuristic (Common Input Ownership Heuristic). As we saw in Part 3, when a transaction on the blockchain has multiple inputs, it is typically assumed that all these inputs belong to the same entity or user.

So, when an analyst examines a payjoin transaction, they are led to believe that all inputs come from the same person. However, this perception is wrong because the payee also contributes to the inputs alongside the actual payer. The chain analysis is therefore diverted towards an interpretation that proves to be incorrect.

Let's take our example of a payjoin transaction for the payment of bread:

Seeing this transaction on the blockchain, an outside observer following the usual heuristics of blockchain analysis would make the following interpretation: "Alice merged 2 UTXOs as inputs to the transaction in order to pay 19,000 sats to Bob".

This interpretation is obviously incorrect, because as you already know, the two UTXOs in the inputs don't belong to the same person. One comes from Alice, the baguette buyer, and the other from Bob, the baker.

In this way, the external observer's analysis is steered towards an erroneous conclusion, ensuring that the confidentiality of stakeholders is preserved.

The second purpose of PayJoin is to mislead an outside observer about the actual amount of the payment that has been made. By examining the transaction structure, the analyst might conclude that the payment is equivalent to the amount of one of the outputs.

If we return to our example of purchasing bread, the analyst will conclude that the payment amount corresponds to either the UTXO of 6,000 sats or the UTXO of 19,000 sats. In this case, the analyst will rather think that the payment amount is 19,000 sats, because there are 2 UTXOs in outputs, at least one of which is greater than 6,000 sats (there is no logical reason to use 2 UTXOs to pay 6,000 sats when a single UTXO would have been sufficient to satisfy this payment).

But in reality, this analysis is flawed. The payment amount does not correspond to any of the outputs. It is, in fact, the difference between the recipient's UTXO in output and the recipient's UTXO in input.

In this respect, the payjoin transaction falls into the realm of steganography. It allows the real amount of a transaction to be hidden within a fake transaction that acts as a decoy.

Steganography is a technique for concealing information within other data or objects, making the presence of the hidden information imperceptible. For example, a secret message can be concealed within a dot in unrelated text, making it undetectable to the naked eye (this is the microdot technique).

Unlike encryption, which renders information incomprehensible without the decryption key, steganography does not modify information. It remains displayed in clear text. Rather, its aim is to conceal the very existence of the secret message, whereas encryption clearly reveals the presence of hidden information, albeit inaccessible without the key. This is why the original name of PayJoin was "steganographic transactions".

An analogy can be drawn between cryptography and coinjoin, as well as between steganography and payjoin. Coinjoin has similar attributes to encryption: the method is recognizable, but the information is indecipherable. Conversely, payjoin is similar to steganography: the information is theoretically accessible, but since the method of concealment is not recognizable, it becomes inaccessible.

Well-known software programs that support payjoin include Sparrow Wallet, Wasabi Wallet, Mutiny, BitMask, BlueWallet, and JoinMarket, as well as payment processor BTCPay.

The most advanced payjoin implementation is undoubtedly the Stowaway invented by the developers of Samourai Wallet. Since the arrest of the software’s founders, this tool has only worked partially on Samourai. However, it has been relaunched on the Ashigaru application.

The advantage of Stowaway is that it is a complete and very easy-to-use protocol that supports both receiving and sending payjoins. Partially signed transactions can be exchanged manually by scanning multiple QR codes or automatically over Tor via Soroban.

The difficulty in using PayJoin lies in its dependence on the merchant's participation. As a customer, you can't use a payjoin if the merchant doesn't support it. This adds a further difficulty to the purchase process: not only is it challenging to find merchants who accept Bitcoin, but if you also look for those who support PayJoins, it becomes even more complicated.

One solution would be to use transaction structures that introduce ambiguity into the chain analysis without requiring the recipient's cooperation. This would enable us to improve the confidentiality of our payments without relying on the active participation of merchants. This is precisely what we'll be looking at in the next chapter.