# An incomplete information to stealth addresses

*by*Phil Tadros

2023 Jan 20

See all posts

*Particular due to Ben DiFrancesco, Matt Solomon, Toni Wahrstätter and Antonio Sanso for suggestions and assessment*

One of many largest remaining challenges within the Ethereum ecosystem is privateness. By default, something that goes onto a public blockchain is public. More and more, this implies not simply cash and monetary transactions, but additionally ENS names, POAPs, NFTs, soulbound tokens, and far more. In apply, utilizing the complete suite of Ethereum purposes includes making a good portion of your life public for anybody to see and analyze.

Enhancing this state of affairs is a vital downside, and that is well known. To this point, nevertheless, discussions on bettering privateness have largely centered round one particular use case: privacy-preserving transfers (and often self-transfers) of ETH and mainstream ERC20 tokens. This publish will describe the mechanics and use instances of a unique class of software that might enhance the state of privateness on Ethereum in a variety of different contexts: **stealth addresses**.

## What’s a stealth deal with system?

Suppose that Alice desires to ship Bob an asset. This may very well be some amount of cryptocurrency (eg. 1 ETH, 500 RAI), or it may very well be an NFT. When Bob receives the asset, he doesn’t need the complete world to know that it was he who bought it. Hiding the truth that a switch occurred is not possible, particularly if it is an NFT of which there’s just one copy on-chain, however hiding *who’s the recipient* could also be far more viable. Alice and Bob are additionally lazy: they need a system the place the fee workflow is strictly the identical as it’s at the moment. Bob sends Alice (or registers on ENS) some form of “deal with” encoding how somebody pays him, and that data alone is sufficient for Alice (or anybody else) to ship him the asset.

Word that it is a totally different form of privateness than what’s supplied by eg. Twister Money. Twister Money can cover transfers of mainstream fungible belongings comparable to ETH or main ERC20s (although it is most simply helpful for privately *sending to your self*), but it surely’s very weak at including privateness to transfers of obscure ERC20s, and it can not add privateness to NFT transfers in any respect.

*The odd workflow of constructing a fee with cryptocurrency. We need to add privateness (nobody can inform that it was Bob who obtained the asset), however hold the workflow the identical.*

Stealth addresses present such a scheme. A stealth deal with is an deal with that may be generated by both Alice or Bob, however which might solely be managed by Bob. Bob generates and retains secret a **spending key**, and makes use of this key to generate a **stealth meta-address**. He passes this meta-address to Alice (or registers it on ENS). Alice can carry out a computation on this meta-address to generate a **stealth deal with** belonging to Bob. She will then ship any belongings she desires to ship to this deal with, and Bob can have full management over them. Together with the switch, she publishes some further cryptographic information (an **ephemeral pubkey**) on-chain that helps Bob uncover that this deal with belongs to him.

One other approach to take a look at it’s: stealth addresses give the identical privateness properties as Bob producing a recent deal with for every transaction, however with out requiring any interplay from Bob.

The total workflow of a stealth deal with scheme will be seen as follows:

- Bob generates his
**root spending key**(`m`

) and**stealth meta-address**(`M`

). - Bob provides an ENS file to register
`M`

because the stealth meta-address for`bob.eth`

. - We assume Alice is aware of that Bob is
`bob.eth`

. Alice appears up his stealth meta-address`M`

on ENS. - Alice generates an
**ephemeral key**that solely she is aware of, and that she solely makes use of as soon as (to generate this particular stealth deal with). - Alice makes use of an algorithm that mixes her ephemeral key and Bob’s meta-address to
**generate a stealth deal with**. She will now ship belongings to this deal with. - Alice additionally
**generates her ephemeral public key, and publishes it to the ephemeral public key registry**(this may be achieved in the identical transaction as the primary transaction sending belongings to this stealth deal with). - For Bob to find stealth addresses belonging to him, Bob must
**scan the ephemeral public key registry for the**printed by anybody for any motive because the final time he did the scan.*whole checklist*of ephemeral public keys - For every ephemeral public key, Bob makes an attempt to mix it along with his root spending key to generate a stealth deal with, and checks if there are any belongings in that deal with. If there are, Bob computes the spending key for that deal with and remembers it.

