On Reusing Bitcoin Addresses

Yesterday afternoon, after reading GreenAddress.it’si blog about the evilness of reusing public addresses, I called him out on Twitter. My bold and colourful language clearly had an impactii because, next thing ya know, one of the GreenAddress crewiii dropped by IRC for a chat. What followed what a useful discussion of the security and privacy implications of reusing addresses.

Despite my apparent convictions, I’ll admit that this is a topic that I didn’t fully have my noodle around, so let’s take a step-by-step look at the address reuse debate together.

At the technical level, Bitcoin transactions involve inputs and outputs, each of which is identified by public addresses. At the party level, there’s one sender and one receiver, where the sending party signs the input(s) and the receiving party ends up with ownership of the output.iv An input controls a certain amount of bitcoin before the transaction and less afterwards. If the amount of bitcoin necessary for a transaction doesn’t exactly match one of the potential inputs controlled by the sending party’s private key, then inputs from multiple addresses will be merged to create the correct amount. For more, there’s a useful video entitled “How Bitcoin Works Under The Hood.”

Now we come to the optimization of privacy and security when conducting these transactions, and whether reusing public addresses makes sense.


On the security side, let’s specifically address GreenAddress’ claims, as set out in their blog, and see if we can’t refute a few of the points:

Not reusing addresses can protect you from a weak random number generator or buggy ECDSA implementation (see what happened on Android with their RNG).

This is exactly backwards. If a random number generator is weak, we want to rely on it less rather than more. We can certainly agree that Elliptic Curve Digital Signature Algorithm (ECDSA) isn’t perfect, and as such, we should only want to generate a single public address for that private key. If anything, creating more public addresses, creates more points of correlation to a private key and therefore increases its exposure. Since we can therefore only safely generate one address, it would have to be reused. Thankfully, as we’ll soon see, this strategy has privacy benefits as well.

Not reusing addresses protects you from quantum computing.

Quantum computing is no more a thing than cold fusion. As such, it’s about as relevant as Bitcoin 2.0.

Not reusing addresses may prevent you to be exposed from undiscovered holes in ECDSA theory.

Whether you’re reusing addresses or not, you’re exposed to ECDSA holes. If anything, more address generation is likely to expose more holes.

On the practical side, as GreenAddress mentioned in his post, unless you’re using a deterministic wallet (as GA does), you’re having to generate a new private key every time you generate new public addresses. This then means that your back-ups have to be updated as well. This is rather cumbersome given that this approach doesn’t confer any security advantages, don’t you think?


While it’s the opinion of the esteemed that “there’s no such thing as bitcoin taint,” for as long as the Bitcoin code is too fucktarded not to merge inputs, creating new addresses for every transaction inevitably results in several addresses with just a little bit of bitcoin. Eventually, for larger transactions, these addresses have to merge, tying several of your sources together. This is, of course, exactly why everyone in #bitcoin-dev, the majority of whom have the rotten luck to live in the United States of Egypt, tell you to generate new addresses for every transaction.v

Reusing addresses has the advantage of tying primarily your identity as the sender, not those of your sources. While the source of your inputs can be determined, since the blockchain is public, reusing addresses muddies the waters a bit as to the source of the specific bitcoins you’re sending.


To the person, place, or thing receiving your inputs, reusing addresses obfuscates the source of those inputs. Reusing addresses is therefore the preferred method of maintaining the privacy of your sources. Therefore, if you’re using Bitcoin-Qt/d or MultiBit, using a single address per wallet is the best practise. Since generating new wallets is free, there’s no reason not to. Also, each wallet should have a specific purpose, siloing your funds and your activities.

If you’re dead set on creating lots of public addresses, or you just want more control, you can choose a more sophisticated wallet,vi that is, one that allows you to control the input and change addresses. However, you’ll still probably end up merging inputs at some point. And if you don’t, you’re effectively just using one-address-per-wallet in a more tedious way.

Periodically, when using one-address-per-wallet, you can mothball it and switch to a new wallet. When doing this, you can blur the link between the two wallets by sending bitcoins to an exchange and withdrawing them to the new wallet in chunks, or by using a service like BitBet.us to wager on near-sure-thing and/or near-deadline bets and sending your winnings to the new wallet.vii

Overall, we’re once again reminded that Bitcoin isn’t perfect. But that doesn’t mean there aren’t best practises for security and privacy. In this case, it means creating more wallets rather than more addresses and using each wallet for a different purpose.

