:: Re: [unSYSTEM] rather than send pay…
Kezdőlap
Delete this message
Reply to this message
Szerző: Thomas Hartman
Dátum:  
Címzett: System undo crew
Tárgy: Re: [unSYSTEM] rather than send payments to a single stealth address, how about using multiple?
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
>
>