From address

Relying on things that seem like ‘from’ addresses would be like:

• Getting on a train/bus that just arrived from where you want to go, in the hope that all trains/buses always turn around and head back the way they came.
• Trying to reply to mail you received in a re-used envelope — by peeling the sticker bearing your address off, and using the previous address you find underneath.
• Looking at the routing and account numbers on a cheque you received, and then sending money to those numbers.

The concept of a “from address” is inextricably entwined with transaction linkability. Since Bitcoin has no “from address” in its design, the closest substitute in practice is a prior receiving address. By implication, and usually without realizing it, people who speak of a “from address” assume that the money they receive must have been previously received at an address which can reliably discovered and linked in a chain of transactions.

In addition to the other problems listed on this page, transactional linkability destroys privacy. To protect privacy, there are active efforts in Bitcoin to make transactions unlinkable; in the abstract, this causes Bitcoin to behave somewhat more like bearer instruments, such as cash or gold coins. When you receive a physical currency note or a physical coin, there is obviously no “from address”; and you cannot attempt to construct one by examining the transactional history of the note or coin.

At the protocol level, when looking at a transaction in isolation as it appears on the wire or in a block, no part of it directly encodes a “from”. A transaction provides solutions for some challenges and poses some new challenges, both in the form of scripts[1] . Here’s one way to depict that for a transaction like e9e2....5063:

None of the prev_outs in the decoded version directly encode addresses in any form. It does encode indirect references to unspent coins, and maybe for some unspent coins you can infer something about their previous destination, but conceptually those are at best references to previous “to” addresses. Even that inference is not always sensible (advanced transactions will probably defeat most block explorers) and is never necessary or appropriate in everyday use of Bitcoin. The rest of this post will use the term “last-sent-to address”[2].

Many web wallets/exchanges[1] (shared wallets) manage addresses and private keys for you, and pool all deposited coins. After you deposit coins to such a site they will almost always use coins you deposited to fulfill other customers’ withdrawals, maintaining your balance only as a centralised database entry. Similarly, when you go to withdraw coins to an external address, your withdrawal will probably consist entirely of coins last-sent-to some other customer’s deposit address and/or addresses used purely internally by the site to receive change.

FIXME: diagram of typical shared wallet coin-pooling, picturing your freshly deposited coins being used satisfy another customer’s withdrawal, then someone else’s coins being used to satisfy yours.

In that case, the address Monica’s coins were last-sent-to might just be the deposit address of a completely unrelated user of the same shared wallet Monica uses, or at best, a change address used purely internally by the shared wallet, not associated with any particular user. Either way, Monica would be unlikely ever to recover what you sent.

This wouldn’t be a problem if the last-sent-to address[2] was created with a local wallet such as Bitcoin QT, Electrum or Multibit — but you can’t safely assume that, and even if you know Monica used a local wallet recently she may have changed her habits when creating that address, or switched wallets since.

This doesn’t mean shared wallets are misbehaving by pooling deposits; it’s necessary for keeping most coins in cold storage. The model has other benefits too; they can make more efficient use of block space (and reduce fees as a result) by grouping withdrawals [3] and by handling transfers between customers internally, and provided they protect/expire their logs, they increase privacy.

Monica may have lost all copies of the last-sent-to address’s private key since paying you, so you may be destroying coins by sending them there. While this is unlikely if the interval is short, there are a multitude of ways to lose data:

• accidental/naïve deletion; especially:
  • switching devices without keeping old wallet data
  • switching wallet software without keeping old wallet data
  • spending a paper wallet or “physical” bitcoin then discarding it
• physically losing the media
• data corruption
• device failure
• forgotten password or death of the owner
• bad app uninstall procedures

and most people are pretty poor at keeping suitably regular/redundant backups. Even if Monica is fantastic at keeping regular backups, perhaps the private key is physically distant or requires some tedious recovery procedure, so it might be very inconvenient.

Monica may have had her private keys extracted from her by an attacker:

• fallen prey to malware
• been socially engineered
• been physically robbed/mugged
• suffered from a bug in a common wallet

or may have been negligent with it/underestimated attacks:

• used a weak password
• left her phone/laptop unattended and unlocked
• used her wallet from a USB stick in an Internet café

and have taken measures to recover, generating fresh keys/addresses.

Another way Monica might not have exclusive control of the key is if she received the coins by someone handing her a paper wallet, as a present or tip. While a careful giver would be sure to wipe the private key from their wallet once they were sure it was spent, they may have forgotten, gone rogue or fallen victim to a wallet-stealing malware themselves.

If Monica received those coins she used to pay you at a multisignature address, she may now lack sufficient signing keys to release anything you send there, and it may be inconvenient or impossible for her to get signatures from the other keyholders. For instance, maybe she used Bitrated and had a dispute resolved in her favour but the arbitrator she chose since discarded or lost their key, went rogue or died. Multisignature addresses are just one use of pay-to-script-hash, so you can’t even infer that a pay-to-script-hash is a multisignature address; she may have used a more exotic variety.

Even if she received those coins with pay-to-pubkey-hash transactions[1], her transaction to you may have consumed multiple inputs. How are you going to distribute your repayment between those? Equally? Pick one at random? Existing use of CoinJoin probably involves people participating in a join between external transactions, as a separate privacy enhancement step, but as more implementations appear perhaps clients will support direct payments via CoinJoins. That would be a similar situation to the shared wallets point above.

This is more about respecting a payee’s preferred payment method and making life easy for them than about avoiding loss. To ease accounting (and other reasons) Monica might always create a dedicated address for every receive, and label it with the name of the expected sender and purpose of the transaction. If you send to an address Monica gave out to her employer, her accounts won’t balance. Assuming her employer and you both follow best practices regarding privacy/address re-use, she can’t tell anything about the mystery incoming funds with any certainty.

In some business (and perhaps tax return) situations having an inexplicable imbalance on an account can be a serious compliance problem; while folks in that situation could delete all related keys to prevent that, you can’t be sure they have and even if they did, you’re destroying coins.

Established security best practices discourage address re-use because when Monica sends you the restaurant bill, she reveals the public key for the last-sent-to address; before that, the world knew only the address (a hash of the public key) and would have had to perform a pre-image attack to find the public key. While it’s pretty unlikely, ECDSA is relatively new and could be found to be weak; private keys may somehow be found to be easily derived from public ones, exposing any unspent coins where the public key is known.

Re-using addresses also probably increased the losses suffered via the Android SecureRandom bug, since exploiting it required seeing two transactions with the same last-sent-to and the same r values.

The discoverers of the OpenSSL ECDSA “FLUSH+RELOAD” attack estimated that under the right conditions they could recover a private key by observing as few as 200 signatures (in Bitcoin’s case, typical transactions) made with it.

Hopefully those are the last bugs we’ll see related to re-use, but we can’t be sure.

Since it’s Monica’s money at stake here, the decision on whether these threats are significant should be up to her.

Established privacy best practices discourage address re-use because it reduces privacy both for you and, infectiously, for all other users (most directly, people you transact with, but also to a lesser extent the people they transact with, and so on). Even if you feel the simpler key management is worth the privacy cost to you and the rest of the network, it’s more polite to avoid inflicting that cost on Monica any more than you already are — again, you should let her make her own decision on this.