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