public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Question about PayJoin effectiveness
@ 2020-06-10  4:01 Mr. Lee Chiffre
  2020-06-10  6:29 ` ZmnSCPxj
  2020-06-10 17:49 ` Chris Belcher
  0 siblings, 2 replies; 4+ messages in thread
From: Mr. Lee Chiffre @ 2020-06-10  4:01 UTC (permalink / raw)
  To: bitcoin-dev

I am trying to learn about payjoin. I have a couple concerns on its
effectiveness. Are my concerns valid or am I missing something?

concern 1
If it is known to be a payjoin transaction anyone could determine the
sender the recipient and amount right?

Lets assume that everyone has a single utxo because payjoin becomes common
use and payjoin consolidates utxos through "snowballing". If Alice has a
UTXO of 0.05 btc and Bob has a UTXO of 1.15 btc. Bob can be assumed to
have more balance because he is a merchant and his customers payjoin him
payments alot.

If Alice and Bob do a payjoin with Alice paying 0.01 btc to Bob, it would
probably look like this right?

 0.05---> |____---->1.16
 1.15---> |    ---->0.04

It is very obvious here the amount sent and the sender.  Even if Alice did
combine another input it would still be very obvious. In this case Alice
has another utxo with 0.4 BTC

 0.40---> |
 0.05---> |____---->1.16
 1.15---> |    ---->0.44

This is still obvious that Alice paid Bob 0.01 BTC isn't it?



concern 2
If there is just one consolidated utxo after each payjoin, would it  be
easy to break the privacy of transaction chains?

Alice---payjoin--->Bob
Clark---payjoin--->Bob

or

Alice---payjoin--->Bob---payjoin--->Clark

For exmaple, lets say that Alice payjoins to Bob. Then later on Clark
payjoins with Bob. Based on the payjoin between Clark and Bob, Clark now
knows what UTXO was actually Bob's. And can then know which one was
actually Alices. By transacting a payjoin with someone, they could decloak
the payjoins before them right? If so, how far back the chain can they go?

The issue is not that someone knows the utxos of themselves and the entity
they payjoined with. The issue is that someone can figure out the payjoins
of others before them with the same entity.


I surely must be missing something here. What am I not understanding?

-- 
lee.chiffre@secmail•pro
PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35










^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [bitcoin-dev] Question about PayJoin effectiveness
  2020-06-10  4:01 [bitcoin-dev] Question about PayJoin effectiveness Mr. Lee Chiffre
