Is mining relevant here?
On Sun, Dec 22, 2013 at 9:36 AM, Thomas Hartman
<thomas@???>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@???>
> 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@???> wrote:
> >>
> >> Hi!
> >>
> >> On 19/12/13 18:23, Mike Belshe wrote:
> >> > Hey Peter -
> >> >
> >> > I think this is a super list. A couple of thoughts:
> >> >
> >> > 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.
> >>
> >> cheers!
> >>
> >> _______________________________________________
> >> 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
> >
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
--
ॐMetatronॐ
::
Re: [unSYSTEM] [Bitcoin-development…
