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
>
::
Re: [unSYSTEM] [Bitcoin-development…
