From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 ; Tue, 20 Jan 2015 15:46:44 GMT Date: Tue, 20 Jan 2015 10:46:41 -0500 From: Peter Todd 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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/--