This would be conserved, as long as you remember your seed and the senders
bip32 master public key (xpub), this master public key should ideally be
distributed publicly and well known/embedded in the blockchain or twister,
on the owners website, copied on archive.org etc, this would still retain
privacy as any addresses derived from this key would be computationally
impractical to generate unless you know the shared seed of the two people.

As long as the receiver knows their seed and the senders mpk all funds can
be recovered. My idea is that we use twister, or something similar, to
create a username/xpub pair which is then published. A sender can then get
this xpub and send funds to the secret branch, (multiple times if
necessary) and notify the receiver with their xpub, so the receiver can
also find the secret branch, the users wallets would then "remember" each
other and keep a watch on the next address on that branch for another
payment, up to a gap limit. This doesn't have to be registered anywhere
though, people can still use arbitrary xpubs for alternate
identities/different accounts etc. This might be an issue though, if you
have 100 contacts in your address book, you'll be listening for deposits to
100 new addresses.

There is another problem with BIP32 however, is that custom branch numbers
also need to be backed up, along with the seed. Like /0 and /1 might be
standard branches, but /213/321/421/123 wont be and you'd either have to
back up that branch number, or scan the entire space for an address that
has already been used on the network, which is likely to be impractical.


Thanks
Bob




On 18 January 2014 19:01, Thomas Hartman <thomas@???> wrote:

> I like this.
>
> However, there is an issue that affects your proposal, and many others.
>
> I'm talking about wallet recoverability, and how lightweight should
> wallets be.
>
> I think a desirable property for a modern wallet would be that you can
> recover all funds in the event of loss with a 128 bit seed (i.e. bip32
> or electrum style).
>
> If payments are done as you described, do we retain this property?
>
> Or is going on a nonce finding expedition too expensive, if you lose
> both the wallet and the invoices?
>
> If too expensive that doesn't mean we shouldn't follow your idea for
> the appropriate use cases. But, I think it's important to have a clear
> way to indicate to users what wallet features and use modes are
> "lightweight memory" and which ones require diligent backups and
> caution and care to avoid loss. By memory, I mean human not machine
> memory.
>
>
>
>
>
>
> On Sat, Jan 18, 2014 at 8:14 AM, Robert Williamson <bobalot@???>
> wrote:
> > Hey Thomas,
> >
> > I have this idea for people to share their BIP32 public keys (xpub) and
> then
> > they can use the diffie hellman to generate a shared secret from the
> > public/private key pair and generate a secret branch for each mpk, you
> can
> > then send multiple payments to each others mpk discreetly by generating
> the
> > next address on that branch. This allows the benefits of multiple
> payments
> > without having to transmit a nonce, all you need to know is the public
> key
> > of the person paying you.
> >
> > It's a mess at the moment, but it'll have a better implementation once
> I've
> > sorted out some of the BIP32 sequence stuff.
> >
> > https://gist.github.com/Bobalot/8458501
> > https://gist.github.com/Bobalot/8458443
> >
> > This is probably a good thing for merge avoidance too, a wallet could
> send 3
> > different transactions to the secret branch of the mpk and nobody would
> be
> > able to tell if they were all to the same person (unless they merge them
> > when spending)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On 18 January 2014 12:36, Thomas Hartman <thomas@???>
> wrote:
> >>
> >> Idea:
> >>
> >> Generate multiple nonces, send to multiple addresses, include all the
> >> nonces with the invoice of course.
> >>
> >> This prevents guessing what a payment is for just by the price tag,
> >> and differentiating payments from change.
> >>
> >> Taking a step back, I am thinking about these proposed address
> >> groupings as "single use accounts" rather than single use addresses.
> >>
> >> An account being a group of addresses grouped for some purposes,
> >> possibly for a single use payment.
> >>
> >> In most cases an account will be a seed and a group of identifyers
> >> (like nonces). I think this covers both bip32 accounts and stealth
> >> addresses.
> >> _______________________________________________
> >> 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
>