@ 2020-06-10  6:29 ` ZmnSCPxj
  2020-06-10  6:47   ` ZmnSCPxj
  2020-06-10 17:49 ` Chris Belcher
  1 sibling, 1 reply; 4+ messages in thread
From: ZmnSCPxj @ 2020-06-10  6:29 UTC (permalink / raw)
  To: Mr. Lee Chiffre, Bitcoin Protocol Discussion


Good morning Mr. Lee,

> I am trying to learn about payjoin. I have a couple concerns on its
> effectiveness. Are my concerns valid or am I missing something?
>
> concern 1
> If it is known to be a payjoin transaction anyone could determine the
> sender the recipient and amount right?
>
> Lets assume that everyone has a single utxo because payjoin becomes common
> use and payjoin consolidates utxos through "snowballing". If Alice has a
> UTXO of 0.05 btc and Bob has a UTXO of 1.15 btc. Bob can be assumed to
> have more balance because he is a merchant and his customers payjoin him
> payments alot.
>
> If Alice and Bob do a payjoin with Alice paying 0.01 btc to Bob, it would
> probably look like this right?
>
> 0.05---> |____---->1.16
> 1.15---> | ---->0.04


There are multiple interpretations:

* The 0.05 owner is paying the 1.15 owner 0.01 BTC.
* The 1.15 owner is paying the 0.05 owner 1.11 BTC.
* The 0.05 + 1.15 owner is paying an independent user 1.16 BTC using a non-PayJoin transaction (because for example the payee currently has no coins, i.e. a new user).

It is this fact of multiple interpretations that is what PayJoin buys you in practice.

You could argue that paying 0.01 is more likely than paying 1.11 or 1.16, but that still does not give you 100% assurance --- the creators of the transaction are still getting the `100% - probability_of_paying_0.01` benefit, and reducing UTXO set size as well.

Your assertion that this is "very obvious" only exists because you already know that Alice is paying 0.01 to Bob, but that is in fact the very thing that is being obscured here.


>
> It is very obvious here the amount sent and the sender. Even if Alice did
> combine another input it would still be very obvious. In this case Alice
> has another utxo with 0.4 BTC
>
> 0.40---> |
> 0.05---> |____---->1.16
> 1.15---> | ---->0.44


This can be interpreted as well multiple ways:

* 0.05 + 1.15 is the same owner who wants to merge coins, and is paying the 0.40 owner 0.04 BTC.
* 0.40 + 1.15 is the same owner who wants to merge coins, and is paying the 0.05 owner 0.39 BTC.
* 0.40 + 0.05 is the same owner who wants to merge coins, and is paying the 1.15 owner 0.01 BTC.

You should probably be shuffling the inputs and outputs, or using BIP39 consistently, so that inputs and outputs do not correlate (i.e. do not necessarily group together all of Alice inputs).


>
> This is still obvious that Alice paid Bob 0.01 BTC isn't it?
>
> concern 2
> If there is just one consolidated utxo after each payjoin, would it be
> easy to break the privacy of transaction chains?
>
> Alice---payjoin--->Bob
> Clark---payjoin--->Bob
>
> or
>
> Alice---payjoin--->Bob---payjoin--->Clark
>
> For exmaple, lets say that Alice payjoins to Bob. Then later on Clark
> payjoins with Bob. Based on the payjoin between Clark and Bob, Clark now
> knows what UTXO was actually Bob's. And can then know which one was
> actually Alices. By transacting a payjoin with someone, they could decloak
> the payjoins before them right? If so, how far back the chain can they go?
>
> The issue is not that someone knows the utxos of themselves and the entity
> they payjoined with. The issue is that someone can figure out the payjoins
> of others before them with the same entity.

If Clark can hack Alice (even just read-only access to Alice logs), they can go by one more transaction.

If Clark cannot hack Alice, then that is the sole extent Clark knows: Clark know that Bob transacted with somebody for a resulting N BTC (which is relatively uninteresting, obviously somebody who uses BTC is going to be transacting with random BTC users in BTC), without being sure that Bob was the payer or the payee in that situation.

Regards,
ZmnSCPxj


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [bitcoin-dev] Question about PayJoin effectiveness
  2020-06-10  6:29 ` ZmnSCPxj
@ 2020-06-10  6:47   ` ZmnSCPxj
  0 siblings, 0 replies; 4+ messages in thread
From: ZmnSCPxj @ 2020-06-10  6:47 UTC (permalink / raw)
  To: ZmnSCPxj, Bitcoin Protocol Discussion

Good morning again Mr. Lee,

> > I am trying to learn about payjoin. I have a couple concerns on its
> > effectiveness. Are my concerns valid or am I missing something?
> > concern 1
> > If it is known to be a payjoin transaction anyone could determine the
> > sender the recipient and amount right?
> > Lets assume that everyone has a single utxo because payjoin becomes common
> > use and payjoin consolidates utxos through "snowballing". If Alice has a
> > UTXO of 0.05 btc and Bob has a UTXO of 1.15 btc. Bob can be assumed to
> > have more balance because he is a merchant and his customers payjoin him
> > payments alot.


It is also helpful to remember that Bob cannot exist in isolation, and therefore, Bob probably has:

* Employees.
* Suppliers.
* Shareholders.

For example, suppose Bob holds in reserve a 0.05 BTC UTXO in a holding wallet.

Then Bob takes the 1.16 UTXO it got from Alice and transfers 1.12 BTC to the holding wallet:

    Bob merchant wallet 1.16 --___-- 1.17 Bob holding wallet
    Bob holding wallet  0.05 --   -- 0.04 Bob merchant wallet

The above looks exactly like one of the "customer pays Bob" transactions, but is in fact different.

Then Bob uses the holding wallet to pay out to employees, suppliers, and shareholders, such as in a single large batched transaction, and then leaves behind another 0.05 BTC in the holding wallet (or some random small number of BTC) for the next time Bob has to pay to employees/suppliers/shareholders.

So the transaction below:

    1.16 --___-- 1.17
    0.05 --   -- 0.04

*could* be interpreted as the 0.05 owner paying to the 1.16 owner, but in fact that is just Bob preparing the incoming funds from the merchant front-end for processing to send to its own liabilities.

Regards,
ZmnSCPxj


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [bitcoin-dev] Question about PayJoin effectiveness
  2020-06-10  4:01 [bitcoin-dev] Question about PayJoin effectiveness Mr. Lee Chiffre
  2020-06-10  6:29 ` ZmnSCPxj
