đź“… Original date posted:2017-02-25
📝 Original message:Yea, well. I don’t think it is ethical to post instructions without an associated remediation (BIP) if you don’t see the potential attack.
I was rather hoping that we could have a fuller discussion of what the best practical response would be to such an issue?
> On Feb 25, 2017, at 3:21 PM, Dave Scotese <dscotese at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 <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 <https://petertodd.org/>; 'peter'[:-1]@petertodd.org <http://petertodd.org/>;
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170225/461ac05d/attachment.html>;
Steve Davis [ARCHIVE] /
npub1nf…gkps5
2023-06-07 17:56:44
in reply to nevent1q…at6j
Author Public Key
npub1nf4hx3yuahf4awyzsdfzh6gelr8ef4d8yqeker5y8sku64k48c7qcgkps5Published at
2023-06-07 17:56:44Event JSON
{
"id": "2cd436e98e6c1212c184541cc6d4ea2070c32d98b9836dd377a146a4fd4cf0b1",
"pubkey": "9a6b73449cedd35eb88283522be919f8cf94d5a720336c8e843c2dcd56d53e3c",
"created_at": 1686160604,
"kind": 1,
"tags": [
[
"e",
"37053a195373ca87d2cc167b4470872a0425d55bfe62c38a20deac2033060b94",
"",
"root"
],
[
"e",
"5ed1c1fcae68254a3b16b7df5b7e10530a7514ad1199d7fb9be34e64d7aa8726",
"",
"reply"
],
[
"p",
"a384795310cea1937dda4d01ee8f14ca734b9a7ab60c62114a5656706e15e47f"
]
],
"content": "📅 Original date posted:2017-02-25\n📝 Original message:Yea, well. I don’t think it is ethical to post instructions without an associated remediation (BIP) if you don’t see the potential attack.\n\nI was rather hoping that we could have a fuller discussion of what the best practical response would be to such an issue?\n\n\n\u003e On Feb 25, 2017, at 3:21 PM, Dave Scotese \u003cdscotese at litmocracy.com\u003e wrote:\n\u003e \n\u003e 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.\n\u003e \n\u003e On Sat, Feb 25, 2017 at 1:04 PM, Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e On Sat, Feb 25, 2017 at 03:53:12PM -0500, Russell O'Connor wrote:\n\u003e \u003e On Sat, Feb 25, 2017 at 2:12 PM, Peter Todd via bitcoin-dev \u003c\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev\n\u003e \u003e \u003e wrote:\n\u003e \u003e \u003e \u003e \u003eSHA1 is insecure because the SHA1 algorithm is insecure, not because\n\u003e \u003e \u003e \u003e 160bits isn't enough.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e I would argue that 160-bits isn't enough for collision resistance.\n\u003e \u003e \u003e Assuming\n\u003e \u003e \u003e \u003e RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle),\n\u003e \u003e \u003e collisions\n\u003e \u003e \u003e\n\u003e \u003e \u003e That's something that we're well aware of; there have been a few\n\u003e \u003e \u003e discussions on\n\u003e \u003e \u003e this list about how P2SH's 160-bits is insufficient in certain use-cases\n\u003e \u003e \u003e such\n\u003e \u003e \u003e as multisig.\n\u003e \u003e \u003e\n\u003e \u003e \u003e However, remember that a 160-bit *security level* is sufficient, and\n\u003e \u003e \u003e RIPEMD160\n\u003e \u003e \u003e has 160-bit security against preimage attacks. Thus things like\n\u003e \u003e \u003e pay-to-pubkey-hash are perfectly secure: sure you could generate two\n\u003e \u003e \u003e pubkeys\n\u003e \u003e \u003e that have the same RIPEMD160(SHA256()) digest, but if someone does that it\n\u003e \u003e \u003e doesn't cause the Bitcoin network itself any harm, and doing so is\n\u003e \u003e \u003e something\n\u003e \u003e \u003e you choose to do to yourself.\n\u003e \u003e \u003e\n\u003e \u003e\n\u003e \u003e Be aware that the issue is more problematic for more complex contracts.\n\u003e \u003e For example, you are building a P2SH 2-of-2 multisig together with someone\n\u003e \u003e else if you are not careful, party A can hand their key over to party B,\n\u003e \u003e who can may try to generate a collision between their second key and\n\u003e \u003e another 2-of-2 multisig where they control both keys. See\n\u003e \u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012205.html \u003chttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012205.html\u003e\n\u003e \n\u003e I'm very aware of that, in fact I think I may have even been the first person\n\u003e to post on this list the commit-reveal mitigation.\n\u003e \n\u003e Note how I said earlier in the message you're replying to that \"P2SH's 160-bits\n\u003e is insufficient in certain use-cases such as multisig\"\n\u003e \n\u003e --\n\u003e https://petertodd.org \u003chttps://petertodd.org/\u003e 'peter'[:-1]@petertodd.org \u003chttp://petertodd.org/\u003e\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e -- \n\u003e I like to provide some work at no charge to prove my value. Do you need a techie? \n\u003e I own Litmocracy \u003chttp://www.litmocracy.com/\u003e and Meme Racing \u003chttp://www.memeracing.net/\u003e (in alpha). \n\u003e I'm the webmaster for The Voluntaryist \u003chttp://www.voluntaryist.com/\u003e which now accepts Bitcoin.\n\u003e I also code for The Dollar Vigilante \u003chttp://dollarvigilante.com/\u003e.\n\u003e \"He ought to find it more profitable to play by the rules\" - Satoshi Nakamoto\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170225/461ac05d/attachment.html\u003e",
"sig": "899fbc06ff867615de10bf1a22fe0daaae065d774b8411723d847bbbaee6ffa4951064c2fc76a5521e6845b152e5c23df5f9039c483aaa0674cd4021c903301e"
}