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