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
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jim@ergophobia.org>) id 1YrAQd-00023A-1O
for bitcoin-development@lists.sourceforge.net;
Sat, 09 May 2015 19:28:51 +0000
X-ACL-Warn:
Received: from mail-wi0-f172.google.com ([209.85.212.172])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YrAQa-0003Jh-Qf
for bitcoin-development@lists.sourceforge.net;
Sat, 09 May 2015 19:28:51 +0000
Received: by wief7 with SMTP id f7so58200615wie.0
for <bitcoin-development@lists.sourceforge.net>;
Sat, 09 May 2015 12:28:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:content-type;
bh=TVwJ5XZrUGI4AEcXZBP6MUYhF7OaviLdPU3k4tcfark=;
b=P1DAOwMt+1Qq5zgUad+5qLifWdsMWE3AuXE7hPyKoKsIKGVWqehTmmflRJJcWUJS13
3bcoVVgxFSEMpZJm5kSk6XVhb/r8j40qzd92qaJpSbY65Q7zBrZehu4SDHyy/Qlb3IYk
9GqgjI2jrZHz0KG5mEyULGlwtQIRWcZBWb2vVPkDNSEquAWvJVIsi9eubWrbVxKomOOF
mKBstUC3QdSI7iFmkjPZARxmQb0GwxAr8ozRfSt3iR/Urug2zPaERQigPdCt6AIIGLlX
nXVIXd6lkDevxpA8DWdm4yS+3piV4tjuSQ3FxbBKEchZ5omsFnr8pONvSffS7+Dbg1E+
Qw3g==
X-Gm-Message-State: ALoCoQlvdkFjOiLbVWBlYWQRggZIfLSQ7CxV4rv8KBdIVNkaQsntErxPm8p+OZvP/XjzADglYzC0
X-Received: by 10.194.157.194 with SMTP id wo2mr6983754wjb.103.1431199722852;
Sat, 09 May 2015 12:28:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.246.69 with HTTP; Sat, 9 May 2015 12:28:12 -0700 (PDT)
In-Reply-To: <8029969D-FD22-43F7-930D-CEC7A87CEAD5@newcastle.ac.uk>
References: <CANe1mWzBy8-C+CWfwaOLxJ2wokjy8ytQUh2TkRY_Ummn1BpPzw@mail.gmail.com>
<3862E01F-FD0F-48F5-A6D9-F8E0FB0AB68F@newcastle.ac.uk>
<CANe1mWys1gAO1CgPEpD7rdtXF2KYfvXA6bc0q-rAzg9xOFc-5A@mail.gmail.com>
<8029969D-FD22-43F7-930D-CEC7A87CEAD5@newcastle.ac.uk>
From: Jim Phillips <jim@ergophobia.org>
Date: Sat, 9 May 2015 14:28:12 -0500
Message-ID: <CANe1mWzxH9dwiAwZz2gEybWG03-87Ti65xV+SyFyC0KLuk+BAg@mail.gmail.com>
To: "Patrick Mccorry (PGR)" <patrick.mccorry@newcastle.ac.uk>,
bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=089e013c673c156af30515ab2797
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YrAQa-0003Jh-Qf
Subject: Re: [Bitcoin-development] A suggestion for reducing the size of the
UTXO database
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 09 May 2015 19:28:51 -0000
--089e013c673c156af30515ab2797
Content-Type: text/plain; charset=UTF-8
On Sat, May 9, 2015 at 2:12 PM, Patrick Mccorry (PGR) <
patrick.mccorry@newcastle.ac.uk> wrote:
> Not necessarily. If you want to ensure privacy, you could limit the
> selection of UTXOs to a single address, and even go so far as to send
> change back to that same address. This wouldn't be as effective as
> combining the UTXOs from multiple addresses, but it would help. The key is
> to do everything that can be done when building a transaction to ensure
> that as many inputs as possible are consolidated into as few outputs as
> possible.
>
>
> I would agree if you have multiple utxo for a single address then it
> makes sense since there is no privacy loss. However sending the change back
> to the same address would damage privacy (Hive does this) as it is then
> obvious from looking at the transaction which output is change and which
> output is sending funds.
>
I tend to agree with you here. But the change output could just as easily
be sent to a new change address.
> Also not everyone is concerned with their own privacy, and I'm not aware
> of any HD-wallet implementations that won't already combine inputs from
> multiple addresses within that wallet without user input.
>
>
> For people who do not care for privacy then it would work fine. But
> adding it into the wallet as default behaviour would deter those who do
> care for privacy - and making it a customisable option just adds complexity
> for the users. Wallets do need to combine utxo at times to spend bitcoins
> which is how people can be tracked today, using the minimum set of utxo
> tries to reduce the risk.
>
> Different wallets are targeted at different demographics. Some are geared
towards more mainstream users (for whom the privacy issue is less a
concern) and some (such as DarkWallet) are geared more towards the privacy
advocates. These wallets may choose to set their defaults at oposite ends
of the spectrum as to how they choose to select and link addresses and
UTXOs, but they can all improve on their current algorithms and promote
some degree of consolidation.
> Additionally, large wallets that have lots of addresses owned by
> multiple users like exchanges, blockchain.info, and Coinbase can
> consolidate UTXOs very effectively when building transactions
>
>
> That's true - I'm not sure how they would feel about it though. I
> imagine they probably are already to minimise key management.
>
> That's what these discussions are for. Hopefully this thread will be seen
by developers of these wallets and give them something to consider.
>
--089e013c673c156af30515ab2797
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, May 9, 2015 at 2:12 PM, Patrick Mccorry (PGR) <span dir=3D"ltr"><<a =
href=3D"mailto:patrick.mccorry@newcastle.ac.uk" target=3D"_blank">patrick.m=
ccorry@newcastle.ac.uk</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<div dir=3D"auto">
<div><span class=3D"">
<blockquote type=3D"cite">
<div dir=3D"ltr"><font color=3D"#000000"><span style=3D"background-color:rg=
ba(255,255,255,0)">Not necessarily. If you want to ensure privacy, you coul=
d limit the selection of UTXOs to a single address, and even go so far as t=
o send change back to that same address.
This wouldn't be as effective as combining the UTXOs from multiple add=
resses, but it would help. The key is to do everything that can be done whe=
n building a transaction to ensure that as many inputs as possible are cons=
olidated into as few outputs as possible.
=C2=A0</span></font></div>
</blockquote>
<div><br>
</div></span>
I would agree if you have multiple utxo for a single address then it makes =
sense since there is no privacy loss. However sending the change back to th=
e same address would damage privacy (Hive does this) as it is then obvious =
from looking at the transaction
which output is change and which output is sending funds.=C2=A0</div></div=
></blockquote><div><br></div><div>I tend to agree with you here. But the ch=
ange output could just as easily be sent to a new change address.=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div><span class=3D""><b=
lockquote type=3D"cite"><div dir=3D"ltr"><font color=3D"#000000"><span styl=
e=3D"background-color:rgba(255,255,255,0)">=C2=A0Also not everyone is conce=
rned with their own privacy, and I'm not aware of any HD-wallet impleme=
ntations that won't already combine inputs from multiple addresses
within that wallet without user input.</span></font></div>
</blockquote>
<blockquote type=3D"cite">
<div dir=3D"ltr"></div>
</blockquote>
<div><br>
</div>
</span><div>For people who do not care for privacy then it would work fine.=
But adding it into the wallet as default behaviour would deter those who d=
o care for privacy - and making it a customisable option just adds complexi=
ty for the users. Wallets do need to combine
utxo at times to spend bitcoins which is how people can be tracked today, =
using the minimum set of utxo tries to reduce the risk.=C2=A0</div><span cl=
ass=3D"">
<div><br></div></span></div></div></blockquote><div>Different wallets are t=
argeted at different demographics. Some are geared towards more mainstream =
users (for whom the privacy issue is less a concern) and some (such as Dark=
Wallet) are geared more towards the privacy advocates. These wallets may ch=
oose to set their defaults at oposite ends of the spectrum as to how they c=
hoose to select and link addresses and UTXOs, but they can all improve on t=
heir current algorithms and promote some degree of consolidation.=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div><span class=3D""><d=
iv>
</div>
<div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><font color=3D"#000000"><span style=3D"background-color:rg=
ba(255,255,255,0)">Additionally, large wallets that have lots of addresses =
owned by multiple users like exchanges,=C2=A0<a href=3D"http://blockchain.i=
nfo" target=3D"_blank">blockchain.info</a>, and Coinbase can
consolidate UTXOs very effectively when building transactions</span></font=
></div>
</blockquote>
<br>
</div>
</span><div>That's true - I'm not sure how they would feel about it=
though. I imagine they probably are already to minimise key management.=C2=
=A0</div><span class=3D"">
<div><br></div></span></div></div></blockquote><div>That's what these d=
iscussions are for. Hopefully this thread will be seen by developers of the=
se wallets and give them something to consider.=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"auto"><div><span class=3D""><div>
</div>
</span></div></div></blockquote></div><br></div></div>
--089e013c673c156af30515ab2797--
|
