From: Peter Todd <pete@petertodd•org>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Two factor wallet with one-time-passwords
Date: Thu, 8 Aug 2013 14:20:14 -0400 [thread overview]
Message-ID: <20130808182014.GA8964@petertodd.org> (raw)
In-Reply-To: <20130727234918.GA11635@savin>
[-- Attachment #1: Type: text/plain, Size: 2915 bytes --]
On Sat, Jul 27, 2013 at 07:49:18PM -0400, Peter Todd wrote:
> Funding the wallet
> ==================
>
> As with any multi-party wallet receiving funds must also be handled
> carefully to ensure an attacker can't fool the user into giving the
> sender the wrong address. This requires the involvement of all parties
> required to authorize an outgoing payment. In addition here the
> protection only works if funds sent to the wallet are split up into the
> discrete authorization amounts the user wishes. (possibly with more than
> one amount level)
Quick note for patent prior-art/my own memory - did a talk yesterday
about multifactor wallets, one time passwords and hash digest based
oracles. Someone getting involved in the business of selling bitcoins
pointed out that legally it can actually be desirable to give the
bitcoins to the customer by giving them a physical private key, perhaps
on a sheet of paper in a mailed envelope. Obviously the customer would
be wise to sweep the funds. Of course, the advantage of doing it with
paper is the legal system has a long history of dealing with the concept
of a secret on a piece of paper. (your customers won't have handy PKI to
use after all)
With multi-factor wallets you can have the customer provide one or more
keys, and you give them one final key on a sheet of paper, with
instructions to scan it on their phone via QR-code or something. Now the
transfer is absolute on your end - you can't get the funds back. If it's
a large amount you may want to split it up among multiple addresses, and
deliver the keys to the customer in a way that makes it obvious when
they are revealed. (scratch off for instance)
Finally, one-time-passwords do much the same thing, but they don't
require the second device, and the sheet of paper the customer is
dealing with can be much shorter. Similarly the final approval could
just be done over the phone by telling the customer the ~6-8 magic words
that unlock their funds - legally it could be useful to record that
phone call. Similarly for a large transfer, make it clear how much each
scratched off text field is unlocking to defend yourself in court.
Of course, in both there is still the risk of the funds ending up locked
due to a mistake, but at least there isn't financial incentive to make
that event happen. (usually)
I'll admit I hadn't thought of any of this stuff until I talked to an
actual business with real problems, worth doing.
Finally it's too bad we didn't get OP_EVAL; the customer could have
provided a P2SH script with, well, anything in it, and the unlock could
could have easily been a "bolt-on":
HASH160 <digest> EQUALVERIFY
DUP HASH160 <p2sh-code-digest> EQUALVERIFY EVAL
Oh well, MAST support can do the same thing one day.
--
'peter'[:-1]@petertodd.org
000000000000002f3613b5394e39a254ba4afa9f76af72cd6b4273736d7987fb
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
prev parent reply other threads:[~2013-08-08 18:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-27 23:49 Peter Todd
2013-07-28 1:20 ` Peter Todd
2013-07-28 19:11 ` John Dillon
2013-08-08 18:20 ` Peter Todd [this message]
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=20130808182014.GA8964@petertodd.org \
--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