[Tracker] Stealth Address Support

[justusranvier]

This thread is to track the progress of stealth address support in various Bitcoin clients.

In order for stealth addresses to be useful, it's necessary for Bitcoin clients to support sending funds to them, even if those clients do not support receiving funds via a stealth address.

To accelerate this process, anyone who would like to see stealth addresses become a standard feature of the Bitcoin landscape should ask the developers of their wallets they use to support at least sending to stealth addresses. Since in some cases the developers may be reluctant to add this feature and may be unwilling (or unable) to explain why, asking them in a public forum is best so that their answer - or refusal to answer - is also public.

Please feel free to create feature requests, etc for clients that aren't in this list and link them in this thread so I can add them to this post.

sx
Status: supports sending and receiving

http://sx.dyne.org/stealth.html

Dark Wallet
Status: supports sending and receiving

https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth

Electrum
Status: Sending support:: https://github.com/spesmilo/electrum/pull/817

Bitcore
Status: Sending support: https://twitter.com/ryanxcharles/status/514224778052243456

https://gist.github.com/ryanxcharles/1c0f95d0892b4a92d70a
https://github.com/ryanxcharles/bitcore2/blob/master/lib/expmt/stealthmessage.js
https://github.com/ryanxcharles/bitcore2/blob/master/lib/expmt/stealthaddress.js

btcwallet
Status: interested, no immediate plans: https://github.com/conformal/btcwallet/issues/90

airBitz
Status: "very interested", no immediate plans https://twitter.com/anonymouscoin/status/496513836133154816

Mycelium
Status: Tentatively interested: https://twitter.com/MyceliumCom/status/500327004022243328

Coinkite
Status: "at some point": https://twitter.com/Coinkite/status/509489249826373632

Armory
Status: no official comment: https://github.com/etotheipi/BitcoinArmory/issues/226

Blockchain
Status: unknown

Bitcoin-Qt
Status: unknown

Multibit
Status: unknown

Coinbase
Status: unknown

[1714177034]

1714177034

[1714177034]

1714177034

[justusranvier]

From IRC:

2014-08-04T16:12:34 <@jrick>I marked the issue as low prio for now since there are just other things that need to happen first, but I would like to see support for it in btcwallet

[gmaxwell]

Petertodd claimed to be working on a BIP and reserved a number but hasn't proposed any text. https://github.com/bitcoin/bips/blob/master/bip-0063.mediawiki

New address types should not see widespread use without extensive review for cryptographic and privacy weaknesses and functionality footguns. This really needs a clear specification.

[justusranvier]

New address types should not see widespread use without extensive review for cryptographic and privacy weaknesses and functionality footguns. This really needs a clear specification.

All true, and at the same time we don't want this to turn into a Waiting for Godot situation.

"Inadequate review" could be a great excuse to pigeonhole the functionality indefinitely.

[justusranvier]

In addition, stealth addresses only need to be better than the current standard of "publish a static address that anyone can look up in blockchain.info" in order to represent an improvement. The only thing they could possibly get wrong and be worse than what we have now is leak private keys.

[gmaxwell]

There are a great many things that can be done wrong— including the fact that a poorly done reusable-address proposal can preclude adoption of a good and usable one ("We've already got that, low priority to add another one",  "We're not going to spent time on that— as you can see it's not widely used"). An early flaw was already avoided where it would be incompatible with having a third party scan for you or hardware wallets... lots of stuff to possibly get wrong in this space.

Already we seem to have not learned from the experience with this kind of address in Bytecoin/Monero/etc.—  Payment IDs are an important feature but also a usability challenge with the way they're implemented in BCN/XMR/.... Right now with the way dark wallet implements this if you ask two different parties to pay you with the same address and only one of them does, you cannot tell which one paid you.

[justusranvier]

Already we seem to have not learned from the experience with this kind of address in the Bytecoin/Monero space— the payment IDs are an important feature but also a usability challenge with the way they're implemented there. Right now with the way dark wallet implements this if you ask two different parties to pay you with the same address and only one of them does, you cannot tell which one paid you.

I don't think stealth addresses are ever going to be appropriate for anything other than online tip jars. They do a great job in that role.

If you want to know who has paid you, then you should give them an xpub specific to them and let them use that from that point on.

See my comment on this gist:
https://gist.github.com/ryanxcharles/1c0f95d0892b4a92d70a

[justusranvier]

Maybe they need to be renamed to "tip addresses" or something to make sure people don't use them in situations where they are not appropriate.

[genjix]

Hi, sx supports stealth. I wrote these commands to aid developers as a debugging tool:

http://sx.dyne.org/stealth.html

for anonymity I don't want people to differentiate payments sent to me. If it's needed you can already shard payments by grinding the prefix to differentiate. https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth#Comparing_prefixes

I prefer a simple proposal that does one thing rather than trying to second guess every possible future use case we're not aware of yet. It's the UNIX philosophy: https://en.wikipedia.org/wiki/Worse_is_better

[justusranvier]

Already we seem to have not learned from the experience with this kind of address in Bytecoin/Monero/etc.—  Payment IDs are an important feature but also a usability challenge with the way they're implemented in BCN/XMR/.... Right now with the way dark wallet implements this if you ask two different parties to pay you with the same address and only one of them does, you cannot tell which one paid you.

