New BSIP 0054: Deterministic addresses for Stealth wallets

[christophersanborn]

(From: https://github.com/Agorise/bsips/blob/master/bsip-1204.md)

BSIP: 1204 (unassigned)
Title: Deterministic addresses for Stealth wallets
Authors: Christopher J. Sanborn
Status: Draft
Type: Informational
Created: 2018-01-29
Discussion: <url>

Abstract

To simplify a wallet owner's backup burden by documenting and standardizing key derivation for Stealth balances from the same backup seeds used to generate the user's regular account keys.

Motivation

Current wallet implementations (e.g. the CLI wallet and Agorise's extensions to the UI wallet) generate a new Brain Key for each Stealth "account" (defined as a confidential balance under the control of a single private key). Since creating a confidential account is a purely client-side activity, (in contrast with a regular account which is registered on the blockchain), there is no automatic association between a confidential balance and a regular account that ostensibly "owns" it, and a backup burden is created for each new confidential balance.

It would be desireable to give the user the ability to maintain all of her accounts and balances under the control of a single backup key seed or brain key, so that the backup burden can be satisfied just once, at the creation of the user's first regular account. The derivation schemes defined under Bitcoin's BIP-44 provide a natural mechanism for this, and Satoshi Lab's SLIP-48 already define derivation paths for owner, active, and memo keys on BitShares and similar networks.

We propose here:

(1) To define additional derivation paths for Stealth accounts, and,

(2) For backwards compatibility with existing accounts secured by Brain Key, to standardise and document a distinct procedure for deriving Stealth keys from Brain Keys so that the same Brain Key that secures a user's regular account can also be used to secure their confidential balances, if the user desires.

Rationale

Specifications

Discussion

Summary for Shareholders

Copyright

This document is placed in the public domain.

See Also

[xeroc]

It may be possible to use BIP32 to derive child keys from the recepient's stealth keys/addresses, but I fear that that would only bring convenience to the recepient IFF you also allow linkability of addresses, no?

[christophersanborn]

It should not present a problem for unlinkability. The unlinkable address (or "receiving address," the address at which funds actually get deposited) is derived from a shared secret (computed via ECDH) between the stealth address (or "asking address," the address the recipient uses to ask for funds) and a one-time-key generated by the sender.

Incrementing the stealth address via BIP32 doesn't pose any problems for unlinkability here. It only gives the recipient more choices of stealth address to use.

In fact, one might even think it unnecessary to increment the stealth address at all, since it's not possible for a third party to monitor when transactions are sent to that address (because the unlinkable addresses are all one-time use). But the reason to increment addresses is for how you use those addresses outside of the blockchain. If you always ask for funds with the same stealth address, then there is linkability between those communications, off chain. So I can imagine use cases in which the user may still want an address-per-transaction, or address per use-case, or just periodic incrementing of the address, etc.

[xeroc]

I think I now understand what you are trying to achieve. You generate a master shared secret from which you go down in a tree using BIP32 to get transfer-individual addresses.
Makes sense to me.

The receiver only needs to know who potentially sent something and go throught the BIP32 tree to find out. The only thing that needs to be addresses is how the recepient is supposed to know how far into the BIP32 tree he needs to go for subsequent transfers (assuming a gap or already emptied stealth addresses)

[svk31]

How expensive would the lookup be? The GUI already has a similar problem when discovering accounts from the brain key seed. In that case there's a bounded loop that does API calls to check for accounts linked to public keys. The previous highest found index is stored, and we look 20 indices ahead I believe.

Eaely iterations if the wallet had a bug that created gaps in the brain key indices with no keys used for those indices, thats why we look that far ahead.

[Agorise]

@christophersanborn
re: "give the user the ability to maintain all of her accounts and balances under the control of a single backup key seed or brain key"
i asked Henry to ping you about this. he coded something similar already for our new Crystal wallet.

[abitmore]

Draft merged.