<p>Alice gets her computer hacked by Mallory, and she steals her wallet. Fortunately, Alice had encrypted it with a strong passphrase. Alice wants to sue Mallory for breaking into her computer, so she gets a lawyer, Bob.</p>

<ul>
<li>Alice's address, 10BTC --> Bob's address</li>
</ul>

<p>Unfortunately for Alice, Mallory controls a node on the Bitcoin network, not too far from Alice, that quickly sees the transaction is from Alice (she has all her addresses), and instead relays, to hundreds of nodes at once, the transaction:</p>

<ul>
<li>Mallory's address, 1000 satoshis --> Bob's address</li>
</ul>

<p>Which is incompatible with Alice's honest transaction.</p>

<p>Now, three things happen:</p>

<p>1) Alice tries to send the bitcoins to a different address given by Bob</p>

<p>2) Alice's nodes see her transaction as a double spend, and refuse to relay any transaction spending that coin to a different address</p>

<p>3) Mallory's transaction eventually gets mined. Back to trying to spend the coins to Bob.</p>

<p>Mallory can do other mischievous things with her position, such as allowing Alice to spend her bitcoin at a church fundraiser but not an abortion clinic (assuming she knows the address of both).</p>

<p>The main way people lose their privacy in bitcoin today is through heuristic analysis of the blockchain, not address reuse. Introducing a new network rule to protect users against their own stupidity will not significantly improve privacy (most wallets don't reuse addresses by default anyway), and opens up users to some interesting attacks.</p>

CC BY-SA 3.0
2016-11-18T21:40:39.527Z
I don't understand your reasoning. Mallory does not have access to Alice's private keys (Alice's wallet is encrypted). Also even if Mallory does not relay Alice's transaction, other nodes will. It takes time to compose a new tx, in that time Alice's tx would reach 100's of nodes. Address reuse makes heuristic analysis easier.
Albert S
CC BY-SA 3.0
2016-11-18T23:21:21.643Z
Mallory *would* need Alice's keys to make a double spend of Alice's coin. But here we're talking about a double *receive*, not a double spend. The proposal is to make a transaction invalid if that output script has ever been included in a block. This means any nodes that see Mallory's transaction first would refuse to relay Alice's, as otherwise the network could be DoS'ed for free by sending millions of transactions to one address. Mallory only needs Alice's address to do this, not her private key.
maservant
CC BY-SA 3.0
2016-11-18T23:25:57.580Z
As for "It takes time to prepare a new tx", yes, but it can be done in advance: Mallory signs a transaction with one output signed and another not signed, using clever SigHash flags. As soon as she sees Alice's transaction, she just plugs Bob's address into the unsigned output, which costs only a memcpy(), no crypto required.
maservant
CC BY-SA 3.0
2016-11-19T18:53:52.247Z
Yes, i do follow now, thanks. What about all the other nodes that would receive the original tx from Alice, don't you think that one would propagate faster? I do agree with the DoS attack here. However, we can add a requirement that the fee will be spent in those txs. (I mean there would be a cost to send invalid txs) Nevertheless, like I said this is meant to stimulate the conversation, there must be a way to design this somehow in such a way that does not open new attack vectors.
Albert S
CC BY-SA 3.0
2016-11-19T22:58:59.400Z
Suppose Mallory controls enough well-connected nodes to make her transaction reach 90% of hashpower before Alice's. This means Alice has a 10% chance of success. A law firm was probably a bad example, as Alice can just retry until her transaction gets accepted (which will eventually happen with 100% probability), only paying the fee once. If Bob gets paid in two days, he won't mind, and Mallory pays a fee for each attack tx until Alice succeeds. If Alice were at a grocery store, Mallory's attack would be more annoying.
maservant
CC BY-SA 3.0
2016-11-19T23:04:53.520Z
Mallory has a better trick up her sleeve, though. She can make a promise to recursively block every transaction tainted with Alice's initial output to Bob. If she convinces enough people that her attack will be successful, Alice's coins will lose value and no longer be fungible, as they will take ages to spend, and will require higher fees to be spent successfully. If Bob is economically rational, he will reject Alice's cursed coin, unless he has a good coin tumbler handy.
maservant
CC BY-SA 3.0
2016-11-15T22:36:22.500Z
2016-11-15T22:36:22.500Z
maservant
<blockquote>
  <p>I guess there would need to be a way of quickly looking up if an
  address was already "used-up".</p>
</blockquote>

<p>There is, in Bitcoin. Just paste the address into the search box (not the one in the header) on <a href="https://blockchain.info" rel="nofollow noreferrer">https://blockchain.info</a>.</p>

<p>Regarding your creation of a new address: Not only is this impossible in the way things are done currently, but it's furthermore contradictory to your goal of enhanced privacy.</p>

<p>First of all, let's talk about the current situation. Addresses are hashes of public keys (simplified). Those public keys are cryptographically associated with private keys which only the owner of them knows because knowing them enables one to spend the money which has been sent to the addresses associated with them. Hashes are one-way, meaning that you can determine the hash of something but not that something given only the hash. In order to pay to a different address belonging to the recipient, you either had to do a known function like incrementing by 1 on the private key – which is impossible not only because you can't find the public key given its hash but also because you can't find the private key given the public key – or somehow access a list of addresses of the recipient which would subvert the goal of increased privacy.</p>

<p>Now to all fictional situations, so all specifics of Bitcoin are dropped in this paragraph. If I'm the first one to pay to Mr. Smith's address <code>1e9Kp22</code> and you want to pay to that same address 5 minutes later, you have to get a new address. There can be either one or several addresses which can come after <code>1e9Kp22</code> but there certainly only is a small number of them so Mr. Smith can find the correct one. Let <code>Φ(α)</code> be the set of all addresses which are the possible next addresses after address α. In this general, fictional situation, we can't exclude the possibility of just being able to create new addresses belonging to Mr. Smith without undermining the exclusive right of the owner of coins the spend them. Since you can find a <code>φ ∈ Φ(α)</code> to pay to and know nothing more than me and <code>∀α∈Addreses : |Φ(α)| small</code>, I can find your <code>φ</code> by just finding all elements of <code>Φ(α)</code> and examining which ones money has been paid to. Because we now both know that <code>1e9Kp22</code> belongs to Mr. Smith and I just learned that <code>φ</code> belongs to Mr. Smith, too, we both know that the address the other person used belongs to Mr. Smith.</p>

<p>The simple solution of this issue in practice is to just give a different address out for each expected payment, for example for each purchase in a web shop. Why would the shop owner give us both the same address in the first place? Addresses are completely free.</p>

CC BY-SA 3.0
2016-11-15T23:02:42.300Z
2016-11-15T23:02:42.300Z
UTF-8
<p>Most users reuse their addresses for deposits (ie. they receive money more than once on a given address).<br>
Can the protocol be designed in such a way that an address can be used only once as an output in a transaction?<br>
I guess there would need to be a way of quickly looking up if an address was already "used-up".<br>
Also there would need to be a way to somehow to get "next address". For eg if an address is used for dividends and it can be used only once, the dividend payer should be able to automatically get a new address without the owner's (payee's) repeated input. (a one time set up of this, would be ok)<br>
The point of this is to enhance privacy.</p>

<p>These are just thoughts, comments welcome.</p>

CC BY-SA 3.0
2016-11-18T21:43:12.200Z
I believe Android Bitcoin Wallet 4 discourages address reuse by always displaying a fresh address automatically.
Albert S
<privacy><address-reuse>
Can we design the protocol, so that an address can only be used once as an output in a transaction?
Albert S
# Can we design the protocol, so that an address can only be used once as an output in a transaction?

(Asked by: username_0 on 2016-11-15)

Most users reuse their addresses for deposits (ie. they receive money more than once on a given address).  
Can the protocol be designed in such a way that an address can be used only once as an output in a transaction?  
I guess there would need to be a way of quickly looking up if an address was already "used-up".  
Also there would need to be a way to somehow to get "next address". For eg if an address is used for dividends and it can be used only once, the dividend payer should be able to automatically get a new address without the owner's (payee's) repeated input. (a one time set up of this, would be ok)  
The point of this is to enhance privacy.