This all depends on two makes use of of cryptographic trickery. First, we’d like a pair of algorithms to generate a **shared secret**: one algorithm which makes use of Alice’s secret factor (her ephemeral key) and Bob’s public factor (his meta-address), and one other algorithm which makes use of Bob’s secret factor (his root spending key) and Alice’s public factor (her ephemeral public key). This may be achieved in some ways; Diffie-Hellman key exchange was one of many outcomes that based the sphere of recent cryptography, and it accomplishes precisely this.

However a shared secret by itself isn’t sufficient: if we simply generate a non-public key from the shared secret, then Alice and Bob might each spend from this deal with. We might go away it at that, leaving it as much as Bob to maneuver the funds to a brand new deal with, however that is inefficient and needlessly reduces safety. So we additionally add a **key blinding mechanism**: a pair of algorithms the place Bob can mix the shared secret along with his root spending key, and Alice can mix the shared secret with Bob’s meta-address, in such a approach that Alice can generate the stealth deal with, and Bob can generate the spending key for that stealth deal with, all with out making a public hyperlink between the stealth deal with and Bob’s meta-address (or between one stealth deal with and one other).

## Stealth addresses with elliptic curve cryptography

Stealth addresses utilizing elliptic curve cryptography had been initially launched within the context of Bitcoin by Peter Todd in 2014. This system works as follows (this assumes prior data of fundamental elliptic curve cryptography; see here, here and here for some tutorials):

- Bob generates a key
`m`

, and computes`M = G * m`

, the place`G`

is a commonly-agreed generator level for the elliptic curve. The stealth meta-address is an encoding of`M`

. - Alice generates an ephemeral key
`r`

, and publishes the ephemeral public key`R = G * r`

. - Alice can compute a shared secret
`S = M * r`

, and Bob can compute the identical shared secret`S = m * R`

. - On the whole, in each Bitcoin and Ethereum (together with correctly-designed ERC-4337 accounts), an deal with is a hash containing the general public key used to confirm transactions from that deal with. So you possibly can compute the deal with in the event you compute the general public key. To compute the general public key, Alice or Bob can compute
`P = M + G * hash(S)`

- To compute the non-public key for that deal with, Bob (and Bob alone) can compute
`p = m + hash(S)`

This satisfies all of our necessities above, and is remarkably easy!

There’s even an EIP attempting to outline a stealth deal with commonplace for Ethereum at the moment, that each helps this strategy and offers area for customers to develop different approaches (eg. that assist Bob having separate spending and viewing keys, or that use totally different cryptography for quantum-resistant safety). Now you may assume: stealth addresses should not too tough, the speculation is already strong, and getting them adopted is simply an implementation element. The issue is, nevertheless, that there are some fairly huge implementation particulars {that a} really efficient implementation would wish to get by.

## Stealth addresses and paying transaction charges

Suppose that somebody sends you an NFT. Conscious of your privateness, they ship it to a stealth deal with that you simply management. After scanning the ephem pubkeys on-chain, your pockets robotically discovers this deal with. Now you can freely show possession of the NFT or switch it to another person. However there’s an issue! That account has 0 ETH in it, and so there is no such thing as a option to pay transaction charges. Even ERC-4337 token paymasters will not work, as a result of these solely work for fungible ERC20 tokens. And you may’t ship ETH into it out of your principal pockets, as a result of then you definately’re making a publicly seen hyperlink.

*Inserting memes of 2017-era (or older) crypto rip-off figures is a vital method that writers can use to sign erudition and respectableness, as a result of it reveals that they’ve been round for a very long time and have refined tastes, and should not simply swayed by current-thing rip-off figures like SBF.*

There’s one “simple” option to resolve the issue: simply use ZK-SNARKs to switch funds to pay for the charges! However this prices a whole lot of gasoline, an additional a whole lot of 1000’s of gasoline only for a single switch.

One other intelligent strategy includes trusting specialised transaction aggregators (“searchers” in MEV lingo). These aggregators would permit customers to pay as soon as to buy a set of “tickets” that can be utilized to pay for transactions on-chain. When a person must spend an NFT in a stealth deal with that comprises nothing else, they supply the aggregator with one of many tickets, encoded utilizing a Chaumian blinding scheme. That is the unique protocol that was utilized in centralized privacy-preserving e-cash schemes that had been proposed within the Nineteen Eighties and Nineteen Nineties. The searcher accepts the ticket, and repeatedly consists of the transaction of their bundle totally free till the transaction is efficiently accepted in a block. As a result of the amount of funds concerned is low, and it might solely be used to pay for transaction charges, belief and regulatory points are a lot decrease than a “full” implementation of this sort of centralized privacy-preserving e-cash.

