{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-01-07\n📝 Original message:I'm hoisting this from some private feedback I sent on the segregated\nwitness BIP:\n\nI said:\n\n\"I'd also use RIPEMD160(SHA256()) as the hash function and save the 12\nbytes-- a successful preimage attack against that ain't gonna happen before\nwe're all dead. I'm probably being dense, but I just don't see how a\ncollision attack is relevant here.\"\n\nPieter responded:\n\n\"The problem case is where someone in a contract setup shows you a script,\nwhich you accept as being a payment to yourself. An attacker could use a\ncollision attack to construct scripts with identical hashes, only one of\nwhich does have the property you want, and steal coins.\n\nSo you really want collision security, and I don't think 80 bits is\nsomething we should encourage for that. Normal pubkey hashes don't have\nthat problem, as they can't be constructed to pay to you.\"\n... but I'm unconvinced:\n\n\"But it is trivial for contract wallets to protect against collision\nattacks-- if you give me a script that is \"gavin_pubkey CHECKSIG\narbitrary_data OP_DROP\" with \"I promise I'm not trying to rip you off, just\nignore that arbitrary data\" a wallet can just refuse. Even more likely, a\ncontract wallet won't even recognize that as a pay-to-gavin transaction.\n\nI suppose it could be looking for some form of \"gavin_pubkey\nsomebody_else_pubkey CHECKMULTISIG ... with the attacker using\nsomebody_else_pubkey to force the collision, but, again, trivial contract\nprotocol tweaks (\"send along a proof you have the private key corresponding\nto the public key\" or \"everybody pre-commits pubkeys they'll use at\nprotocol start\") would protect against that.\n\nAdding an extra 12 bytes to every segwit to prevent an attack that takes\n2^80 computation and 2^80 storage, is unlikely to be a problem in practice,\nand is trivial to protect against is the wrong tradeoff to make.\"\n\n20 bytes instead of 32 bytes is a savings of almost 40%, which is\nsignificant.\n\nThe general question I'd like to raise on this list is:\n\nShould we be worried, today, about collision attacks against RIPEMD160 (our\n160-bit hash)?\n\nMounting a successful brute-force collision attack would require at least\nO(2^80) CPU, which is kinda-sorta feasible (Pieter pointed out that Bitcoin\nPOW has computed more SHA256 hashes than that). But it also requires\nO(2^80) storage, which is utterly infeasible (there is something on the\norder of 2^35 bytes of storage in the entire world).  Even assuming\ndoubling every single year (faster than Moore's Law), we're four decades\naway from an attacker with THE ENTIRE WORLD's storage capacity being able\nto mount a collision attack.\n\n\nReferences:\n\nhttps://en.wikipedia.org/wiki/Collision_attack\n\nhttps://vsatglobalseriesblog.wordpress.com/2013/06/21/in-2013-the-amount-of-data-generated-worldwide-will-reach-four-zettabytes/\n\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160107/09860830/attachment.html\u003e"}