:: Re: [unSYSTEM] DarkWallet Best Prac…
Top Page
Delete this message
Reply to this message
Author: Metatron YHVH
Date:  
To: System undo crew
Subject: Re: [unSYSTEM] DarkWallet Best Practices
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
>
>



--
ॐMetatronॐ