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
>