These are just thoughts, comments welcome.

**Tags:** privacy, address-reuse

> **Comments:**
> **username_0**: I believe Android Bitcoin Wallet 4 discourages address reuse by always displaying a fresh address automatically.  

---

## 2 answers

### Answer by username_1 on 2016-11-15. Score: 1

Alice gets her computer hacked by Mallory, and she steals her wallet. Fortunately, Alice had encrypted it with a strong passphrase. Alice wants to sue Mallory for breaking into her computer, so she gets a lawyer, Bob.

* Alice's address, 10BTC --> Bob's address

Unfortunately for Alice, Mallory controls a node on the Bitcoin network, not too far from Alice, that quickly sees the transaction is from Alice (she has all her addresses), and instead relays, to hundreds of nodes at once, the transaction:

* Mallory's address, 1000 satoshis --> Bob's address

Which is incompatible with Alice's honest transaction.

Now, three things happen:

1) Alice tries to send the bitcoins to a different address given by Bob

2) Alice's nodes see her transaction as a double spend, and refuse to relay any transaction spending that coin to a different address

3) Mallory's transaction eventually gets mined. Back to trying to spend the coins to Bob.

Mallory can do other mischievous things with her position, such as allowing Alice to spend her bitcoin at a church fundraiser but not an abortion clinic (assuming she knows the address of both).

The main way people lose their privacy in bitcoin today is through heuristic analysis of the blockchain, not address reuse. Introducing a new network rule to protect users against their own stupidity will not significantly improve privacy (most wallets don't reuse addresses by default anyway), and opens up users to some interesting attacks.

> **Comments:**
> **username_0**: I don't understand your reasoning. Mallory does not have access to Alice's private keys (Alice's wallet is encrypted). Also even if Mallory does not relay Alice's transaction, other nodes will. It takes time to compose a new tx, in that time Alice's tx would reach 100's of nodes. Address reuse makes heuristic analysis easier.  
> **username_1**: Mallory *would* need Alice's keys to make a double spend of Alice's coin. But here we're talking about a double *receive*, not a double spend. The proposal is to make a transaction invalid if that output script has ever been included in a block. This means any nodes that see Mallory's transaction first would refuse to relay Alice's, as otherwise the network could be DoS'ed for free by sending millions of transactions to one address. Mallory only needs Alice's address to do this, not her private key.  
> **username_1**: As for "It takes time to prepare a new tx", yes, but it can be done in advance: Mallory signs a transaction with one output signed and another not signed, using clever SigHash flags. As soon as she sees Alice's transaction, she just plugs Bob's address into the unsigned output, which costs only a memcpy(), no crypto required.  
> **username_0**: Yes, i do follow now, thanks. What about all the other nodes that would receive the original tx from Alice, don't you think that one would propagate faster? I do agree with the DoS attack here. However, we can add a requirement that the fee will be spent in those txs. (I mean there would be a cost to send invalid txs) Nevertheless, like I said this is meant to stimulate the conversation, there must be a way to design this somehow in such a way that does not open new attack vectors.  
> **username_1**: Suppose Mallory controls enough well-connected nodes to make her transaction reach 90% of hashpower before Alice's. This means Alice has a 10% chance of success. A law firm was probably a bad example, as Alice can just retry until her transaction gets accepted (which will eventually happen with 100% probability), only paying the fee once. If Bob gets paid in two days, he won't mind, and Mallory pays a fee for each attack tx until Alice succeeds. If Alice were at a grocery store, Mallory's attack would be more annoying.  
> **username_1**: Mallory has a better trick up her sleeve, though. She can make a promise to recursively block every transaction tainted with Alice's initial output to Bob. If she convinces enough people that her attack will be successful, Alice's coins will lose value and no longer be fungible, as they will take ages to spend, and will require higher fees to be spent successfully. If Bob is economically rational, he will reject Alice's cursed coin, unless he has a good coin tumbler handy.  

---

### Answer by username_2 on 2016-11-15. Score: 0

> I guess there would need to be a way of quickly looking up if an
> address was already "used-up".

There is, in Bitcoin. Just paste the address into the search box (not the one in the header) on <https://blockchain.info>.

Regarding your creation of a new address: Not only is this impossible in the way things are done currently, but it's furthermore contradictory to your goal of enhanced privacy.

First of all, let's talk about the current situation. Addresses are hashes of public keys (simplified). Those public keys are cryptographically associated with private keys which only the owner of them knows because knowing them enables one to spend the money which has been sent to the addresses associated with them. Hashes are one-way, meaning that you can determine the hash of something but not that something given only the hash. In order to pay to a different address belonging to the recipient, you either had to do a known function like incrementing by 1 on the private key – which is impossible not only because you can't find the public key given its hash but also because you can't find the private key given the public key – or somehow access a list of addresses of the recipient which would subvert the goal of increased privacy.

Now to all fictional situations, so all specifics of Bitcoin are dropped in this paragraph. If I'm the first one to pay to Mr. Smith's address `1e9Kp22` and you want to pay to that same address 5 minutes later, you have to get a new address. There can be either one or several addresses which can come after `1e9Kp22` but there certainly only is a small number of them so Mr. Smith can find the correct one. Let `Φ(α)` be the set of all addresses which are the possible next addresses after address α. In this general, fictional situation, we can't exclude the possibility of just being able to create new addresses belonging to Mr. Smith without undermining the exclusive right of the owner of coins the spend them. Since you can find a `φ ∈ Φ(α)` to pay to and know nothing more than me and `∀α∈Addreses : |Φ(α)| small`, I can find your `φ` by just finding all elements of `Φ(α)` and examining which ones money has been paid to. Because we now both know that `1e9Kp22` belongs to Mr. Smith and I just learned that `φ` belongs to Mr. Smith, too, we both know that the address the other person used belongs to Mr. Smith.

The simple solution of this issue in practice is to just give a different address out for each expected payment, for example for each purchase in a web shop. Why would the shop owner give us both the same address in the first place? Addresses are completely free.


---

