From: Peter Todd <pete@petertodd•org>
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships
Date: Tue, 20 Jan 2015 10:46:41 -0500 [thread overview]
Message-ID: <20150120154641.GA32556@muck> (raw)
[-- Attachment #1: Type: text/plain, Size: 3155 bytes --]
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¹ 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-returned-by-strongcoin/
--
'peter'[:-1]@petertodd.org
00000000000000001a5e1dc75b28e8445c6e8a5c35c76637e33a3e96d487b74c
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next reply other threads:[~2015-01-20 15:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-20 15:46 Peter Todd [this message]
[not found] ` <CAHpxFbEoDLMGKB7arHbgB+4kx8BwgcX7nBUZz6yP9k4LjZeu1A@mail.gmail.com>
2015-01-20 17:15 ` Peter Todd
2015-01-20 17:23 ` Matt Whitlock
2015-01-20 17:40 ` Peter Todd
2015-01-20 17:44 ` Matt Whitlock
2015-01-20 17:44 ` Tamas Blummer
2015-01-20 17:47 ` Matt Whitlock
2015-01-20 17:49 ` Peter Todd
2015-01-20 17:56 ` Tamas Blummer
2015-01-20 17:47 ` Justus Ranvier
2015-01-20 18:48 ` Tamas Blummer
2015-01-20 19:31 ` Justus Ranvier
2015-01-20 21:33 ` odinn
2015-01-20 21:49 ` Roy Badami
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150120154641.GA32556@muck \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox