{"type":"rich","version":"1.0","author_name":"npub15wz8j5cse6sexlw6f5q7arc5efe5hxn6kcxxyy222et8qms4u3lsemaru8","author_url":"https://nostr.ae/npub15wz8j5cse6sexlw6f5q7arc5efe5hxn6kcxxyy222et8qms4u3lsemaru8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-01-07\n📝 Original message:Maybe I'm being dense, but I don't see why 2**80 storage is required for\nthis attack.  Also, I don't see why the attacker ever needs to get the\nvictim to accept \"arbitrary_data\".  Perhaps I'm wrong about how the\ncollision attack works:\n\n   1. Create a script which is perfectly acceptable and would pass the\n   sniff test Gavin proposed (no arbitrary_data).\n   2. Set off CPU power to construct a second script that lets attacker\n   keep his coins and has the same hash. (This is where you get\n   \"arbitrary_data\").\n   3. Send a transaction with the first script to the seller as payment.\n   4. Wait for the transaction to be included in a block.\n   5. Redeem the transaction with the second script, thus stealing the\n   coins back.\n\nSo the seller would never see the I'd appreciate any correction to my\nunderstanding here.  Where do you need 2**80 storage?  And when does the\nseller have to accept \"arbitrary_data\"?\nThanks!\n\nOn Thu, Jan 7, 2016 at 11:19 AM, Adam Back via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e You could say 256 bit ECDSA is overkill lets go to 160 equivalently.\n\u003e Saves even more bytes.\n\u003e\n\u003e The problem with arguing down is where to stop.\n\u003e\n\u003e As Matt said these things dont degrade gracefully so a best practice\n\u003e is to aim for a bit of extra margin.\n\u003e\n\u003e 256-bit is quite common at this point since AES, SHA256 etc even in\n\u003e things with much less at stake than Bitcoin.\n\u003e\n\u003e You could send the compressed (unhashed) pubkey then there's no hash\n\u003e (and omit it from the sig).  Greg had mentioned that in the past.\n\u003e\n\u003e I think it might be possible to do both (reclaim the hash bits in the\n\u003e serialisation of the pub key).\n\u003e\n\u003e Adam\n\u003e\n\u003e On 7 January 2016 at 20:02, Gavin Andresen via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e I'm hoisting this from some private feedback I sent on the segregated\n\u003e \u003e witness BIP:\n\u003e \u003e\n\u003e \u003e I said:\n\u003e \u003e\n\u003e \u003e \"I'd also use RIPEMD160(SHA256()) as the hash function and save the 12\n\u003e \u003e bytes-- a successful preimage attack against that ain't gonna happen\n\u003e before\n\u003e \u003e we're all dead. I'm probably being dense, but I just don't see how a\n\u003e \u003e collision attack is relevant here.\"\n\u003e \u003e\n\u003e \u003e Pieter responded:\n\u003e \u003e\n\u003e \u003e \"The problem case is where someone in a contract setup shows you a\n\u003e script,\n\u003e \u003e which you accept as being a payment to yourself. An attacker could use a\n\u003e \u003e collision attack to construct scripts with identical hashes, only one of\n\u003e \u003e which does have the property you want, and steal coins.\n\u003e \u003e\n\u003e \u003e So you really want collision security, and I don't think 80 bits is\n\u003e \u003e something we should encourage for that. Normal pubkey hashes don't have\n\u003e that\n\u003e \u003e problem, as they can't be constructed to pay to you.\"\n\u003e \u003e\n\u003e \u003e ... but I'm unconvinced:\n\u003e \u003e\n\u003e \u003e \"But it is trivial for contract wallets to protect against collision\n\u003e \u003e attacks-- if you give me a script that is \"gavin_pubkey CHECKSIG\n\u003e \u003e arbitrary_data OP_DROP\" with \"I promise I'm not trying to rip you off,\n\u003e just\n\u003e \u003e ignore that arbitrary data\" a wallet can just refuse. Even more likely, a\n\u003e \u003e contract wallet won't even recognize that as a pay-to-gavin transaction.\n\u003e \u003e\n\u003e \u003e I suppose it could be looking for some form of \"gavin_pubkey\n\u003e \u003e somebody_else_pubkey CHECKMULTISIG ... with the attacker using\n\u003e \u003e somebody_else_pubkey to force the collision, but, again, trivial contract\n\u003e \u003e protocol tweaks (\"send along a proof you have the private key\n\u003e corresponding\n\u003e \u003e to the public key\" or \"everybody pre-commits pubkeys they'll use at\n\u003e protocol\n\u003e \u003e start\") would protect against that.\n\u003e \u003e\n\u003e \u003e Adding an extra 12 bytes to every segwit to prevent an attack that takes\n\u003e \u003e 2^80 computation and 2^80 storage, is unlikely to be a problem in\n\u003e practice,\n\u003e \u003e and is trivial to protect against is the wrong tradeoff to make.\"\n\u003e \u003e\n\u003e \u003e 20 bytes instead of 32 bytes is a savings of almost 40%, which is\n\u003e \u003e significant.\n\u003e \u003e\n\u003e \u003e The general question I'd like to raise on this list is:\n\u003e \u003e\n\u003e \u003e Should we be worried, today, about collision attacks against RIPEMD160\n\u003e (our\n\u003e \u003e 160-bit hash)?\n\u003e \u003e\n\u003e \u003e Mounting a successful brute-force collision attack would require at least\n\u003e \u003e O(2^80) CPU, which is kinda-sorta feasible (Pieter pointed out that\n\u003e Bitcoin\n\u003e \u003e POW has computed more SHA256 hashes than that). But it also requires\n\u003e O(2^80)\n\u003e \u003e storage, which is utterly infeasible (there is something on the order of\n\u003e \u003e 2^35 bytes of storage in the entire world).  Even assuming doubling every\n\u003e \u003e single year (faster than Moore's Law), we're four decades away from an\n\u003e \u003e attacker with THE ENTIRE WORLD's storage capacity being able to mount a\n\u003e \u003e collision attack.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e References:\n\u003e \u003e\n\u003e \u003e https://en.wikipedia.org/wiki/Collision_attack\n\u003e \u003e\n\u003e \u003e\n\u003e https://vsatglobalseriesblog.wordpress.com/2013/06/21/in-2013-the-amount-of-data-generated-worldwide-will-reach-four-zettabytes/\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e --\n\u003e \u003e --\n\u003e \u003e Gavin Andresen\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \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-- \nI like to provide some work at no charge to prove my value. Do you need a\ntechie?\nI own Litmocracy \u003chttp://www.litmocracy.com\u003e and Meme Racing\n\u003chttp://www.memeracing.net\u003e (in alpha).\nI'm the webmaster for The Voluntaryist \u003chttp://www.voluntaryist.com\u003e which\nnow accepts Bitcoin.\nI also code for The Dollar Vigilante \u003chttp://dollarvigilante.com/\u003e.\n\"He ought to find it more profitable to play by the rules\" - Satoshi\nNakamoto\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160107/b5c2e636/attachment.html\u003e"}