This question revolves around Bitcoin Optech newsletter #51 (1) and an email thread from the bitcoin-dev mailing list (2). I asked the same question in a reply-email of the newsletter and the response was so enlightening that I thought I'd share my question and quote David Harding's reply email in an answer (I got his permission to do so).
In the newsletter text, the author describes what is supposedly a collision attack on RIPEMD160(SHA256):
However, when multisig addresses are being used, the attacker may be one of the parties involved in generation of the address and so may be able to manipulate what address is finally chosen. For example, Bob sends his pubkey to Mallory expecting that Mallory will send her pubkey back. Then he expects they’ll each put the pubkeys into a multisig script template, hash it into an address, and someone will deposit money into that address.
Mallory instead takes the script template and Bob’s pubkey, inserts one of her pubkeys without telling Bob about it, and hashes it into an address. This allows her to see the address Bob will accept before Mallory has committed to using that pubkey. Mallory can then compare this address to a database of addresses generated from scripts that pay only her. If there’s a match (collision) between two of the addresses, she sends the pubkey back to Bob, waits for money to be deposited into the address, and then uses the script from her database to steal the money. If there’s not a match, Mallory can try again with a different pubkey over and over until she succeeds (if we assume she has unlimited time and resources).
Although this seems like the same brute force attack described earlier with a 1-in-2^160 chance of success per attempt, we have to consider the size of Mallory’s database. If we imagine the database has 100 addresses, then each different pubkey she tries has a 100-in-2^160 chance of success because it succeeds if it matches any one of the addresses in Mallory’s database.
This type of attack is called a collision attack.
My question is: Isn't the described attack actually a second-preimage attack, and not a collision attack?
The attack described is based on a database of preimages and hashes, so I'd call the attack a second-preimage attack (though possibly a highly concurrent one). I wouldn't call it a collision attack because a collision attack is the process of finding two different preimages with the same hash value, no matter the hash value. In your attack the attacker is looking for a set of specific hash values. Your example with a database of 100 addresses makes it pretty clear that we're dealing with a second-preimage attack. It's even more clear if the database only contains 1 entry. The line between a collision attack and a second-preimage attack becomes a bit blurry when the database grows, but I still think it's wrong to call it a collision attack.
The attack described by Pieter Wuille in the email linked to (3) from the newsletter is a pure collision attack where the attacker doesn't have a pre-created database of preimages and hashes. Instead the attacker calculates a collision after the victim's pubkey is received, and doesn't care at all what the hash value is. See for example Ethan Heilman's algorithm (4), which I haven't fully understood yet, but it's an algorithm, that doesn't use a database, to find collisions with the order of ~2^80 work. Anthony Towns later (5) fleshes out an explicit algorithm for finding a collision with a chosen prefix and suffix with about the same complexity.
An important difference between the attack described in the newsletter and Wuille's is that you need a huge database (~2^80 entries) to reach complexity ~2^80 while Wuille doesn't need a database to reach about the same complexity. You kind of emulate a collision attack using a huge number of simultaneous second-preimage attacks. So is the newsletter really describing a collision attack?