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