<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 25, 2017 at 2:12 PM, Peter Todd via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev wrote:<br>
> >SHA1 is insecure because the SHA1 algorithm is insecure, not because<br>
> 160bits isn't enough.<br>
><br>
> I would argue that 160-bits isn't enough for collision resistance. Assuming<br>
> RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle), collisions<br>
<br>
</span>That's something that we're well aware of; there have been a few discussions on<br>
this list about how P2SH's 160-bits is insufficient in certain use-cases such<br>
as multisig.<br>
<br>
However, remember that a 160-bit *security level* is sufficient, and RIPEMD160<br>
has 160-bit security against preimage attacks. Thus things like<br>
pay-to-pubkey-hash are perfectly secure: sure you could generate two pubkeys<br>
that have the same RIPEMD160(SHA256()) digest, but if someone does that it<br>
doesn't cause the Bitcoin network itself any harm, and doing so is something<br>
you choose to do to yourself.<br></blockquote><div><br></div><div>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 <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012205.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012205.html</a><br></div></div></div></div>