How is this any different than the problem we have right now without stealth addresses?

1) Some merchant uses a blockchain.info wallet containing a single address to accept payments (yes, people really do this).
2) They give the address to two customers.
3) Only one customer pays.
4) Merchant doesn't know which customer paid without asking them.

It doesn't make sense to delay stealth addresses because they don't solve every problem.

[gmaxwell]

Already we seem to have not learned from the experience with this kind of address in Bytecoin/Monero/etc.—  Payment IDs are an important feature but also a usability challenge with the way they're implemented in BCN/XMR/.... Right now with the way dark wallet implements this if you ask two different parties to pay you with the same address and only one of them does, you cannot tell which one paid you.

How is this any different than the problem we have right now without stealth addresses?

1) Some merchant uses a blockchain.info wallet containing a single address to accept payments (yes, people really do this).
2) They give the address to two customers.
3) Only one customer pays.
4) Merchant doesn't know which customer paid without asking them.

It doesn't make sense to delay stealth addresses because they don't solve every problem.

Virtually all merchants (and, by definition, all competent merchants) use unique addresses in Bitcoin. This is widely supported, widely practiced, etc.   The fact that you can screw it up and a few people do is no excuse to make an uncommon mistake mandatory.

"Stealth addresses" as currently proposed break what already works pretty severely— using a different address per user makes scanning have a quadratic cpu costs in the number of payments you receive. Bytecoin/monero/etc. have payment IDs which address the issue, though the don't have a way to serialize them with the address— so they get accidentally left out a lot, which seems like an easy-to-address shortcoming.

Making stealth addresses "tip jar only" makes them far less interesting. There is no reason that all payments couldn't be done with this kind of address— assuming it was well constructed, and users would be much less private if only a narrow usecase uses them.

[gmaxwell]

On the Payment Ids issue - if 2 people are sending to me anonymously why not create a "satoshi" string at the end.
For example
Justus owes me 1 BTC as does you for a service -
I work with Justus and have him send me 1.00001234 string and gmaxwell is 1.00001235

Thats pretty inefficient and not very private.  It would be straightforward enough to just allow a suffix on addresses e.g. 

B123456789BCDFG-00001  and encrypt the suffix using the negotiated  ephemeral key and include it in the aux data.

[justusranvier]

There is no reason that all payments couldn't be done with this kind of address— assuming it was well constructed, and users would be much less private if only a narrow usecase uses them.

So the entire Bitcoin ecosystem should wait around for your NIH solution to be ready instead of taking advantage of the immediate improvement that's available right now?

[genjix]

can you explain payment ids? how do users make sense of the data?

say a website posts a single address, users send payments to it... at some point the user has to send something to the website so they know which payment is which... why don't they just transmit the decrypted shared secret that only the sender should have? that way the website knows it was them that sent the payment.

or if the website sends a nonce to the user so they can make repeating payments then the website can issue the same stealth address but with different prefixes for each user. that makes it highly efficient for the website to receive payments by scanning a single stealth address and separating based on their stealth_prefix into different users.

[justusranvier]

https://twitter.com/anonymouscoin/status/496513836133154816

[laurentmt]

"Stealth addresses" as currently proposed break what already works pretty severely— using a different address per user makes scanning have a quadratic cpu costs in the number of payments you receive. Bytecoin/monero/etc. have payment IDs which address the issue, though the don't have a way to serialize them with the address— so they get accidentally left out a lot, which seems like an easy-to-address shortcoming.

Seems to me that the payment protocol solves this problem. The merchant should look for tx(s) received in Payment messages, not for stealth payments.

[justusranvier]

Bitcore PoC: https://github.com/ryanxcharles/bitcore2/blob/master/lib/expmt/stealthmessage.js

[BurtW]

If I want to actually use a stealth address right now, for example publish one in my signature, what are my options?

If I were to publish a stealth address in my signature would anyone be able send me BTC?

Has the specification been completed or are the details still being hashed out?  If there is a specification where can it be found?

I obviously really like this idea and I just want to get a sense of where we are at on it and learn more about the technical details with an eye to contributing in some way.

Privacy/fungibility is a hot topic item for me.  I am a very experienced programmer (>30 years of experienced) with very good cryptographic and Bitcoin knowledge.  Where is the most effective and current work being done on this idea?  In other words, where would I go to be most effective in my contributions?

[justusranvier]

If I want to actually use a stealth address right now, for example publish one in my signature, what are my options?

If I were to publish a stealth address in my signature would anyone be able send me BTC?

Right now I believe you'd have to be using Dark Wallet to receive stealth address payments.

Also, only Dark Wallet is capable of sending to stealth addresses, but as noted above at least one other client is actively working to implement DW-compatible stealth addresses

Has the specification been completed or are the details still being hashed out?  If there is a specification where can it be found?

It's complete enough to be implemented in Dark Wallet (which Works For Me, despite it's scary alpha warning)

This the only documentation I know of:

https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth

[BurtW]

Thanks!  I will read up on it.

gmaxwell:  what is your opinion on this?  Seems like you are saying that it is a good idea but not yet ready for prime time (needs more work)?  Or, is the DW specification good enough to implement in other wallets and get this thing off the ground?