On Feb 25, 2017, at 3:21 PM, Dave Scotese <dscotese@litmocracy.com> wrote:

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 and Meme Racing (in alpha).
I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
I also code for The Dollar Vigilante.
"He ought to find it more profitable to play by the rules" - Satoshi Nakamoto