public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Daniel Stadulis <dstadulis@gmail.com>,
	bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships
Date: Tue, 20 Jan 2015 12:15:57 -0500	[thread overview]
Message-ID: <20150120171557.GA29353@muck> (raw)
In-Reply-To: <CAHpxFbEoDLMGKB7arHbgB+4kx8BwgcX7nBUZz6yP9k4LjZeu1A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

On Tue, Jan 20, 2015 at 08:43:57AM -0800, Daniel Stadulis wrote:
> Hey Peter,
> 
> What would you say to the argument: given developers have auto update
> capabilities they only have the ability to *give themselves* *the ability* to
> have custodial rights?

Heh, well, courts tend not to have the narrow-minded pedantic logic that
programmers do; quite likely that they'd see having the ability to give
themselves the ability as equivalent to simply having the ability. What
matters more is intent: the authors of an operating system had no intent
to have a custodial relationship over anyones' BTC, so they'd be off the
hook. The authors of a Bitcoin wallet on the other hand, depends on how
you go about it.

For instance Lighthouse has something called UpdateFX, which allows for
multi-signature updates. It also supports deterministic builds, and
allows users to chose whether or not they'll follow new updates
automatically, or only update on demand. In a court that could be all
brought up as examples of intent *not* to have a custodial relationship,
which may be enough to sway judge/jury, and certainly will help avoid
ending up in court in the first place by virtue of the fact that all
those protections help avoid theft, and increase the # of people that an
authority need to involve to seize funds via an update.

-- 
'peter'[:-1]@petertodd.org
00000000000000001a5e1dc75b28e8445c6e8a5c35c76637e33a3e96d487b74c

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

  parent reply	other threads:[~2015-01-20 17:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-20 15:46 [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships Peter Todd
     [not found] ` <CAHpxFbEoDLMGKB7arHbgB+4kx8BwgcX7nBUZz6yP9k4LjZeu1A@mail.gmail.com>
2015-01-20 17:15   ` Peter Todd [this message]
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=20150120171557.GA29353@muck \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=dstadulis@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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