public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Kenshiro []" <tensiam@hotmail•com>
To: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	"rhavar@protonmail•com" <rhavar@protonmail•com>
Subject: Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction
Date: Fri, 22 Mar 2019 11:15:26 +0000	[thread overview]
Message-ID: <DB6PR10MB1832FFFFD06F26525522E826A6430@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <DB6PR10MB1832829D9C812F50C66BD11CA6430@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>

[-- Attachment #1: Type: text/plain, Size: 4287 bytes --]

They Payjoin protocol could include the possibility of receive "safe" amounts (i.e.: 0.025 btc) to several addresses so every user using Payjoin already have a splitted balance. Only people receiving a regular public transaction should need the extra splitting transaction.

Regards

________________________________
From: Kenshiro []
Sent: Friday, March 22, 2019 11:23
To: Bitcoin Protocol Discussion; rhavar@protonmail•com
Subject: Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction

>I'm not really sure the problem you're describing, but it sounds like something that affects normal bitcoin transactions as well.

Yeah, it affects normal transactions too. But I'm focused in Payjoin because it should allow private transactions. The problem I see is that Payjoin shouldn't allow that the sender or the receiver of the transaction can get information about the bitcoin balance of each other. A person could have his savings in btc in a single address, use Payjoin to send/receive a payment thinking it's private and leaking to the receptor he has a high amount of btc. But an automatic splitting to itself in the background could solve the problem (maybe 100$ amounts) or so.

>There's certainly some interesting about the idea of "pre-fragmenting" your wallet utxo so you can make (or in payjoin: receive) payments with better privacy aspects.However, it's pretty unlikely to be practical for normal users, as it'll generally result in pretty big and cost-ineffective transactions.

For users that really want privacy it should not be a problem. When a wallet receive a high amount of btc (+100$ or another amount defined by the user) it can automatically make a transaction to itself splitting the amount in several addresses. The amounts that are already small don't need to be splitted again. Small amount addresses + Payjoin could give real privacy to bitcoin users. Users that don't want privacy could disable the "Private" mode in the wallet and disable the auto-splitting feature.

i.e.: you receive 1000$ in btc and the wallet make an automatic transaction to itself to 10 addresses, 100$ each.

I would prefer wait some time and have privacy than the opposite.

Regards

________________________________
From: rhavar@protonmail•com <rhavar@protonmail•com>
Sent: Thursday, March 21, 2019 17:52
To: Kenshiro \[\]; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction

I'm not really sure the problem you're describing, but it sounds like something that affects normal bitcoin transactions as well.

There's certainly some interesting about the idea of "pre-fragmenting" your wallet utxo so you can make (or in payjoin: receive) payments with better privacy aspects.However, it's pretty unlikely to be practical for normal users, as it'll generally result in pretty big and cost-ineffective transactions.

In general though, there's like a 1000 different things you can do with coin selection, utxo management (and payjoin contributed input selection) but more often than not you are just making just making 1 trade off for another and good solutions will be wildly different depending on how you use your wallet.


-Ryan


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, March 18, 2019 3:55 AM, Kenshiro \[\] via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:

Hi,

I think Payjoin can be a very good privacy solution for Bitcoin, but I have a question about it:

- If a user has 1 BTC in a single address and make a payjoin payment to other person of 0.1 BTC using that address as input, the other person can see in a blockchain explorer the change address with an amount of 0.9 BTC. That's a serious privacy leak. I would like to know what will be the standard solution to this issue. An easy fix could be that the user wallet check if any address contains a BTC amount higher than a "safe" amount like 0.01 BTC or less. If some address exceed that amount the wallet could automatically make 1 payment to itself to split the amount in several addresses. In this way nobody receiving a payment from a user will ever know that he has a bitcoin balance higher than the "safe" amount.

What do you think?

Regards,


[-- Attachment #2: Type: text/html, Size: 7465 bytes --]

  reply	other threads:[~2019-03-22 11:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-18 10:55 Kenshiro []
2019-03-21 16:52 ` rhavar
2019-03-22 10:23   ` Kenshiro []
2019-03-22 11:15     ` Kenshiro [] [this message]
2019-03-22 16:05     ` ZmnSCPxj

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=DB6PR10MB1832FFFFD06F26525522E826A6430@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM \
    --to=tensiam@hotmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=rhavar@protonmail$(echo .)com \
    /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