<p>Provided the second transaction is spending inputs that have not been spent, yes. </p>

<p>There is no logic or rule that checks to ensure public key uniqueness for an address. As long as you can fulfill the signature and Hash160 checks, the transaction is valid.</p>

CC BY-SA 4.0
2018-06-19T23:58:18.027Z
2018-06-19T23:58:18.027Z
Raghav Sood
<p>In a typical case of finding a collision with an address, as long as the private key provided has a consistent public key that hashes to the address, then the coins in that address can be spent. The problem is that this assumes the collided address only has incoming transactions, and never an outgoing transaction. This is because that means the public key was never revealed but the address still has coins. In order for a transaction to be valid, it has to have a valid public key to verify the signature.</p>

<p>My question is this: if two outgoing transactions are made for the <strong>same address</strong> but with <strong>two different public keys</strong> (found by a collision), can the second transaction be confirmed if the first was already confirmed? Logically, the "righteous owner" of an address wouldn't have two distinct private/public key pairs for the same address (excluding multisigs), because that wouldn't make sense. Do clients even store the public key of transactions if they already confirmed it?</p>

<address><address-generation><attack><ecdsa><key-collision>
Hypothetical Scenario - Address collision with address with already confirmed outgoing transaction
Expectator
# Hypothetical Scenario - Address collision with address with already confirmed outgoing transaction

(Asked by: username_0 on 2018-06-19)

In a typical case of finding a collision with an address, as long as the private key provided has a consistent public key that hashes to the address, then the coins in that address can be spent. The problem is that this assumes the collided address only has incoming transactions, and never an outgoing transaction. This is because that means the public key was never revealed but the address still has coins. In order for a transaction to be valid, it has to have a valid public key to verify the signature.

My question is this: if two outgoing transactions are made for the **same address** but with **two different public keys** (found by a collision), can the second transaction be confirmed if the first was already confirmed? Logically, the "righteous owner" of an address wouldn't have two distinct private/public key pairs for the same address (excluding multisigs), because that wouldn't make sense. Do clients even store the public key of transactions if they already confirmed it?

**Tags:** address, address-generation, attack, ecdsa, key-collision


---

## 1 answers

### Answer by username_1 on 2018-06-19. Score: 2 | Accepted answer

Provided the second transaction is spending inputs that have not been spent, yes.

There is no logic or rule that checks to ensure public key uniqueness for an address. As long as you can fulfill the signature and Hash160 checks, the transaction is valid.


---

