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
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
