<p>To phrase the question in my own words: Can you prove that a transaction output was unlocked with a different private key than originally intended?</p>

<p>Short answer: You can or can't, depending on the situation.</p>

<hr>

<p>A standard transaction output script works like this:</p>

<ol>
<li>Assume that the stack starts with two items, with the public key on top and the signature below.</li>
<li>Duplicate the public key (topmost item).</li>
<li>Compute its hash.</li>
<li>Push the expected hash, which is the payee's address (20-byte SHA-256 + RIPEMD-160 hash).</li>
<li>Compare and assert that the top two items are equal.</li>
<li>Restore the stack to the initial state, and use the two items to check the signature.</li>
</ol>

<p>A standard transaction input script works like this:</p>

<ol>
<li>Push the signature.</li>
<li>Push the public key (this is now at the top of the stack).</li>
</ol>

<hr>

<p>Because of this underlying mechanism, here are the implications:</p>

<ul>
<li><p>If an output to a specific address has never been spent before, then the public key has never been seen by the Bitcoin network. Thus the first time that a valid public key shows up (whose SHA-256 + RIPEMD-160 hash matches), it is indistinguishably as valid as any other public key that has the same hash (which is extremely unlikely to find one, of course).</p></li>
<li><p>If an output to a specific address has been spent before, then the network has recorded one or more public keys that were used to spend that address. The Bitcoin/blockchain protocol does not mandate that the public key must be the same; in other words there is no notion of "key pinning". Although it is plausible for an individual miner's Bitcoin client to enforce key pinning, I don't expect this to be a feature that becomes implemented.</p></li>
</ul>

CC BY-SA 3.0
2016-01-14T20:40:18.160Z
In the specific example- early blocks- this isn't the case, they are raw pubkeys not a pubkey hash.
Claris
CC BY-SA 3.0
2016-01-14T20:51:48.687Z
Okay, I understand pay-to-pubkey. In that case, what does it mean to have a collision? Because each private key maps to a unique public key.
Nayuki
CC BY-SA 3.0
2016-01-14T22:05:29.487Z
It depends on what you mean by private key. 256-bit elliptic curve multiplier? It is unique. / HD wallet parent key? There would be many.
Nayuki
CC BY-SA 3.0
2016-01-14T19:29:06.907Z
2016-01-14T19:29:06.907Z
Nayuki
<p>If there is a private key that leads to a collision on an address, it is possible to show that the private key is not the one used previously, even though they have a collision on the address?</p>

<p>Specifically, if there was a collision on one of the Satoshi-owned early blocks, could it be challenged, to show that the person who got it didn't have the initial private key? Specifically, if they signed the same script that was used originally, wouldn't it generate a different signature, while the original owner would be able to reproduce the original signature?</p>

<p>Thanks,
David</p>

<private-key><hash><cryptography><key-collision>
Proving collisions on Bitcoin addresses without discovery of the private key?
David Manheim
# Proving collisions on Bitcoin addresses without discovery of the private key?

(Asked by: username_0 on 2016-01-13)

If there is a private key that leads to a collision on an address, it is possible to show that the private key is not the one used previously, even though they have a collision on the address?

Specifically, if there was a collision on one of the Satoshi-owned early blocks, could it be challenged, to show that the person who got it didn't have the initial private key? Specifically, if they signed the same script that was used originally, wouldn't it generate a different signature, while the original owner would be able to reproduce the original signature?

Thanks,
username_0

**Tags:** private-key, hash, cryptography, key-collision


---

## 1 answers

### Answer by username_1 on 2016-01-14. Score: 1 | Accepted answer

To phrase the question in my own words: Can you prove that a transaction output was unlocked with a different private key than originally intended?

Short answer: You can or can't, depending on the situation.

---

A standard transaction output script works like this:

1. Assume that the stack starts with two items, with the public key on top and the signature below.
2. Duplicate the public key (topmost item).
3. Compute its hash.
4. Push the expected hash, which is the payee's address (20-byte SHA-256 + RIPEMD-160 hash).
5. Compare and assert that the top two items are equal.
6. Restore the stack to the initial state, and use the two items to check the signature.

A standard transaction input script works like this:

1. Push the signature.
2. Push the public key (this is now at the top of the stack).

---

Because of this underlying mechanism, here are the implications:

* If an output to a specific address has never been spent before, then the public key has never been seen by the Bitcoin network. Thus the first time that a valid public key shows up (whose SHA-256 + RIPEMD-160 hash matches), it is indistinguishably as valid as any other public key that has the same hash (which is extremely unlikely to find one, of course).
* If an output to a specific address has been spent before, then the network has recorded one or more public keys that were used to spend that address. The Bitcoin/blockchain protocol does not mandate that the public key must be the same; in other words there is no notion of "key pinning". Although it is plausible for an individual miner's Bitcoin client to enforce key pinning, I don't expect this to be a feature that becomes implemented.

> **Comments:**
> **username_2**: In the specific example- early blocks- this isn't the case, they are raw pubkeys not a pubkey hash.  
> **username_1**: Okay, I understand pay-to-pubkey. In that case, what does it mean to have a collision? Because each private key maps to a unique public key.  
> **username_1**: It depends on what you mean by private key. 256-bit elliptic curve multiplier? It is unique. / HD wallet parent key? There would be many.  

---

