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

Good morning,

> >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.
>

It seems to me, to interact somewhat with ZeroLink.

Under ZeroLink, post-mix UTXOs must not be combined.
(Basic Post-Mix Wallet Requirement: "Post-mix wallet MUST prevent joining inputs together.")

The upshot of this, for practical use, is that as payments are done by the user, available coins become smaller and smaller.
And the maximum amount the user can pay with, is limited by the largest post-mix coin they have.

If a ZeroLink post-mix wallet were to split its UTXOs as soon as it got them from the mix, then it would immediately find itself limiting the maximum amount the user could pay.
I suppose if the ZeroLink post-mix wallet had multiple post-mix coins, it could split one of them for the same purpose as above.

Another thought, is if a ZeroLink post-mix wallet could support a Payjoin, as either receiver or sender.
Naively, it seems to me to improve privacy to do so, as long as the ZeroLink post-mix wallet only provides a single UTXO to the Payjoin, whether as receiver or sender.
For a ZeroLink post-mix wallet to a ZeroLink post-mix wallet Payjoin, this would typically result in a two-input, two-output transaction, with both participants having one input and one output each in the transaction, but difficult (?) for third parties to determine which input/output belongs to which.

Now, if we suppose that both ZeroLink and Payjoin become commonly used, then it is likely that two users using the same Chaumian CoinJoin mix transaction will find that one needs to pay the other.
Thus hopefully it may become common for a Chaumian CoinJoin mix transaction to have outputs that (directly or indirectly) merge into Payjoin two-input two-output transactions.
This can then be used to allow a ZeroLink post-mix wallet some limited amount of merging its post-mix UTXOs.
For instance, if a ZeroLink post-mix wallet has a 0.25BTC and a 0.15BTC coin, and needs to pay 0.3 BTC, it may very well simulate a Payjoin to itself, and create a transaction (0.25, 0.15) -> (0.35, 0.05).
Then it can use the 0.35BTC output to pay the 0.3 BTC.

Possibly, anyway.

Regards,
ZmnSCPxj


      parent reply	other threads:[~2019-03-22 16:05 UTC|newest]

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

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='8lijztpZXhFjjVzlRV1LGtSulNfgYNiZzRmzpO7epoZRjwswnAtqne9TsEpGOqNxL6NTTH-G4xUrusKRjG-Rl7Y5cAOCtvEXiC5QDbWne7U=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=tensiam@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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