From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: "Mr. Lee Chiffre" <lee.chiffre@secmail•pro>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Question about PayJoin effectiveness
Date: Wed, 10 Jun 2020 06:29:08 +0000 [thread overview]
Message-ID: <sjC0RVZr0Uyg5QKjgmAQfNibCUtaG-r_XEO8xDgPd7GIjLKSEybd47utANFWA53yySigMzqfiotpbCdFy-M5NcxJN1J6cCQO1r3sR1-eVks=@protonmail.com> (raw)
In-Reply-To: <7c0dc46538f96032596163c4a9f03dc2.squirrel@giyzk7o6dcunb2ry.onion>
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
next prev parent reply other threads:[~2020-06-10 6:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-10 4:01 Mr. Lee Chiffre
2020-06-10 6:29 ` ZmnSCPxj [this message]
2020-06-10 6:47 ` ZmnSCPxj
2020-06-10 17:49 ` Chris Belcher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='sjC0RVZr0Uyg5QKjgmAQfNibCUtaG-r_XEO8xDgPd7GIjLKSEybd47utANFWA53yySigMzqfiotpbCdFy-M5NcxJN1J6cCQO1r3sR1-eVks=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lee.chiffre@secmail$(echo .)pro \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox