So if you bungled your wallet, to recover you would need to recall everyone
that ever sent you money.

Hmmmm..... Not terrible, but not great.

I guess it's the usual tradeoff between security and convenience.
On Jan 18, 2014 12:21 PM, "Robert Williamson" <bobalot@???> wrote:

> 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
>>
>
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>