<h4>Security levels</h4>
<p>First of all, the relation between security level and the number of bits involved is non-trivial, and depends on the sort of attack we're talking about. For what follows, there are roughly 3 ones that matter:</p>
<ul>
<li><strong>preimage resistance</strong> of a hash function: This is how hard it is for an attacker to find a piece of data that hashes to a given hash. So, symbolically, given <em>a</em>, find <em>x</em> such that <em>hash(x) = a</em>. For secure <em>N</em>-bit hash functions it is assumed that the preimage resistance is <em>2<sup>N</sup></em> work. For example, finding a preimage for RIPEMD160 takes roughly <em>2<sup>160</sup></em> attempts, so we say it has 160 bits of security. SHA256 has 256-bit preimage security.</li>
<li><strong>collision resistance</strong> of a hash function: This is how hard it is for an attacker to find two pieces of data that hash to the same thing (but it doesn't matter what that hash is). Symbolically, find <em>x</em> and <em>y</em> such that <em>hash(x) = hash(y)</em>. Perhaps surprisingly, this is a significantly easier problem than finding preimages, and for a secure <em>N</em>-bit hash function it is assumed that finding a collision takes only roughly <em>2<sup>N/2</sup></em> invocations of the hash function (e.g. , so we say for example that SHA256 has 128-bit collision resistance, and RIPEMD160 has 80-bit collision resistance.</li>
<li><strong>existential forgery</strong> of signatures: This is how hard it is for an attacker to construct a valid signature for a private key they don't have. For a secure <em>N</em>-bit elliptic curve, this is assumed to take roughly <em>2<sup>N/2</sup></em> group operations, so <code>secp256k1</code> is said to have 128-bit security for this sort of attack.</li>
</ul>
<h4>Security in Bitcoin</h4>
<p>Bitcoin aims to have a 128-bit security level.</p>
<ul>
<li>The secp256k1 Elliptic Curve used to sign transactions has a 128-bit security level</li>
<li>The SHA256 hash function has 128-bit collision resistance (it has 256-bit preimage resistance, but for some security properties of the system collision resistance is important).</li>
<li>Using 160-bit hashes for single-key addresses is actually overkill. This could just as well have been a 128-bit hash, as only preimage resistance matters. Presumably no 128-bit hash was chosen as at the time Bitcoin was designed no 128-bit hash functions were considered secure anymore. Of course, a 160-bit or 256-bit hash function truncated to 128-bit could have been used, but presumably there was little desire for such an unconventional design to just save a few bytes.</li>
<li>For multi-party addresses like P2SH multisig and P2WSH, the situation is a bit more complicated. There are known collision attacks that matter in this case (where one of the multisig parties defrauds the other parties, resulting in the ability to spend coins unilaterally). For this, a 256-bit hash of the script is needed to get 128-bit security. P2WSH (and the upcoming P2TR) has this, but P2SH does not, so P2SH technically only has 80-bit security against this attack.</li>
</ul>

CC BY-SA 4.0
2021-09-15T06:43:01.927Z
Thanks for the great info! So which resistance do we actually need for TXID? Is the preimage resistance enough, and then 256-bit is overkill? Or do we need collision resistance as well? The case from your other comment (send the tx two distinct nodes, and the one who saw the invalid one will first will reject the chain that includes the valid one) is rather a bug, isn't it?
Aleš Janda
CC BY-SA 4.0
2021-09-15T06:59:06.647Z
We need collision resistance on the txids. I'll try to extend this answer later with why.
Pieter Wuille
CC BY-SA 4.0
2021-11-08T09:17:33.540Z
Can you extend it? I don't want to pressure you but I'm still very interested in the answer. Thank you!
Aleš Janda
CC BY-SA 4.0
2023-02-13T16:07:43.913Z
@AlešJanda I think it's answered in this comment, but would be good to add it to the answer itself: https://bitcoin.stackexchange.com/questions/109652/why-does-the-txid-have-256-bits-when-bitcoins-address-security-is-160-bit/109658#comment124396_109652
Sjors Provoost
CC BY-SA 4.0
2021-09-14T15:05:23.777Z
2021-09-15T14:26:19.990Z
2021-09-15T14:26:19.990Z
Pieter Wuille
<p>Commonly used Bitcoin addresses have the security of 2<sup>160</sup> (due to the RIPEMD-160 hash). This means that Bitcoin is based on the fact that 160-bit security is good enough. If someone breaks 160-bit security, most bitcoins are in trouble.</p>
<p>The TXID is used to determine previous inputs. For each input, you need to specify the TXID and the output number you want to spend. But the TXID is 256-bit. If 160-bit is good enough, why do we need to enter 256 bits for each input? Why don't TXIDs have only 160 bits as well? This would save 12 bytes for each transaction input, reduce blocks, etc.</p>
<p>If this is for historical reasons, why do some other unrelated cryptocurrencies (e.g. Ethereum) use the same scheme (160-bit address, 256-bit TXID)?</p>

CC BY-SA 4.0
2021-09-14T11:05:43.460Z
TXID has nothing to do with security, even if you could produce a collision you couldn't spend an input that you don't own.
Mike D
CC BY-SA 4.0
2021-09-14T15:06:40.743Z
@Mike D It does. The ability to produce colliding txids where one version is valid and the other is not could be used to trivially fork the network (send the tx two distinct nodes, and the one who saw the invalid one will first will reject the chain that includes the valid one).
Pieter Wuille
<security><cryptography><sha256><ripemd160>
Why does the TXID have 256 bits when Bitcoin's address security is 160-bit?
Aleš Janda
# Why does the TXID have 256 bits when Bitcoin's address security is 160-bit?

(Asked by: username_0 on 2021-09-14)

Commonly used Bitcoin addresses have the security of 2160 (due to the RIPEMD-160 hash). This means that Bitcoin is based on the fact that 160-bit security is good enough. If someone breaks 160-bit security, most bitcoins are in trouble.

The TXID is used to determine previous inputs. For each input, you need to specify the TXID and the output number you want to spend. But the TXID is 256-bit. If 160-bit is good enough, why do we need to enter 256 bits for each input? Why don't TXIDs have only 160 bits as well? This would save 12 bytes for each transaction input, reduce blocks, etc.

If this is for historical reasons, why do some other unrelated cryptocurrencies (e.g. Ethereum) use the same scheme (160-bit address, 256-bit TXID)?

**Tags:** security, cryptography, sha256, ripemd160

> **Comments:**
> **username_1**: TXID has nothing to do with security, even if you could produce a collision you couldn't spend an input that you don't own.  
> **username_2**: @username_1 It does. The ability to produce colliding txids where one version is valid and the other is not could be used to trivially fork the network (send the tx two distinct nodes, and the one who saw the invalid one will first will reject the chain that includes the valid one).  

---

## 1 answers

### Answer by username_2 on 2021-09-14. Score: 11

#### Security levels

First of all, the relation between security level and the number of bits involved is non-trivial, and depends on the sort of attack we're talking about. For what follows, there are roughly 3 ones that matter:

* **preimage resistance** of a hash function: This is how hard it is for an attacker to find a piece of data that hashes to a given hash. So, symbolically, given *a*, find *x* such that *hash(x) = a*. For secure *N*-bit hash functions it is assumed that the preimage resistance is *2N* work. For example, finding a preimage for RIPEMD160 takes roughly *2160* attempts, so we say it has 160 bits of security. SHA256 has 256-bit preimage security.
* **collision resistance** of a hash function: This is how hard it is for an attacker to find two pieces of data that hash to the same thing (but it doesn't matter what that hash is). Symbolically, find *x* and *y* such that *hash(x) = hash(y)*. Perhaps surprisingly, this is a significantly easier problem than finding preimages, and for a secure *N*-bit hash function it is assumed that finding a collision takes only roughly *2N/2* invocations of the hash function (e.g. , so we say for example that SHA256 has 128-bit collision resistance, and RIPEMD160 has 80-bit collision resistance.
* **existential forgery** of signatures: This is how hard it is for an attacker to construct a valid signature for a private key they don't have. For a secure *N*-bit elliptic curve, this is assumed to take roughly *2N/2* group operations, so `secp256k1` is said to have 128-bit security for this sort of attack.

#### Security in Bitcoin

Bitcoin aims to have a 128-bit security level.

* The secp256k1 Elliptic Curve used to sign transactions has a 128-bit security level
* The SHA256 hash function has 128-bit collision resistance (it has 256-bit preimage resistance, but for some security properties of the system collision resistance is important).
* Using 160-bit hashes for single-key addresses is actually overkill. This could just as well have been a 128-bit hash, as only preimage resistance matters. Presumably no 128-bit hash was chosen as at the time Bitcoin was designed no 128-bit hash functions were considered secure anymore. Of course, a 160-bit or 256-bit hash function truncated to 128-bit could have been used, but presumably there was little desire for such an unconventional design to just save a few bytes.
* For multi-party addresses like P2SH multisig and P2WSH, the situation is a bit more complicated. There are known collision attacks that matter in this case (where one of the multisig parties defrauds the other parties, resulting in the ability to spend coins unilaterally). For this, a 256-bit hash of the script is needed to get 128-bit security. P2WSH (and the upcoming P2TR) has this, but P2SH does not, so P2SH technically only has 80-bit security against this attack.

> **Comments:**
> **username_0**: Thanks for the great info! So which resistance do we actually need for TXID? Is the preimage resistance enough, and then 256-bit is overkill? Or do we need collision resistance as well? The case from your other comment (send the tx two distinct nodes, and the one who saw the invalid one will first will reject the chain that includes the valid one) is rather a bug, isn't it?  
> **username_2**: We need collision resistance on the txids. I'll try to extend this answer later with why.  
> **username_0**: Can you extend it? I don't want to pressure you but I'm still very interested in the answer. Thank you!  
> **username_3**: @username_0 I think it's answered in this comment, but would be good to add it to the answer itself: https://bitcoin.stackexchange.com/questions/109652/why-does-the-txid-have-256-bits-when-bitcoins-address-security-is-160-bit/109658#comment124396_109652  

---

