:: Re: [unSYSTEM] [Bitcoin-development…
Top Page
Delete this message
Reply to this message
Author: caedes
Date:  
To: System undo crew
CC: Bitcoin Dev, Mike Belshe
Subject: Re: [unSYSTEM] [Bitcoin-development] DarkWallet Best Practices
Hi!

On 19/12/13 18:23, Mike Belshe wrote:
> Hey Peter -
>
> I think this is a super list. A couple of thoughts:
>
> a) In the section on multi-sig and multi-factor, I think we can split
> these apart. Multi-factor user authentication is very valuable and not
> the same as multi-factor signing, which is a second level of
> complexity.   The multi-factor auth can be off-blockchain, e.g.
> authenticating with SMS message to your phone or Google Authenticator
> challenge.  Given the state of malware today, I personally would
> propose two requirements:
>     1) wallets SHOULD use multi-factor authentication before
> authorizing access to a wallet (e.g. view balances, addresses,
> transactions, etc)
>     2) wallets MUST use multi-factor auth before signing a
> transaction.   [note: I recognize that MUST might be too aggressive
> right now, but I wouldn't use a wallet without it.  this can also be
> impractical for server-side wallets]


Using multi-sig for multi-factor so the wallet needs to get some
additional signatures (or even the keys can be somewhere else) can make
2factor more orthogonal to the whole thing specially since we need to
support multisig spending, and other partial transaction fullfilling.

We can still account for other 2fa schemes, but i'm thinking more of
exploiting key signing itself and maybe bip32 wallet structure.

I agee on uour requirements, but also think they might be too harsh for
some uses I would require them myself so I could feel safe with my wallet.


>
> b) Multi-factor signing (e.g. P2SH) may be too early to really define.
>  But here are some issues which have come up from my own personal
> development experience:
>     - Wallets SHOULD NOT create two keys on a single host or device
>     - Wallets SHOULD provide a way to import external public keys
> which can be used as part of a P2SH address



Agree on these ones. Public keys could be imported through extended
public keys too if we agree to using those.

>
> Slightly off topic: For P2SH, address creation requires the public
> key, not the public hash of an address. For me, this has made it
> difficult to import keys created through out-of-band sources. Most
> wallets/key generators/etc only provide the address and not the public
> key, and this is a hinderance to easy P2SH creation off host. It
> would be great if there were a way to address this, but I don't know how.
>



We have to work on solutions... our aim is settle down on a way to
negotiate addresses and other parameters among identities, also key
importing can be supported to make these easier.

cheers!