Yeah we'll work on mockups. Still thinking / sorting out other tech stuff.

I found this on using the blockchain for identities:

https://eprint.iacr.org/2013/622.pdf

Conclusion:
"To realize such a ledger we propose using the block
chain system already in real world use with the distributed
cryptographic currency Bitcoin."

On 21/12/13 15:24, Mihai Alisie wrote:
> Looks awesome! When you guys have decided on the final version I can
> have it designed nicely as a pdf that can be easily passed around.
>
> Cheers,
> Mihai
> On 21/12/13 16:55, Metatron YHVH wrote:
>> So this darkwallet is not as efficient as multi-wallet balances? What is
>> the benefit of you putting your money in one place?
>>
>>
>> On Fri, Dec 20, 2013 at 9:46 AM, Amir Taaki <genjix@???> wrote:
>>
>>> I want to embed user identities in the blockchain which maps to a PGP
>>> fingerprint and domain. Then users can communicate using XMPP using
>>> their fingerprint@??? to coordinate things like sharing MPKs for
>>> new addresses or managing multisigs accounts and so on.
>>>
>>> https://wiki.unsystem.net/index.php/DarkWallet/Negotiation
>>>
>>> Users can establish this identity for a small fee (cost of tx to embed
>>> ID and setup cost for their XMPP server to create account and upload
>>> pubkey). Of course users can setup this info manually themselves but
>>> then have to enter details and use PGP key servers which is a lot of
>>> manual steps.
>>>
>>> F22F39B5@???
>>>
>>> There is then a negotation API on top of this for doing stuff like this:
>>>
>>> https://wiki.unsystem.net/index.php/DarkWallet/Multisig
>>>
>>> (probably just JSON messages passed around)
>>>
>>> On 20/12/13 17:32, Taylor Gerring wrote:
>>>> I’m inclined to agree, as this was discussed on multiple occasions and
>>>> seems to fix a lot of the address re-use problems. With hot topics like
>>>> “coin validation”, I think it’s important to highlight the privacy that
>>>> generating fresh addresses from public extended keys grants us.
>>>>
>>>> Also thinking about implications regarding non-merchant use of Payment
>>>> Protocol, encouraging the exchange of extended public keys instead of a
>>>> single address could be a boon for Payment Protocol to actually be
>>>> useful for users. Initially, the idea was that the merchant would
>>>> generate a new address from an extended key and include that in the
>>>> Payment Request. How do we handle pushing the extended public key down
>>>> to the wallet itself? Do we just shoehorn the exchange of keys into the
>>>> Payment Protocol itself via a special tag or would this require more
>>>> substantive change? Services could develop to facilitate the exchange
>>>> (acting as a sort of “PP gateway”) or wallet software might be able to
>>>> directly communicate, perhaps by exchanging PGP-encrypted files in
>>>> Payment Protocol format via Bluetooth, AirDrop, email, BitMessage, or
>>>> whatever future communications channel comes into being.
>>>>
>>>> Thanks again to Peter for putting together a consolidated list of topics!
>>>>
>>>> Taylor
>>>>
>>>>
>>>>
>>>> On Dec 19, 2013, at 2:40 PM, caedes <caedes@???
>>>> <mailto:caedes@sindominio.net>> wrote:
>>>>
>>>>> I feel it's missing mention of using (or not) *extended public keys*
>>>>> from bip 32 to share multiple addresses in one go, so regular payments
>>>>> can be done without asking for further addresses. Also since whoever has
>>>>> the extended key can generate public keys this might help P2SH where the
>>>>> public key is also needed.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> unSYSTEM mailing list: http://unsystem.net
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
> --
> Editor-in-Chief Bitcoin Magazine
>
>
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>