Hopefully this will be used mostly with public xpubs, so you'd probably be
able to find the branch again quite easily. Amir wants to do some sort of
identity blockchain with twister, so you could lookup peoples xpub in there
if you need to restore.

This is the problem with BIP32 though, it's not just write down your seed
and don't worry, you have to save your branch hierarchy too, it'd be
advisable that any wallet using it doesn't create any branch without
explicitly telling the user to make a copy of the account numbers, which
can be up to 0x80000000 for each branch.




On 18 January 2014 22:53, Thomas Hartman <thomas@???> wrote:

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