>>>    Is mining relevant here?

>>>    On Sun, Dec 22, 2013 at 9:36 AM, Thomas Hartman
>>>    <thomas@??? <mailto:thomas@standardcrypto.com>> wrote:

>>>        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
>>>        https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem

>>>    --

>>>      ॐMetatronॐ

>>>    _______________________________________________
>>>    unSYSTEM mailing list: http://unsystem.net
>>>    https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem