LaurentMT/Steganographic Transactions, Deception Tools and Asymmetric Games

## Steganographic Transactions, Deception Tools and Asymmetric Games

1/ About the nature of Payjoin Transactions and Deception Tools

I'm used to describe Payjoin Transactions as Steganographic Transactions but they can also be described more generally as "Deception Tools" (https://medium.com/@laurentmt/hi-ilya-e72ddda60b35).

In my humble opinion, the use of deception tools is a legit and effective strategy for improving on-chain privacy but it's important to keep in mind that the deception game has its own rules and these rules are very different from others approaches (like "privacy backed by maths" tools).

An important principle of this deception game is that it must introduces and preserves some kind of morphism between interpretations. It should be absolutely impossible for an analyst to distinguish between one form and the other.

For instance, we have:

Transactions with 2 "senders"                 <=>         Transactions with a single "sender"

 Stowaway (Payjoin)                           <=>          Simple Payment

 Stonewallx2                                  <=>          Stonewall
 (Equal-amount CJ with 2 participants)                     (imitation of a Stonewallx2)


2/ An Asymmetric Game

This deception game is an asymmetric game between Privacy Enhancing Tools (PETs) and Chain Analytics platforms (CA). And truth be told, asymmetry doesn't play in favor of PETs.

The reason is simple: a single mistake (privacy leak) may be enough for a CA platform to win a round of the game (i.e. correct interpretation of a transaction). On the other side, a PET must have everything correct (no leak, no fingerprint) everytime to win the game.

That highlights an important challenge for PETs willing to play the deception game: Transaction fingerprinting is paramount. For instance, no factor should allow a CA platform to distinguish a Payjoin from a Simple Payment.


3/ Cross-compatible Payjoins VS Payjoins between users of a same wallet implementation

When we think about it, many factors may be used to fingerprint a wallet (implementation of BIP69 or not, use f RBF or not, management of nlocktime, coin selection strategy, etc)
And these are just examples of existing factors. New factors may occur in the future with new features/BIPs being implemented by wallets.

That highlights a new point: Playing this deception game with a cross-compatible implementation isn't the same thing as playing the game with a single wallet implementation. The latter is far easier because it's easier to enforce a homogeneous fingerprint across wallets in the scope of a single implementation.

Truth be told, consequences for wallets developers of the adoption of a cross-compatible Payjoin are far larger than just implementing some network plumbing with a endpoint.


4/ Which tactics for playing the deception game with a cross-compatible implementation?

Recent renewed interest for a cross-compatible Payjoin raised again questions about how to play this deception game in the context of a cross-compatible implementation and questions about the associated challenges in terms of transaction fingerprints. https://github.com/btcpayserver/btcpayserver-doc/issues/486

While it's good to list all factors that may act as a threat, it's my opinion that we should take the time to think about what we want to achieve and how we're going to achieve it.

The strategy is known. We want to play an asymmetric deception game and transactions fingerprinting is one of the main challenges.

Now, the question is what is the best tactic to play this game while minimizing the asymmetry?

As far as I can tell, a recent trend in the ecosystem is that wallets should converge towards a common fingerprint for theirs transactions. I'm certainly in the minority here, but I think that it's a loosing tactic in the context of Bitcoin.
My rationale for believing this isn't technical. The point is that trying to enforce such a tactic implies a large coordination effort between wallet implementations. By coordination, I mean a temporal coordination ("when do we release a new feature?") but also a coordination in terms of features implemented by the wallets.
Another challenge is that as soon as an implementation relaxes its effort (i.e. lags behinds others implementations), asymmetry starts to play against us. Again.
In my humble opinion, the only way to achieve this would be to converge towards a single wallet implementation or to have a "central committee" coordinating how wallets implementations evolve. Both solutions seem antithetical to Bitcoin's ethos and more importantly don't seem sustainable on the long term. The most likely outcome is that it will lead to exhausted or frustrated developers and to a decreasing effort in maintaining the synchronicity between implementations. And you know the conclusion, asymmetry will start to play against us again.

Another tactic might be what I'm used to call "Embrace the chaos". In the context of this topic, it might be implemented by what I call "Drunk Wallets" or by what Nopara73 calls "Clusterfuck Wallets".
In a nutshell, instead of trying to have all wallet implementations in sync with others implementations, let's try to have wallets generating random fingerprints.

