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

> >> >>>    --

> >> >>>      ॐMetatronॐ

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