Why does the TXID have 256 bits when Bitcoin's address security is 160-bit?

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)?

• 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. Sep 14 '21 at 11:05
• @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). Sep 14 '21 at 15:06

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.
• 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? Sep 15 '21 at 6:43
• We need collision resistance on the txids. I'll try to extend this answer later with why. Sep 15 '21 at 6:59
• Can you extend it? I don't want to pressure you but I'm still very interested in the answer. Thank you! Nov 8 '21 at 9:17