Indeed, anything which uses P2SH is obviously vulnerable if there is an attack on RIPEMD160 which reduces it's security only marginally. While no one thought hard about these attacks when P2SH was designed, we realized later this was not such a good idea to reuse the structure from P2PKH. Hence why this discussion came up.
On January 7, 2016 7:30:11 PM PST, Rusty Russell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: >Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> >writes: >> Yes, this is what I worry about. We're constructing a 2-of-2 multisig >> escrow in a contract. I reveal my public key A, you do a 80-bit >search for >> B and C such that H(A and B) = H(B and C). You tell me your keys B, >and I >> happily send to H(A and B), which you steal with H(B and C). > >FWIW, this attack would effect the current lightning-network >"deployable >lightning" design at channel establishment; we reveal our pubkey in the >opening packet (which is used to redeem a P2SH using normal 2of2). > >At least you need to grind before replying (which will presumably time >out), rather than being able to do it once the channel is open. > >We could pre-commit by exchanging hashes of pubkeys first, but >contracts >on bitcoin are hard enough to get right that I'm reluctant to add more >hoops. > >Cheers, >Rusty. >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
