{"type":"rich","version":"1.0","author_name":"npub108dfgewsuqzm6cvllzmxsv0xnn69rrjnyg5pa32a727k89ndh3xqmsr4hp","author_url":"https://nostr.ae/npub108dfgewsuqzm6cvllzmxsv0xnn69rrjnyg5pa32a727k89ndh3xqmsr4hp","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-01-08\n📝 Original message:On Fri, Jan 8, 2016 at 4:38 AM, Gavin Andresen via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e On Fri, Jan 8, 2016 at 7:02 AM, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\u003e\u003e\n\u003e\u003e Matt Corallo \u003clf-lists at mattcorallo.com\u003e writes:\n\u003e\u003e \u003e Indeed, anything which uses P2SH is obviously vulnerable if there is\n\u003e\u003e \u003e an attack on RIPEMD160 which reduces it's security only marginally.\n\u003e\u003e\n\u003e\u003e I don't think this is true?  Even if you can generate a collision in\n\u003e\u003e RIPEMD160, that doesn't help you since you need to create a specific\n\u003e\u003e SHA256 hash for the RIPEMD160 preimage.\n\u003e\u003e\n\u003e\u003e Even a preimage attack only helps if it leads to more than one preimage\n\u003e\u003e fairly cheaply; that would make grinding out the SHA256 preimage easier.\n\u003e\u003e AFAICT even MD4 isn't this broken.\n\u003e\n\u003e\n\u003e It feels like we've gone over that before, but I can never remember where or\n\u003e when. I believe consensus was that if we were using the broken MD5 in all\n\u003e the places we use RIPEMD160 we'd still be secure today because of Satoshi's\n\u003e use of nested hash functions everywhere.\n\u003e\n\u003e\u003e\n\u003e\u003e But just with Moore's law (doubling every 18 months), we'll worry about\n\u003e\u003e economically viable attacks in 20 years.[1]\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e That's far enough away that I would choose simplicity, and have all SW\n\u003e\u003e scriptPubKeys simply be \"\u003c0\u003e RIPEMD(SHA256(WP))\" for now, but it's\n\u003e\u003e not a no-brainer.\n\u003e\n\u003e\n\u003e Lets see if I've followed the specifics of the collision attack correctly,\n\u003e Ethan (or somebody) please let me know if I'm missing something:\n\u003e\n\u003e So attacker is in the middle of establishing a payment channel with\n\u003e somebody. Victim gives their public key, attacker creates the innocent\n\u003e fund-locking script  '2 V A 2 CHECKMULTISIG' (V is victim's public key, A is\n\u003e attacker's) but doesn't give it to the victim yet.\n\u003e\n\u003e Instead they then generate about 2^81scripts that are some form of\n\u003e pay-to-attacker ....\n\u003e ... wait, no that doesn't work, because SHA256 is used as the inner hash\n\u003e function.  They'd have to generate 2^129 to find a cycle in SHA256.\n\nFor 2^80 they simply generate 2^80 scripts that look innocent, and\n2^80 that are not. With high probability there is a collision. I agree\nthat most cryptanalysis won't work because of the nesting, but 2^80 is\nnot good.\n\u003e\n\u003e Instead, they .. what? I don't see a viable attack unless RIPEMD160 and\n\u003e SHA256 (or the combination) suffers a cryptographic break.\n\u003e\n\u003e\n\u003e --\n\u003e --\n\u003e Gavin Andresen\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\n\n\n-- \n\"Man is born free, but everywhere he is in chains\".\n--Rousseau."}