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