From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 ; Thu, 8 Aug 2013 19:20:17 +0100 (BST) Date: Thu, 8 Aug 2013 14:20:14 -0400 From: Peter Todd To: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 EQUALVERIFY DUP HASH160 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--