:: Re: [unSYSTEM] [Bitcoin-development…
Top Page
Delete this message
Reply to this message
Author: Metatron YHVH
Date:  
To: System undo crew
Subject: Re: [unSYSTEM] [Bitcoin-development] DarkWallet Best Practices
Bitcoins and RFID currency. I've got 7,692 USD to anyone who prove they are
different.


On Sun, Dec 22, 2013 at 7:47 AM, caedes <caedes@???> wrote:

> 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!
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>




--
ॐMetatronॐ