I don't think that such a tactic would solve all the challenges (especially regarding challenges related to temporal aspects of new features) but I believe that it may help to decrease the pressure put on wallet developer and to make the effort more sustainable on the long term (as in "better balance in the asymmetry of the game").

To be honest, I don't even know if a "strong" cross-compatible implementation of Payjoin is a realistic goal. Perhaps it isn't possible but that raises a new question: Do we need a "strong" cross-compatible implementation of Payjoin?


5/ Impacts of a "weak" cross-compatible implementation

Note: The term "weak" used in this section isn't a judgment. It justs highlights the fact that all Payjoin implementations may not be equal and that a cross-compatible implementation may never provide the same guarantees as the ones provided by Payjoins between wallets using a same implementation.

I think this is a very legit question. After all, as long as users are aware of the limitations and potential risks, a weak implementation of Payjoin may still provide positive outcomes.

So, what can we realistically expect from a "weak" implementation of Payjoin?

In my opinion, we shouldn't expect that the adoption of Payjoin will lead to the end of all CA platforms. I suspect that all CA platforms aren't made equals. Thus, I expect that adoption of Payjoin may lead to the end of a large number of less sophisticated actors and as a consequence to a concentration of the actors operating on this market (like 2 or 3 global companies).
A likely consequence of this concentration is that it may strengthen the positions of these actors and put them in a better position to "negociate" with regulated businesses (as in "Hey Mr. Exchange! Share your data with us.").
Obviously, in this context, A Payjoin used mostly for transfers between end-users and exchanges would achieve very little for Bitcoin fungibility.
That leads me to think that an important objective for Payjoin is its adoption for payments between unregulated and non-identified actors (a.k.a end-users, DNM, etc) and not just between end-users and easily identifiaed actors.


6/ Privacy BIPs

Note: This point isn't specific to Payjoin.

