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; 
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
Subject: [Bitcoin-development] The legal risks of auto-updating wallet
 software; custodial relationships
Precedence: list


--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/--