1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1V7Up2-0003tv-0m
for bitcoin-development@lists.sourceforge.net;
Thu, 08 Aug 2013 18:20:28 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.56 as permitted sender)
client-ip=62.13.149.56; envelope-from=pete@petertodd.org;
helo=outmail149056.authsmtp.com;
Received: from outmail149056.authsmtp.com ([62.13.149.56])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1V7Up0-0007Vs-21 for bitcoin-development@lists.sourceforge.net;
Thu, 08 Aug 2013 18:20:27 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r78IKK0W054794 for <bitcoin-development@lists.sourceforge.net>;
Thu, 8 Aug 2013 19:20:20 +0100 (BST)
Received: from petertodd.org (petertodd.org [174.129.28.249])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r78IKECP008031
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
for <bitcoin-development@lists.sourceforge.net>;
Thu, 8 Aug 2013 19:20:17 +0100 (BST)
Date: Thu, 8 Aug 2013 14:20:14 -0400
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20130808182014.GA8964@petertodd.org>
References: <20130727234918.GA11635@savin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0"
Content-Disposition: inline
In-Reply-To: <20130727234918.GA11635@savin>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 2d6b1840-0057-11e3-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXw11
IQ0eXVBSFQZ4ABUL BB4UUx48dgJCZn9y bFhgVm5ZWE1lcE56
XU8aV2oOHBwVGwAf UEhYdAIadwtOeFFH PlYtVXsJYXgHZn9n
WlZqMmt0N2wHImEN GltQfApJGhlWE2Qq fR1QVQYFHFEOQCQ1
ahArNFMYG14UP0Mu BBMdRlVQPRYZFgpE V15EBCtUOxEeRjYr
RQRcUAsCEThQBD9V GQY3JQVEGVQA
X-Authentic-SMTP: 61633532353630.1019:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/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: 1V7Up0-0007Vs-21
Subject: Re: [Bitcoin-development] Two factor wallet with one-time-passwords
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 08 Aug 2013 18:20:28 -0000
--k+w/mQv8wyuph6w0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Jul 27, 2013 at 07:49:18PM -0400, Peter Todd wrote:
> Funding the wallet
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> 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.
--=20
'peter'[:-1]@petertodd.org
000000000000002f3613b5394e39a254ba4afa9f76af72cd6b4273736d7987fb
--k+w/mQv8wyuph6w0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlID4V4ACgkQpEFN739thox5XwCdF4qaiLM7n1zQYPhhnweKHSKE
/NgAoI7vBgWkauFOod0NBnvLNpVghu20
=P7oB
-----END PGP SIGNATURE-----
--k+w/mQv8wyuph6w0--
|
