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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam.back@gmail.com>) id 1UZkPQ-000440-TR
for bitcoin-development@lists.sourceforge.net;
Tue, 07 May 2013 16:06:32 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.83.43 as permitted sender)
client-ip=74.125.83.43; envelope-from=adam.back@gmail.com;
helo=mail-ee0-f43.google.com;
Received: from mail-ee0-f43.google.com ([74.125.83.43])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UZkPN-0006AA-4z
for bitcoin-development@lists.sourceforge.net;
Tue, 07 May 2013 16:06:32 +0000
Received: by mail-ee0-f43.google.com with SMTP id b15so416307eek.30
for <bitcoin-development@lists.sourceforge.net>;
Tue, 07 May 2013 09:06:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=x-received:date:from:to:cc:subject:message-id:references
:mime-version:content-type:content-disposition:in-reply-to
:user-agent:x-hashcash:x-hashcash:x-hashcash;
bh=OktyJ9Bt71SR0aP8USfXWQAFy4us1jPhU0jMmdggf9w=;
b=VZcRfVutsI06izON/awNTo9veUAMYib9QCpkMsMo+gt6nxqOfDOk2DoSyYfPflIipA
+1/UiI5AsC/S0hiS7OyUdTHP6lFlUE3noHmPnKvRgqlQzxKfCENXWpCYKIUBBB8QHXU7
CoCjBkSV8q/75yJO/3f72Qj+G2QM+ABKCbpSAoaUSkGCzjDVqlf/AwBKQZrCY8B+5KEd
45e8MWhk5vfgyWgBcv1Yu5Hjt9BGdyhnL6E5EC6DRS9wY63AGib/YD39h+lpera+GvD3
TZIaPkUBPokgs0BC11aEvCmQLWly6Xj5tarreUXnfV8QPzGCaxoPQzlC/Y8wU9u4X8jy
gn5A==
X-Received: by 10.14.99.198 with SMTP id x46mr6593173eef.38.1367942782790;
Tue, 07 May 2013 09:06:22 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
by mx.google.com with ESMTPSA id t9sm27717684eeo.11.2013.05.07.09.06.21
for <multiple recipients>
(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Tue, 07 May 2013 09:06:21 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
id BD31F2E0619; Tue, 7 May 2013 18:06:19 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
Tue, 7 May 2013 18:06:17 +0200
Date: Tue, 7 May 2013 18:06:17 +0200
From: Adam Back <adam@cypherspace.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20130507160617.GB14418@netbook.cypherspace.org>
References: <20130507121641.GA11770@netbook.cypherspace.org>
<20130507131948.GA4231@vps7135.xlshosting.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20130507131948.GA4231@vps7135.xlshosting.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:130507:pieter.wuille@gmail.com::LogMqdRtCJFXjqrT:00000000000000
0000000000000000000000000ZzQ
X-Hashcash: 1:20:130507:bitcoin-development@lists.sourceforge.net::pKq1/rAP7XE1y
tP1:000000000000000000007BEo
X-Hashcash: 1:20:130507:adam@cypherspace.org::XW3o2MG2cYu4nV9+:00000000000000000
0000000000000000000000004YuI
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(adam.back[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1UZkPN-0006AA-4z
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] minor bitcoin-qt gripes moving BTC off
specific key
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: Tue, 07 May 2013 16:06:33 -0000
At ZKS other than freedom network (ToR precursor) we had psueudonyms
associated with cookie managers. The idea was you create pseudonyms for
different purposes to segregate your online linkability.
medical
casual browsing
social media
private
work
true name
Seems to me that people are always going to make mistakes with individual
keys, even if the feature were there and accidentally link all their coin
sources together. I presume people saw the analysis of the slush related
25k BTC theft, even seemingly the thief made possible slips while trying
presumably not to:
http://anonymity-in-bitcoin.blogspot.com/2011/07/bitcoin-is-not-anonymous.html
Does the client have any privacy algorithm (to minimise coin source cross
linking) to reach a given payment?
eg consider say I use social media, with a screen name; I collect reddit
tips etc; I pay them out to others, or use them to buy virtual goods
associated with the same purpose.
It would be rather useful to help people achieve that, there is already the
ability to create addresses, label them. But I think just for the GUI to
allow you to control which address the payment is from would be enough, it
doesnt seem like such a complicated concept. And if people dont care, they
only need create one address.
Technically ZKS wasnt anonymous networking like ToR but pseudonymous
networking. Multiple wallets for different unlinked purposes would be
somewhat analogous to ZKS freedom pseudonymous networking & cookie-jar.
Because of the pseudonymity in ZKS misbehavers could be blocked by exit
nodes based on pseudonym. Of course they can always create a new pseudonym
but then they lose their accumulated reputation. You can even make people
pay for pseudonyms, as I recall users got 5 free pseudonyms but had to pay
for more.
(Though I have to admit the concensus after some years at ZKS was most end
users didnt understand what a pseudonym was! They just wanted to be
"private" and have the computer magically solve it for them.)
If you want to simplify maybe you could consider normal (linked to AML
trading accounts, orders for physically delivered goods etc), and "private"
analogus to the private browsing mode in various browsers. Maybe beyond 2
is an advanced feature but still available.
Adam
On Tue, May 07, 2013 at 03:19:50PM +0200, Pieter Wuille wrote:
>On Tue, May 07, 2013 at 02:16:41PM +0200, Adam Back wrote:
>> Hi
>>
>> Three minor security/other issues:
>>
>> 1. please a way to unlock the wallet without displaying wallet password in
>> console screen (console unlock wallet, to import priv key); or
>
>I think the general solution here is providing a feature-reach Python RPC client,
>which can do things like remember passwords, command history/tab completion,
>perhaps even batch lookups of compound commands (getblock $(getblockhash X, for
>example, ...). The naive RPC client built into bitcoind is not a good fit for
>many features, as they can much more efficiently be developed outside of the
>core binary,
>
>
>> 2. a button to import a private key (and option to transfer it to another
>> key - if you are not the sole controller the private key)
>
>I'm quite opposed to any per-key fiddling in the GUI. This will inevitably lead
>to (even more) people misunderstanding how wallets work and shooting themself in
>the foot. I don't mind an expert mode ("coin control") that enables such features,
>but in general, we should for entire-wallet export and import rather than
>individual keys.
>
>Import & sweep an address is something else, that sounds safe to.
>
>> 3. a UX way to transfer BTC off a specific adress (eg choose from
>> address), rather than having to spend the entire wallet onto a new
>> address, just to get BTC off a specific address. Doing it that way has
>> problems: creates more network traffic/bigger packets, higher fees (if
>> any transactions are young/low confirmation), and generally damages
>> privacy as all your funds end up linked.
>
>This belongs in coin control, IMHO.
>
>--
>Pieter
>
|