What should be the content of a "Privacy BIP" is still an open question for me.
A huge challenge encountered by PETs is that all details matter. Get something wrong and what was supposed to be a solution becomes a new problem.
Thus, the question is: How do we write "Privacy BIPs" that don't lead developers to implement solution doing more harm than good? Is there such a thing as a "Privacy BIP"?

	1/ About the nature of Payjoin Transactions and Deception Tools

	I'm used to describe Payjoin Transactions as Steganographic Transactions but they can also be described more generally as "Deception Tools" (https://medium.com/@laurentmt/hi-ilya-e72ddda60b35).

	In my humble opinion, the use of deception tools is a legit and effective strategy for improving on-chain privacy but it's important to keep in mind that the deception game has its own rules and these rules are very different from others approaches (like "privacy backed by maths" tools).

	An important principle of this deception game is that it must introduces and preserves some kind of morphism between interpretations. It should be absolutely impossible for an analyst to distinguish between one form and the other.

	For instance, we have:

	Transactions with 2 "senders" <=> Transactions with a single "sender"

	Stowaway (Payjoin) <=> Simple Payment

	Stonewallx2 <=> Stonewall
	(Equal-amount CJ with 2 participants) (imitation of a Stonewallx2)


	2/ An Asymmetric Game

	This deception game is an asymmetric game between Privacy Enhancing Tools (PETs) and Chain Analytics platforms (CA). And truth be told, asymmetry doesn't play in favor of PETs.

	The reason is simple: a single mistake (privacy leak) may be enough for a CA platform to win a round of the game (i.e. correct interpretation of a transaction). On the other side, a PET must have everything correct (no leak, no fingerprint) everytime to win the game.

	That highlights an important challenge for PETs willing to play the deception game: Transaction fingerprinting is paramount. For instance, no factor should allow a CA platform to distinguish a Payjoin from a Simple Payment.


	3/ Cross-compatible Payjoins VS Payjoins between users of a same wallet implementation

	When we think about it, many factors may be used to fingerprint a wallet (implementation of BIP69 or not, use f RBF or not, management of nlocktime, coin selection strategy, etc)
	And these are just examples of existing factors. New factors may occur in the future with new features/BIPs being implemented by wallets.

	That highlights a new point: Playing this deception game with a cross-compatible implementation isn't the same thing as playing the game with a single wallet implementation. The latter is far easier because it's easier to enforce a homogeneous fingerprint across wallets in the scope of a single implementation.

	Truth be told, consequences for wallets developers of the adoption of a cross-compatible Payjoin are far larger than just implementing some network plumbing with a endpoint.


	4/ Which tactics for playing the deception game with a cross-compatible implementation?

	Recent renewed interest for a cross-compatible Payjoin raised again questions about how to play this deception game in the context of a cross-compatible implementation and questions about the associated challenges in terms of transaction fingerprints. https://github.com/btcpayserver/btcpayserver-doc/issues/486

	While it's good to list all factors that may act as a threat, it's my opinion that we should take the time to think about what we want to achieve and how we're going to achieve it.

	The strategy is known. We want to play an asymmetric deception game and transactions fingerprinting is one of the main challenges.

	Now, the question is what is the best tactic to play this game while minimizing the asymmetry?

	As far as I can tell, a recent trend in the ecosystem is that wallets should converge towards a common fingerprint for theirs transactions. I'm certainly in the minority here, but I think that it's a loosing tactic in the context of Bitcoin.
	My rationale for believing this isn't technical. The point is that trying to enforce such a tactic implies a large coordination effort between wallet implementations. By coordination, I mean a temporal coordination ("when do we release a new feature?") but also a coordination in terms of features implemented by the wallets.
	Another challenge is that as soon as an implementation relaxes its effort (i.e. lags behinds others implementations), asymmetry starts to play against us. Again.
	In my humble opinion, the only way to achieve this would be to converge towards a single wallet implementation or to have a "central committee" coordinating how wallets implementations evolve. Both solutions seem antithetical to Bitcoin's ethos and more importantly don't seem sustainable on the long term. The most likely outcome is that it will lead to exhausted or frustrated developers and to a decreasing effort in maintaining the synchronicity between implementations. And you know the conclusion, asymmetry will start to play against us again.

	Another tactic might be what I'm used to call "Embrace the chaos". In the context of this topic, it might be implemented by what I call "Drunk Wallets" or by what Nopara73 calls "Clusterfuck Wallets".
	In a nutshell, instead of trying to have all wallet implementations in sync with others implementations, let's try to have wallets generating random fingerprints.

	I don't think that such a tactic would solve all the challenges (especially regarding challenges related to temporal aspects of new features) but I believe that it may help to decrease the pressure put on wallet developer and to make the effort more sustainable on the long term (as in "better balance in the asymmetry of the game").

	To be honest, I don't even know if a "strong" cross-compatible implementation of Payjoin is a realistic goal. Perhaps it isn't possible but that raises a new question: Do we need a "strong" cross-compatible implementation of Payjoin?


	5/ Impacts of a "weak" cross-compatible implementation

	Note: The term "weak" used in this section isn't a judgment. It justs highlights the fact that all Payjoin implementations may not be equal and that a cross-compatible implementation may never provide the same guarantees as the ones provided by Payjoins between wallets using a same implementation.

	I think this is a very legit question. After all, as long as users are aware of the limitations and potential risks, a weak implementation of Payjoin may still provide positive outcomes.

	So, what can we realistically expect from a "weak" implementation of Payjoin?

	In my opinion, we shouldn't expect that the adoption of Payjoin will lead to the end of all CA platforms. I suspect that all CA platforms aren't made equals. Thus, I expect that adoption of Payjoin may lead to the end of a large number of less sophisticated actors and as a consequence to a concentration of the actors operating on this market (like 2 or 3 global companies).
	A likely consequence of this concentration is that it may strengthen the positions of these actors and put them in a better position to "negociate" with regulated businesses (as in "Hey Mr. Exchange! Share your data with us.").
	Obviously, in this context, A Payjoin used mostly for transfers between end-users and exchanges would achieve very little for Bitcoin fungibility.
	That leads me to think that an important objective for Payjoin is its adoption for payments between unregulated and non-identified actors (a.k.a end-users, DNM, etc) and not just between end-users and easily identifiaed actors.


	6/ Privacy BIPs

	Note: This point isn't specific to Payjoin.

	What should be the content of a "Privacy BIP" is still an open question for me.
	A huge challenge encountered by PETs is that all details matter. Get something wrong and what was supposed to be a solution becomes a new problem.
	Thus, the question is: How do we write "Privacy BIPs" that don't lead developers to implement solution doing more harm than good? Is there such a thing as a "Privacy BIP"?