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