## Stealth addresses and separating spending and viewing keys

Suppose that as a substitute of Bob simply having a single grasp “root spending key” that may do all the things, Bob desires to have a separate root spending key and viewing key. The viewing key can see all of Bob’s stealth addresses, however can not spend from them.

Within the elliptic curve world, this may be solved utilizing a quite simple cryptographic trick:

- Bob’s meta-address
`M`

is now of the shape`(Ok, V)`

, encoding`G * ok`

and`G * v`

, the place`ok`

is the spending key and`v`

is the viewing key. - The shared secret is now
`S = V * r = v * R`

, the place`r`

continues to be Alice’s ephemeral key and`R`

continues to be the ephemeral public key that Alice publishes. - The stealth deal with’s public secret is
`P = Ok + G * hash(S)`

and the non-public secret is`p = ok + hash(S)`

.

Discover that the primary intelligent cryptographic step (producing the shared secret) makes use of the viewing key, and the second intelligent cryptographic step (Alice and Bob’s parallel algorithms to generate the stealth deal with and its non-public key) makes use of the foundation spending key.

This has many use instances. For instance, if Bob desires to obtain POAPs, then Bob might give his POAP pockets (or perhaps a not-very-secure internet interface) his viewing key to scan the chain and see all of his POAPs, with out giving this interface the facility to spend these POAPs.

## Stealth addresses and simpler scanning

To make it simpler to scan the whole set of ephemeral public keys, one method is so as to add a **view tag** to every ephemeral public key. A technique to do that within the above mechanism is to make the view tag be one byte of the shared secret (eg. the x-coordinate of `S`

modulo 256, or the primary byte of `hash(S)`

).

This manner, Bob solely must do a single elliptic curve multiplication for every ephemeral public key to compute the shared secret, and only one/256 of the time would Bob must do extra advanced calculation to generate and examine the complete deal with.

## Stealth addresses and quantum-resistant safety

The above scheme relies on elliptic curves, that are nice however are sadly susceptible to quantum computer systems. If quantum computer systems develop into a difficulty, we would wish to change to quantum-resistant algorithms. There are two pure candidates for this: elliptic curve isogenies and lattices.

Elliptic curve isogenies are a really totally different mathematical building based mostly on elliptic curves, that has the linearity properties that permit us do related cryptographic tips to what we did above, however cleverly avoids establishing cyclic teams that could be susceptible to discrete logarithm assaults with quantum computer systems.

The principle weak spot of isogeny-based cryptography is its extremely sophisticated underlying arithmetic, and the chance that attainable assaults are hidden below this complexity. Some isogeny-based protocols were broken last year, although others remain safe. The principle energy of isogenies is the comparatively small key sizes, and the flexibility to port over many sorts of elliptic curve-based approaches instantly.

*A 3-isogeny in CSIDH, source here.*

Lattices are a really totally different cryptographic building that depends on far easier arithmetic than elliptic curve isogenies, and is able to some very highly effective issues (eg. fully homomorphic encryption). Stealth deal with schemes may very well be constructed on lattices, although designing the very best one is an open downside. Nevertheless, lattice-based constructions are likely to have a lot bigger key sizes.

*Totally homomorphic encryption, an software of lattices. FHE may be used to assist stealth deal with protocols otherwise: to assist Bob outsource the computation of checking the complete chain for stealth addresses containing belongings with out revealing his view key.*

A 3rd strategy is to assemble a stealth deal with scheme from generic black-box primitives: fundamental components that a lot of individuals want for different causes. The shared secret era a part of the scheme maps on to key exchange, a, errr… *essential* part in public key encryption methods. The tougher half is the parallel algorithms that permit Alice generate solely the stealth deal with (and never the spending key) and let Bob generate the spending key.

Sadly, you can’t construct stealth addresses out of components which are *easier* than what’s required to construct a public-key encryption system. There’s a easy proof of this: you possibly can construct a public-key encryption system out of a stealth deal with scheme. If Alice desires to encrypt a message to Bob, she will be able to ship N transactions, every transaction going to both a stealth deal with belonging to Bob or to a stealth deal with belonging to herself, and Bob can see which transactions he obtained to learn the message. That is essential as a result of there are mathematical proofs that you could’t do public key encryption with simply hashes, whereas you are able to do zero-knowledge proofs with just hashes – therefore, stealth addresses can’t be achieved with simply hashes.

