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-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <odinn.cyberguerrilla@riseup.net>) id 1YDgQi-0007K9-W7
for bitcoin-development@lists.sourceforge.net;
Tue, 20 Jan 2015 21:33:45 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of riseup.net
designates 198.252.153.129 as permitted sender)
client-ip=198.252.153.129;
envelope-from=odinn.cyberguerrilla@riseup.net;
helo=mx1.riseup.net;
Received: from mx1.riseup.net ([198.252.153.129])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1YDgQh-0006d5-C0
for bitcoin-development@lists.sourceforge.net;
Tue, 20 Jan 2015 21:33:44 +0000
Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net",
Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
by mx1.riseup.net (Postfix) with ESMTPS id 8E8D640E5B
for <bitcoin-development@lists.sourceforge.net>;
Tue, 20 Jan 2015 21:33:37 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
(Authenticated sender: odinn.cyberguerrilla)
with ESMTPSA id D169A21D50
Message-ID: <54BEC9C1.3000600@riseup.net>
Date: Tue, 20 Jan 2015 21:33:53 +0000
From: odinn <odinn.cyberguerrilla@riseup.net>
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <20150120154641.GA32556@muck> <54BE94AB.3020207@monetas.net>
<FCDDDA53-8B1C-48EF-82B1-FED9B6DE21D5@bitsofproof.com>
In-Reply-To: <FCDDDA53-8B1C-48EF-82B1-FED9B6DE21D5@bitsofproof.com>
Content-Type: text/plain; charset=windows-1252
X-Virus-Scanned: clamav-milter 0.98.5 at mx1
X-Virus-Status: Clean
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.4 (-)
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [198.252.153.129 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
lines
X-Headers-End: 1YDgQh-0006d5-C0
Subject: Re: [Bitcoin-development] The legal risks of auto-updating wallet
software; custodial relationships
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, 20 Jan 2015 21:33:45 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Um ~ "jurisdiction of wallet provider?"
If that's the (perhaps ot) bit you want to run on this thread then my
comments are:
Get out of web wallet businesses now. It's not a jurisdictional
question anymore, although I think there used to be very valid long
running debates on where it would be best to do business. Now it just
feels like you will be bouncing from one place to another -
determining where your exit is as soon as you establish a (physical)
presence, because jurisdictions sense a serious threat from the
advancement of financial cryptography as it will evolve in the next
several years. So you have to be mobile, or do something like what
they are establishing at blueseed (see http://blueseed.com which is
just off coast of San Francisco). Please perk up and don't just swipe
to delete, read the whole e-mail. There are some configurations (e.g.
the zero knowledge bit) you can do to mitigate the issues but if you
are asking users to log in and log out of a service that relies on a
web site then in the end you doom them (and any service you provide)
to mandatory storage of customer data and ultimately loss of customer
resources due to identification of the customer.
I think you need to stop quibbling about the details and just get over
it and understand that the problem of web wallet users and
corporations that serve web wallet customers being forced to give up
information constantly to governments means that web wallets are
certainly no longer a viable solution. And post-cromnibus with the
extra financial surveillance provisions now passed on 3rd party
matters, it's even worse. This is not subject to debate, it's just a
fact. Period. Web wallet corps exist now only on a model that exists
to burn the users. Convenient? Yes. But is it good for the users in
the long haul? Absolutely not. Do alternative to the web wallets
exist? Absolutely.
Back off.. Go to p2p. Stop advocating for webby solutions. In fact,
I don't think that anyone working for coinbase or bitpay should be,
anymore. I think that on principle you should withdraw and end your
employment from such services.
Core? Good. Electrum Wallet? good. Mycelium? Local Trader? Open
Bazaar? Could be better, but great. These are the kind of things we
need. No signups, avoids centralizations, no grabbing your data, no
ID collection and requirements.
As to the issue of auto-updating itself... I think the simplest answer
to this question (personally) is that (go ahead and attack me here)
there shouldn't be auto-updates... but that there should be
auto-notifications for update when (a) update is available, but that
(b) this notification should never "push" the user to update (e.g. the
notification should never say "oh hey user if you don't update by such
and such a date, your wallet will not work or satoshis will die
because of your inaction"
(stays quiet while likely 100-e-mail thread is spawned from this)
- -O
Tamas Blummer:
> Justus,
>=20
> In contrary.
>=20
> Not being in the jurisdiction of the wallet provider makes it
> harder for the user to reclaim funds taken by the wallet provider.=20
> The legal hurdle to force confiscation through a wallet provider
> might also be lower if the target user is not domestic.
>=20
> Tamas Blummer
>=20
>=20
>=20
> -----------------------------------------------------------------------=
-------
>
>=20
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in
> Ashburn. Choose from 2 high performing configs, both with 100TB of
> bandwidth. Higher redundancy.Lower latency.Increased
> capacity.Completely compliant. http://p.sf.net/sfu/gigenet
>=20
>=20
>=20
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net=20
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
- --=20
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJUvsnBAAoJEGxwq/inSG8CGekIAJH4lUdk81sVfQqxZ4sKOKFM
5iAvCD4JNuV+xcCZBiNNr1GxIZEVoDRQYupo7wB1A5uGW+STLHDGsEMuDNyiOcNl
oSsJQFZJabxL7dIn8g89Gw+8J8LtYKEkHHZLk5J5QF0DkRljXjEcOV4KL6WXhdl5
ToV01POMUBbSJsQt2lLznmCvQ+4QW5/GJ9Hk04HIub+kzuil0R23CgRH9QFevC9S
2/RT3NnfGFu+jU5+K/o8RbuUuzExq94x4w266IEmJc0NsLHxnxsg2PefabQbfdzp
P7FU7+D9NsIOaBGTXnQK80kpgRCJ49Gf9HXHKFYg2KCFuqgJYa8DnHm1Xlfo7DQ=3D
=3DyS8H
-----END PGP SIGNATURE-----
|
