Author

Topic: How efficient is the Payjoin protocol as far privacy is concerned? (Read 140 times)

member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
It'd be good to imagine Payjoin as a private payment to another person, and Coinjoin as a private payment to yourself. In the former, you send money elsewhere, whereas in the latter, you send them to yourself.

You can send elsewhere with other coinjoins, it's not required to send to yourself.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
It'd be good to imagine Payjoin as a private payment to another person, and Coinjoin as a private payment to yourself. In the former, you send money elsewhere, whereas in the latter, you send them to yourself.

The problem with Payjoins, as far as I understand, is interactivity. When paying for goods and services, it is not practical to interact with the merchant to make your coins more private. That rises the cost of the merchant for a service they might not be willing to provide.
copper member
Activity: 900
Merit: 2243
Quote
I will appreciate how the actual transaction are displayed on transaction history.
Let's see:
Code:
+----------------------------------+
| Alice 5.00 BTC -> Bob#2 6.00 BTC |
| Bob#1 7.00 BTC    Bob#3 6.00 BTC |
+----------------------------------+
If Bob will avoid address reuse, then outside observer will see:
Code:
+------------------------------------+
| Alice 5.00 BTC -> Charlie 6.00 BTC |
| Bob   7.00 BTC    Daniel  6.00 BTC |
+------------------------------------+

Quote
How efficient is the Payjoin protocol compare to Coinjoin?
Example CoinJoin: https://blockchair.com/bitcoin/privacy-o-meter/69d9d66aae4812b6cf156f32267b773fb2118db696bb847ebd3454a198b59fbd

As you can see, if some tool does not know about this forum topic, it may assume, that gmaxwell had 40k BTC, and sent it to someone else.

However, you never know, if it was only a CoinJoin, or maybe also a PayJoin.

Quote
Aside tx fees, are there other fees involved in using this protocol(Payjoin)?
It depends, how your transaction is created. For example, it is also possible to start from the recipient, create a PSBT, where some dust is spent to some output, with some given amount, and then it can be signed with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, so that anyone could be a sender, without invalidating signatures. In this way, you start from some "negative fee transaction", and the sender is simply attaching some inputs, to make them non-negative.

Also, in case of the first example above: Alice could just send to Bob this transaction, signed with proper sighashes:
Code:
+----------------------------------+
| Alice 5.00 BTC -> Bob#2 6.00 BTC |
+----------------------------------+
And then, Bob could attach more inputs and outputs, to make the transaction from above, by signing everything with SIGHASH_ALL. And then, nobody would know, if Bob received 5 BTC, or maybe 6 BTC, or maybe Alice received 1 BTC from Bob. Outside observers will only see this:
Code:
+------------------------------------+
| Alice 5.00 BTC -> Charlie 6.00 BTC |
| Bob   7.00 BTC    Daniel  6.00 BTC |
+------------------------------------+
And the situation is even more complicated, when you have Schnorr signatures, and you don't know, if behind some Alice's address is actually only Alice, or maybe some 3-of-3 multisig, combined into a single signature.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
I want to assume that: If the transaction history of the sender is properly examined, 5btc should be a sent amount, but while examining the receiver's address, 6btc would be seen as received amount.

1. The last paragraph written in italics, after the image was based on my assumption with uncertainty. I will appreciate how the actual transaction are displayed on transaction history.

Your assumptions are not quite correct. If the receiver has a 7 BTC input and the sender is spending 5 BTC, then the receiver will create a single 12 BTC output. The receiver will not split their 7 BTC input into smaller coins first.

2. How efficient is the Payjoin protocol compare to Coinjoin?.

Payjoins are more fee efficient than any other on chain transaction and create overlapping transaction histories as a privacy bonus. However, regular equal-output coinjoins can contain many more than just 2 participants, so if the goal is to maximize privacy, then other coinjoins with enough liquidity can be more cost efficienct.

3. Aside tx fees, are there other fees involved in using this protocol(Payjoin)?.

No  Grin
full member
Activity: 168
Merit: 138
cout << "Bitcoin";
From the legal perspective that governs a state, we might say that everyone is entitled to privacy both offline and online, but trust me when I say that the privacy of the majority is doomed. The financial sector has been a major area where surveillance and easy monitoring can be achieved, as everyone makes use of money in one way or the other.

Bitcoin which is a digital form of money has literally change some of the default settings operated by centralized institutions. Bitcoin transactions are pseudonymous, which means these transactions can be monitored through addresses or public keys, but the real world identity of the receiver or sender is never visible, except there is a trace to a centralize entity(exchange). Chain analysis is a practical Method which government agencies or other users use in monitoring Bitcoin transactions. A common example of such tool that gives such analysis is found on oxt.me, but the site is currently unavailable as at the time of this writing.

Common Input Heuristic has been a common practice use in detecting owners of a particular transaction, which is based on assumption that all given input from a single transaction are owned by one person. Well, these practice as not been too effective Since the implementation of Coinjoin. According to ACHOW101, he suggested that Coinjoin were designed to break heuristic.

Strategies such as CoinJoin are designed to break this heuristic by having multiple people provide inputs to the transaction.

Coinjoin which aim is to increase privacy for Bitcoin users thereby collecting multiple inputs from multiple users, process it as a single input before distributing it out as a multiple output to corresponding addresses of destination. When some of these transactions are observed on the Blockchain, they are often seen as a very massive transaction input, which ends up as separated output in smaller amounts, but leaving it with a difficulty to trace where they originated from.

The drawn image below represents a typical example of a Coinjoin transaction. There are 3 different users who are joining their UTXOs to form a single Input, which are then received at the later end to the corresponding address. Though, there are several procedures to achieving this.



Protocol of major concern

So recently, while learning more Bitcoin related terminologies, I came across what the Bitcoin community call PayJoin, which also breaks heuristic just like Coinjoin, but involves the sender and receiver this time.

Payjoin which is also called Pay to Endpoint(P2EP). This protocol allows the sender and receiver to manipulate a transaction in such a way that the UTXO used as input is not equal to that of the output. From a rough perspective which I understood, The sender creates a partially signed transaction, and pass it to the receiver to put additional input. The sender then finalize the entire transaction by inputting the amount he/she owes before broadcasting to the entire network.

Below is a drawn image that explains this concept to the best of what I have learnt so far. The example involves a sender who attempts to send an amount of 5btc to someone. in this scenario, we need to assume that the receiver already have a balance of 7btc. inorder for both of them to use the Payjoin protocol, the sender simply creates a partially signed transaction just as I have mentioned before. The receiver then Inputs an amount, let say 1btc. Then the sender input his/her own amount to be sent(5btc) before broadcasting.


I want to assume that: If the transaction history of the sender is properly examined, 5btc should be a sent amount, but while examining the receiver's address, 6btc would be seen as received amount.


My question:
1. The last paragraph written in italics, after the image was based on my assumption with uncertainty. I will appreciate how the actual transaction are displayed on transaction history.
2. How efficient is the Payjoin protocol compare to Coinjoin?.
3. Aside tx fees, are there other fees involved in using this protocol(Payjoin)?.



I am 100% open to correction as I still see myself as a learner. Pardon any of my error and share your personal opinion. You might want to also DYOR after reading this.
Jump to: