Topic: Question regarding BIP141 (Read 202 times)

I don’t think it will be possible even if the attacks are carried out on dormant addresses.

To be clear, a collision attacks is where an attacker can find any 2 inputs to the hash function which result in the same hash. Typically these are random inputs and it requires ~2^80 hashes. The important thing is that it is not finding another input which has a particular hash - that would be a preimage attack, and in the case of finding a different input, a second preimage attack. Preimage attacks require 2^160 hashes for hash160.

No, the address is an encoding of the hash itself and hashes cannot be reversed.

Yes, but it is probably not necessary. In the context of P2PKHn addresses, I think a collision attack is just kind of bad. What would be really bad is a second preimage attack as that would mean finding another keypair with the same hash. It's a different story for P2SH, which I will explain below.

A collision attack is unlikely to affect existing addresses as their current use is nowhere near the 2^80  upper bound for brute force collision attacks.

Trying to find a collision with any address in use might seem like a collision attack, but because the number of addresses to search is so much smaller than 2^80, it's more akin to a (second) preimage attack.

Collision attacks become problematic when someone is able to convince someone to accept coins with a particular address. This is unlikely for P2PKH, but could be a problem for P2SH. Suppose you and I are doing business together and we want to have some coins sent to a multisig address. I generate a keypair, you generate a keypair, and we make a multisig script. This gets hashed with hash160 and becomes a P2SH address. Now suppose that, in secret, I had actually generated tons of key pairs, and in parallel, constructed a different P2SH script where I am the sole signer. By generating new scripts with random keypairs, if I make 2^80 of them, I should be able to create two scripts which have a hash160 collision. One script will be the multisig between you and me, and that's what I give you. The other script is just me as the signer. Now when a payment is made to the supposed multisig address, I can take those coins because I have a script where I am the only signer and its hash matches that of the output.

This is the danger of a hash160 collision. It has to do with P2SH and how a malicious party could produce a colliding script with different spending conditions. Because it is more concerning for P2SH, P2WSH and Taproot both use SHA256 (or hash256) which is expected to need 2^128 hashes to produce a collision.

I remember replying to a thread about this, not sure if you were the OP.

It is a pre-emptive measure against collision attacks, not that it is currently a security risk. P2WSH addresses are all longer than P2WPKH, not limited to multisig.

IMO, no. There was once a discussion about disabling ECDSA dependent keys (actually I think it was about burning Satoshi's coins) to prevent QC attacks in the past and that idea generated significant resistance. I don't expect the community to be more welcoming to ideas like these.

Important to note that such an attack requires the collision to be done beforehand. P2PKH which uses hash160 is not vulnerable** (preimage, instead of collision) ->That still requires 2^160.

** In hindsight, wording was confusing. But the post after this explains why P2PKH/P2PWKH isn't affected.

Will it be possible to eventually either a) strip hash160 from old P2PKH addresses, or b) completely disable spending from them after an extended waiting time in the future?

From a price point of view, even attacks carried out on dormant addresses are enough for media to write up negative stuff about the incident which'll reduce investor confidence (which means the price tanks) and user adoption despite the whole rest of the network using P2WPKH and P2WSH.

In terms of collision resistance, 160 bits is not sufficient because it is feasible. A pure brute force collision attack on a 160 bit hash expects 2^80 hashes to be computed. Clearly this is within the realm of possibility because the Bitcoin network is estimated to have computed several times that number of hashes (the current estimate is 2^93). Sure this is not practical, but it also means that 160 bits is no longer enough to provide collision.

It's because hash160 has potential feasible collision attacks that it is being phased out. Segwit is not using it for script hashes, and Taproot gets rid of it completely in standard use.

If you create a M-of-N multisig using Segwit Nested, it'll be 160 bits encoded, as it should. But, if you choose to have a Segwit Native to save up on fees, you won't get 160 bits, but 256. Is there any serious reasons behind this? I might haven't understood the text below:

Isn't it a little early to be afraid of hash collisions against HASH160? And if it's not, should we fork instead of using it?

I made this, because I noticed a drawback. I recently broadcasted a transaction funding a multi-sig segwit native address, but before I knew it, I had already lost a part of my privacy. I know that once I would have to spend from the multi-sig, I'd reveal that it's a multi-sig, but until then, no one would knew it.