@ 2020-06-10 17:49 ` Chris Belcher
  1 sibling, 0 replies; 4+ messages in thread
From: Chris Belcher @ 2020-06-10 17:49 UTC (permalink / raw)
  To: bitcoin-dev

On 10/06/2020 05:01, Mr. Lee Chiffre via bitcoin-dev wrote:
> I am trying to learn about payjoin. I have a couple concerns on its
> effectiveness. Are my concerns valid or am I missing something?
> 
> concern 1
> If it is known to be a payjoin transaction anyone could determine the
> sender the recipient and amount right?
> 
> Lets assume that everyone has a single utxo because payjoin becomes common
> use and payjoin consolidates utxos through "snowballing". If Alice has a
> UTXO of 0.05 btc and Bob has a UTXO of 1.15 btc. Bob can be assumed to
> have more balance because he is a merchant and his customers payjoin him
> payments alot.
> 
> If Alice and Bob do a payjoin with Alice paying 0.01 btc to Bob, it would
> probably look like this right?
> 
>  0.05---> |____---->1.16
>  1.15---> |    ---->0.04
> 
> It is very obvious here the amount sent and the sender.  Even if Alice did
> combine another input it would still be very obvious. In this case Alice
> has another utxo with 0.4 BTC
> 
>  0.40---> |
>  0.05---> |____---->1.16
>  1.15---> |    ---->0.44
> 
> This is still obvious that Alice paid Bob 0.01 BTC isn't it?
> 
> 
> 
> concern 2
> If there is just one consolidated utxo after each payjoin, would it  be
> easy to break the privacy of transaction chains?
> 
> Alice---payjoin--->Bob
> Clark---payjoin--->Bob
> 
> or
> 
> Alice---payjoin--->Bob---payjoin--->Clark
> 
> For exmaple, lets say that Alice payjoins to Bob. Then later on Clark
> payjoins with Bob. Based on the payjoin between Clark and Bob, Clark now
> knows what UTXO was actually Bob's. And can then know which one was
> actually Alices. By transacting a payjoin with someone, they could decloak
> the payjoins before them right? If so, how far back the chain can they go?
> 
> The issue is not that someone knows the utxos of themselves and the entity
> they payjoined with. The issue is that someone can figure out the payjoins
> of others before them with the same entity.
> 
> 
> I surely must be missing something here. What am I not understanding?
> 

Adding to what other people have written, it's an important point that
PayJoin breaks the common-input-ownership heuristic. I.E. if PayJoins
become even moderately popular then it will no longer be a safe
assumption that all the inputs to a transaction are owned by the same
entity (taking away all the obvious breaks like equal-output-coinjoins).

This assumption is a huge reason why blockchain surveillance is so
effective. A good paper on that is here:
https://arxiv.org/abs/1605.06369 (The Unreasonable Effectiveness of
Address Clustering Harrigan, Martin & Fretter, Christoph. (2016))

The assumption is mentioned by Satoshi in the whitepaper where he
laments that the privacy loss is unavoidable. (One of the few outright
errors in the paper, perhaps the only error). The fact that we have
technology to break this assumption is a massive deal, and that's a big
value-add of PayJoin.



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-06-10 17:49 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-10  4:01 [bitcoin-dev] Question about PayJoin effectiveness Mr. Lee Chiffre
2020-06-10  6:29 ` ZmnSCPxj
2020-06-10  6:47   ` ZmnSCPxj
2020-06-10 17:49 ` Chris Belcher

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox