>>>>>>       Well, at least you posted some budget and a spec.

>>>>>>       You still hijacked the thread (3 threads) though. If you would
>>> at
>>>>>>       least start a new thread, it would be somewhat more socially
>>>>>>       acceptable.

>>>>>>       On Sun, Dec 22, 2013 at 8:49 AM, Metatron YHVH
>>>>>>       <metatrongone@??? <mailto:metatrongone@gmail.com>>
>>>>>> wrote:
>>>>>>> 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@???
>>>>>>       <mailto:caedes@sindominio.net>> wrote:

>>>>>>>>> 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.

>>>>>>       _______________________________________________
>>>>>>       unSYSTEM mailing list: http://unsystem.net

>>>>>>     ॐMetatronॐ