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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1YDb18-0004Qx-9O
for bitcoin-development@lists.sourceforge.net;
Tue, 20 Jan 2015 15:46:58 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.101 as permitted sender)
client-ip=62.13.149.101; envelope-from=pete@petertodd.org;
helo=outmail149101.authsmtp.com;
Received: from outmail149101.authsmtp.com ([62.13.149.101])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YDb13-0003Bn-An for bitcoin-development@lists.sourceforge.net;
Tue, 20 Jan 2015 15:46:58 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t0KFklMd059847
for <bitcoin-development@lists.sourceforge.net>;
Tue, 20 Jan 2015 15:46:47 GMT
Received: from muck (VELOCITY-IN.edge8.SanJose1.Level3.net [4.30.150.186])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t0KFkfpp074247
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
for <bitcoin-development@lists.sourceforge.net>;
Tue, 20 Jan 2015 15:46:44 GMT
Date: Tue, 20 Jan 2015 10:46:41 -0500
From: Peter Todd <pete@petertodd.org>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20150120154641.GA32556@muck>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/"
Content-Disposition: inline
X-Server-Quench: 898580bc-a0bb-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXQV1
KhkXXVBSFQB4ABkL AhgUVhw8cxtFeGBx YEZ8X3hdQ0Fycll8
DApUbhtdMycgaGcb UkRfOQtdcAcEdhZN b1h/BiAQMGVVNGdh
RgJvemE/YmkacHwP H1BVJAtJHEpQCAI8 SlgGEDomGQUfRj4w
NFQhJBYVAVoWd1gq PVI9WFQXewAbDglT AwlWByFFOFAbSnlj
Bh5BQUkSETRZI29G DxkhPh5PBCdSWzJD bAAA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 4.30.150.186/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1YDb13-0003Bn-An
Subject: [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 15:46:58 -0000
--pWyiEgJYm5f9v55/
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I was talking to a lawyer with a background in finance law the other day
and we came to a somewhat worrying conclusion: authors of Bitcoin wallet
software probably have a custodial relationship with their users,
especially if they use auto-update mechanisms. Unfortunately this has
potential legal implications as custodial relationships tend to be
pretty highly regulated.
Why is this? Well, in most jurisdictions financial laws a custodial
relationship is defined as having the ability, but not the right, to
dispose of an asset. If you have the private keys for your users'
bitcoins - e.g. an exchange or "online" wallet - you clearly have the
ability to spend those bitcoins, thus you have a custodial relationship.
However if you can trivially obtain those private keys you can also
argue you have a custodial relationship. For instance StrongCoin was
able to seize funds stolen from OzCoin=B9 with a small change to the
client-side Javascript their users download from them every time they
visit the site. Portraying that as "the ability to dispose of an asset"
in a court of law would be pretty easy. Equally on a technical level
this isn't much different from how auto-updating software works.
Now I'm sure people in this audience will immediately point out that by
that logic your OS vendor is also in a custodial relationship - they
after all can push an update that steals everyones' bitcoins regardless
of what local wallet you use. But the law isn't a deterministic
algorithm, it's a political process. Circle is easy to portray as having
a custodial relationship, StrongCoin and Blockchain.info are a little
harder, Android Wallet harder still, Bitcoin Core's multi-party
deterministicly compiled releases even harder.
But ultimately we're not going to know until court cases start
happening. In the meantime probably the best advice - other than getting
out of the wallet business! - is to do everything you can to prevent
losses through malicious auto-updates. Create systems where as many
people as possible have to sign off and review an update before it has
the opportunity to spend user funds. Not having auto-updates at all is a
(legally) safe way to achieve that goal; if you do have them make sure
the process by which an update happens is controlled by more than one
person and there are mechanisms in place to create good audit logs of
how exactly an update happened.
Finally keep in mind that one of the consequences of a custodial
relationship is that some legal authority might try to *force* you to
seize user funds. StrongCoin made it 100% clear to authorities that they
and sites like them are able to seize funds at will - I won't be
surprised if authorities use that power in the future. The more
automatic and less transparent an update is, the higher the chance some
authority will lean on you to seize funds. So don't make it easy for
yourself to meet those demands.
1) https://bitcoinmagazine.com/4273/ozcoin-hacked-stolen-funds-seized-and-r=
eturned-by-strongcoin/
--=20
'peter'[:-1]@petertodd.org
00000000000000001a5e1dc75b28e8445c6e8a5c35c76637e33a3e96d487b74c
--pWyiEgJYm5f9v55/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJUvnhbXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxYTVlMWRjNzViMjhlODQ0NWM2ZThhNWMzNWM3NjYzN2Uz
M2EzZTk2ZDQ4N2I3NGMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvX2QgAhfwq69dua/KioZCdc0kSQtDL
d2+Nx6Aefbo1WczOh/kOJg+no6FpiqfdrXwz5PQeQBy3g9wIIwZMCmM+daExqq8t
8VFXdMNcbrXr3XjSME4leZVZrL6zS4ukugOn4qgNuZ3sJhLbNY87SQLPExNBNazQ
ggmKa9NizZ7s7zuJIrEcCGdbdPm1BJS6EX49a85xXD8uZGZ8eqXY6Ev+dbDy1JYL
RX0OTAlmHorszXsXzORWZPZr5G5tC6Zoa59Xa0XchVNVFRp90oYhkzIq30tWrawZ
5jRL3z6ZK5Z8Dt8IqYHpgifMnhJlXN5IPUZh4rlaKy1gGGjHORHIjAe6gOeXwQ==
=eHYI
-----END PGP SIGNATURE-----
--pWyiEgJYm5f9v55/--
|