Right here is one strategy that does use comparatively easy components: zero data proofs, which will be made out of hashes, and (key-hiding) public key encryption. Bob’s meta-address is a public encryption key plus a hash `h = hash(x)`

, and his spending secret is the corresponding decryption key plus `x`

. To create a stealth deal with, Alice generates a price `c`

, and publishes as her ephemeral pubkey an encryption of `c`

readable by Bob. The deal with itself is an ERC-4337 account whose code verifies transactions by requiring them to come back with a zero-knowledge proof proving possession of values `x`

and `c`

such that `ok = hash(hash(x), c)`

(the place `ok`

is a part of the account’s code). Figuring out `x`

and `c`

, Bob can reconstruct the deal with and its code himself.

The encryption of `c`

tells nobody apart from Bob something, and `ok`

is a hash, so it reveals virtually nothing about `c`

. The pockets code itself solely comprises `ok`

, and `c`

being non-public implies that `ok`

can’t be traced again to `h`

.

Nevertheless, this requires a STARK, and STARKs are huge. Finally, I feel it’s seemingly {that a} post-quantum Ethereum world will contain many purposes utilizing many starks, and so I’d advocate for an aggregation protocol like that described here to mix all of those STARKs right into a single recursive STARK to save lots of area.

## Stealth addresses and social restoration and multi-L2 wallets

I’ve for a very long time been a fan of social recovery wallets: wallets which have a multisig mechanism with keys shared between some mixture of establishments, your different gadgets and your pals, the place some supermajority of these keys can get better entry to your account in the event you lose your main key.

Nevertheless, social restoration wallets don’t combine properly with stealth addresses: if it’s important to get better your account (that means, change which non-public key controls it), you’d additionally need to carry out some step to alter the account verification logic of your N stealth wallets, and this may require N transactions, at a excessive value to charges, comfort and privateness.

The same concern exists with the interplay of social restoration and a world of a number of layer-2 protocols: in case you have an account on Optimism, and on Arbitrum, and on Starknet, and on Scroll, and on Polygon, and probably a few of these rollups have a dozen parallel situations for scaling causes and you’ve got an account on every of these, then altering keys could also be a extremely advanced operation.

*Altering the keys to many accounts throughout many chains is a large effort.*

One strategy is to chew the bullet and settle for that recoveries are uncommon and it is okay for them to be pricey and painful. Maybe you might need some automated software program switch the belongings out into new stealth addresses at random intervals over a two-week time span to cut back the effectiveness of time-based linking. However that is removed from good. One other strategy is to secret-share the foundation key between the guardians as a substitute of utilizing sensible contract restoration. Nevertheless, this removes the flexibility to *de-activate* a guardian’s energy to assist get better your account, and so is long-run dangerous.

A extra subtle strategy includes zero-knowledge proofs. Think about the ZKP-based scheme above, however modifying the logic as follows. As a substitute of the account holding `ok = hash(hash(x), c)`

instantly, the account would maintain a (hiding) dedication to the *location* of `ok`

on the chain. Spending from that account would then require offering a zero-knowledge proof that (i) you understand the placement on the chain that matches that dedication, and (ii) the thing in that location comprises some worth `ok`

(which you are not revealing), and that you’ve some values `x`

and `c`

that fulfill `ok = hash(hash(x), c)`

.

This permits many accounts, even throughout many layer-2 protocols, to be managed by a single `ok`

worth someplace (on the bottom chain or on some layer-2), the place altering that one worth is sufficient to change the possession of all of your accounts, all with out revealing the hyperlink between your accounts and one another.

## Conclusions

Primary stealth addresses will be applied pretty shortly at the moment, and may very well be a big increase to sensible person privateness on Ethereum. They do require some work on the pockets aspect to assist them. That mentioned, it’s my view that wallets ought to begin shifting towards a extra natively multi-address mannequin (eg. creating a brand new deal with for every software you work together with may very well be one possibility) for different privacy-related causes as properly.

Nevertheless, stealth addresses do introduce some longer-term usability considerations, comparable to problem of social restoration. It’s in all probability okay to easily settle for these considerations for now, eg. by accepting that social restoration will contain both a lack of privateness or a two-week delay to slowly launch the restoration transactions to the varied belongings (which may very well be dealt with by a third-party service). In the long run, these issues will be solved, however the stealth deal with ecosystem of the long run is wanting like one that will actually closely rely upon zero-knowledge proofs.