1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2A30D19EA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Mar 2019 16:05:21 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
[185.70.40.133])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3EECB91A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Mar 2019 16:05:20 +0000 (UTC)
Date: Fri, 22 Mar 2019 16:05:13 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1553270717;
bh=0ETG1HYJ3FaNm4GED54Z7GU+C7XR7mkhXXCWDQevsYE=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=cU0870ZGrCEwYtYFJJL8DOib37lUbzdhkX4g3x/8rk17t6hy929EZws66ufwK9j4T
wkSYd7Lhx7JC9NFYg0etIlknVWNa7HRSEKKcWiH1W/5LYTkdOJkwnNxlYfeUqveG6j
nd1QzLMlIX0hIf9Fy0jL9LATmf/rhEnhLkSfUc9Q=
To: "Kenshiro \\[\\]" <tensiam@hotmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <8lijztpZXhFjjVzlRV1LGtSulNfgYNiZzRmzpO7epoZRjwswnAtqne9TsEpGOqNxL6NTTH-G4xUrusKRjG-Rl7Y5cAOCtvEXiC5QDbWne7U=@protonmail.com>
In-Reply-To: <DB6PR10MB1832829D9C812F50C66BD11CA6430@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB1832253A8D022C4A91573D49A6470@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
<LUvvLGfixy2VQURUSkwxavfcxnQeLsUGvjm3o9iKW6EPOj0HIEeIlyhTUVIvaTcL_9NAY8k7CizkoKvSrQMq8b9fjDwxSzFvuAisboJ5jkQ=@protonmail.com>
<DB6PR10MB1832829D9C812F50C66BD11CA6430@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 22 Mar 2019 17:09:35 +0000
Subject: Re: [bitcoin-dev] Payjoin privacy with the receiver of the
transaction
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2019 16:05:21 -0000
Good morning,
> >There's certainly some interesting about the idea of "pre-fragmenting" y=
our wallet utxo so you can make (or in payjoin: receive) payments with bett=
er privacy aspects.However, it's pretty unlikely to be practical for normal=
users, as it'll generally result in pretty big and cost-ineffective transa=
ctions.
>
> For users that really want privacy it should not be a problem. When a wal=
let receive a high amount of btc (+100$ or another amount defined by the us=
er) 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 s=
plitted again. Small amount addresses + Payjoin could give real privacy to =
bitcoin users. Users that don't want privacy could disable the "Private" mo=
de in the wallet and disable the auto-splitting feature.=C2=A0
>
> i.e.: you receive 1000$ in btc and the wallet make an automatic transacti=
on 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 i=
nputs 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 pos=
t-mix coin they have.
If a ZeroLink post-mix wallet were to split its UTXOs as soon as it got the=
m 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 c=
ould 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 ZeroLin=
k post-mix wallet only provides a single UTXO to the Payjoin, whether as re=
ceiver 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 pa=
rticipants having one input and one output each in the transaction, but dif=
ficult (?) for third parties to determine which input/output belongs to whi=
ch.
Now, if we suppose that both ZeroLink and Payjoin become commonly used, the=
n it is likely that two users using the same Chaumian CoinJoin mix transact=
ion 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 amou=
nt of merging its post-mix UTXOs.
For instance, if a ZeroLink post-mix wallet has a 0.25BTC and a 0.15BTC coi=
n, 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
|