And perhaps the ultimate best practise tip, a heuristic for the intelligent use of Bitcoin:

Take whatever the “Core Devs” say and do the exact opposite.

___ ___ ___

  1. GreenAddress is a webwallet that uses deterministic wallets, per-transaction 2FA, multisig, and a few other interesting things. []
  2. The benefits of a deftly wielded vocabulary are less clear in dat rap game. O else da Wu Tang Clan wud be biggah dan Jay-Z, Kanye, an Drake put togeva. Speaking of rap slang, writing in such a vernacular is a fun way to write a car review, y’heard. []
  3. Likely either Lawrence or Jerzy, but maybe Pietro or Alessandro? You can see their profiles here. []
  4. The caveat here is that, if there’s more value in the input(s) than the output, the “change” is sent back to the sending party as a new output. This works similarly to cash. []
  5. mircea_popescu: GAit the problem is this : i’m pretty well convinced, and i suspect a lot of people here are similarly convinced,
    mircea_popescu: that a campaign against reusing addresses is more a covert usg op than anything else.
    mircea_popescu: now whether you’re participating naively or not is up for grabs, but still. []
  6. More sophisticated wallets include Armory and Electrum on the desktop side and Blockchain.info on the web side. Keep in mind, as sophisticated as Blockchain.info’s webwallet is, it’s still a webwallet, and that means that it’s still not a safe place to keep much value. Lest we forget what happened to Fr33Aid. []
  7. Disclaimer: BitBet is still gambling, no matter how sure something seems. Sending bitcoins to an exchange and withdrawing them to a new wallet carries a small cost but far less risk. []

9 thoughts on “On Reusing Bitcoin Addresses

  1. jurov says:

    creating new addresses for every transaction inevitably results in several addresses with just a little bit of bitcoin.
    This does not make any difference versus sending stuff to one address. All the outputs/inputs must be explicitly named in the transaction that spends them, regardless if it uses multiple outputs from only one or from more addresses. Just try it yourself.

    So I’m very sceptical about muddying anything by reusing one address.

    • Bitcoin Pete says:

      Reusing addresses doesn’t create complete anonymity, but it does create useful ambiguity.

    • jurov says:

      Please ELI5 where is any substantial difference between:

      Source1 -> utxo1@MyNeverReusedAddr1 -> Spent
      Source2 -> utxo2@MyNeverReusedAddr2 ^


      Source1 -> utxo1@MyAddr – > Spent
      Source2 -> utxo2@MyAddr ^

      You are spending 2 distinguishable unspent outputs in both cases.

  2. […] Jurov manages to misrepresent the problem on Bitcoinpete’s blog with the following comment : […]

  3. pankkake says:

    “we should only want to generate a single public address for that private key”.

    Private keys have only one address. Each Bitcoin address is a separate public key and private key. Which makes backups annoying, unless you use a client which creates the private keys from a seed (deterministic wallets).

    However it is true that if your random generator is weak, showing more public keys can expose you.

    • dexX says:

      Actually you can create two public keys and therefore addresses from one private key – there is a compressed and an uncompessed form. Compressed can be transformed into uncompressed and vice versa. If you like visual feedback, try the generator on http://brainwallet.org/ — the “secret exponent” is the “raw private key”.

      Deterministic key generators work like this:

      k0: some key
      k1: non reversible function applied on k0
      k2: non reversible function applied on k1

      kn: non reversible function applied on kn-1

      The specifics are over my head, but just for the reference:


  4. […] One manner in which Bitcoin users can protect themselves from this is, broadly speaking, offline storage. If, for example, your wallet lives on an airgapped computer and isn’t exposed to the Internet, a large number of attack vectors are eliminated, though physical theft, fire, flood, natural disaster, and hard drive failures are still very much on the table. This latter angle can be eliminated with USB backups, but all things digital being also corruptible, we can use high-entropy paper wallets instead. Not that paper wallets don’t have their drawbacks, ink and paper can still fade and QR codes can become unreadable. Neither method is perfect even if they’re far and away more sane than, say, some fucking webwallet with multisig. […]

  5. […] Bitcoin Expo 11. The Brokenness of MaidSafe.ii 12. Bitcoin: Killer of Nietzschian Nihilism 13. On Reusing Bitcoin Addresses 14. Tell The Grand Inquisitor There’s No Fucking Bitcoin Taint. 15. How A Bigger Blockchain Is […]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>