I was under the impression that RIPEMD160(SHA256(msg)) is used to turn a PUBLIC key (msg) into a bitcoin address, so yeah, you could identify ANOTHER (or the same, I guess - how would you know?) public key that has the same bitcoin address if RIPEMD-160 collisions are easy, but I don't see how that has any effect on anyone. Maybe I'm restating what Peter wrote. If so, confirmation would be nice.
On Sat, Feb 25, 2017 at 1:04 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sat, Feb 25, 2017 at 03:53:12PM -0500, Russell O'Connor wrote: > > On Sat, Feb 25, 2017 at 2:12 PM, Peter Todd via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev > > > wrote: > > > > >SHA1 is insecure because the SHA1 algorithm is insecure, not because > > > > 160bits isn't enough. > > > > > > > > I would argue that 160-bits isn't enough for collision resistance. > > > Assuming > > > > RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle), > > > collisions > > > > > > That's something that we're well aware of; there have been a few > > > discussions on > > > this list about how P2SH's 160-bits is insufficient in certain > use-cases > > > such > > > as multisig. > > > > > > However, remember that a 160-bit *security level* is sufficient, and > > > RIPEMD160 > > > has 160-bit security against preimage attacks. Thus things like > > > pay-to-pubkey-hash are perfectly secure: sure you could generate two > > > pubkeys > > > that have the same RIPEMD160(SHA256()) digest, but if someone does > that it > > > doesn't cause the Bitcoin network itself any harm, and doing so is > > > something > > > you choose to do to yourself. > > > > > > > Be aware that the issue is more problematic for more complex contracts. > > For example, you are building a P2SH 2-of-2 multisig together with > someone > > else if you are not careful, party A can hand their key over to party B, > > who can may try to generate a collision between their second key and > > another 2-of-2 multisig where they control both keys. See > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ > 2016-January/012205.html > > I'm very aware of that, in fact I think I may have even been the first > person > to post on this list the commit-reveal mitigation. > > Note how I said earlier in the message you're replying to that "P2SH's > 160-bits > is insufficient in certain use-cases such as multisig" > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy <http://www.litmocracy.com> and Meme Racing <http://www.memeracing.net> (in alpha). I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which now accepts Bitcoin. I also code for The Dollar Vigilante <http://dollarvigilante.com/>. "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
