{"type":"rich","version":"1.0","author_name":"npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj","author_url":"https://nostr.ae/npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-01-07\n📝 Original message:You could say 256 bit ECDSA is overkill lets go to 160 equivalently.\nSaves even more bytes.\n\nThe problem with arguing down is where to stop.\n\nAs Matt said these things dont degrade gracefully so a best practice\nis to aim for a bit of extra margin.\n\n256-bit is quite common at this point since AES, SHA256 etc even in\nthings with much less at stake than Bitcoin.\n\nYou could send the compressed (unhashed) pubkey then there's no hash\n(and omit it from the sig).  Greg had mentioned that in the past.\n\nI think it might be possible to do both (reclaim the hash bits in the\nserialisation of the pub key).\n\nAdam\n\nOn 7 January 2016 at 20:02, Gavin Andresen via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e I'm hoisting this from some private feedback I sent on the segregated\n\u003e witness BIP:\n\u003e\n\u003e I said:\n\u003e\n\u003e \"I'd also use RIPEMD160(SHA256()) as the hash function and save the 12\n\u003e bytes-- a successful preimage attack against that ain't gonna happen before\n\u003e we're all dead. I'm probably being dense, but I just don't see how a\n\u003e collision attack is relevant here.\"\n\u003e\n\u003e Pieter responded:\n\u003e\n\u003e \"The problem case is where someone in a contract setup shows you a script,\n\u003e which you accept as being a payment to yourself. An attacker could use a\n\u003e collision attack to construct scripts with identical hashes, only one of\n\u003e which does have the property you want, and steal coins.\n\u003e\n\u003e So you really want collision security, and I don't think 80 bits is\n\u003e something we should encourage for that. Normal pubkey hashes don't have that\n\u003e problem, as they can't be constructed to pay to you.\"\n\u003e\n\u003e ... but I'm unconvinced:\n\u003e\n\u003e \"But it is trivial for contract wallets to protect against collision\n\u003e attacks-- if you give me a script that is \"gavin_pubkey CHECKSIG\n\u003e arbitrary_data OP_DROP\" with \"I promise I'm not trying to rip you off, just\n\u003e ignore that arbitrary data\" a wallet can just refuse. Even more likely, a\n\u003e contract wallet won't even recognize that as a pay-to-gavin transaction.\n\u003e\n\u003e I suppose it could be looking for some form of \"gavin_pubkey\n\u003e somebody_else_pubkey CHECKMULTISIG ... with the attacker using\n\u003e somebody_else_pubkey to force the collision, but, again, trivial contract\n\u003e protocol tweaks (\"send along a proof you have the private key corresponding\n\u003e to the public key\" or \"everybody pre-commits pubkeys they'll use at protocol\n\u003e start\") would protect against that.\n\u003e\n\u003e Adding an extra 12 bytes to every segwit to prevent an attack that takes\n\u003e 2^80 computation and 2^80 storage, is unlikely to be a problem in practice,\n\u003e and is trivial to protect against is the wrong tradeoff to make.\"\n\u003e\n\u003e 20 bytes instead of 32 bytes is a savings of almost 40%, which is\n\u003e significant.\n\u003e\n\u003e The general question I'd like to raise on this list is:\n\u003e\n\u003e Should we be worried, today, about collision attacks against RIPEMD160 (our\n\u003e 160-bit hash)?\n\u003e\n\u003e Mounting a successful brute-force collision attack would require at least\n\u003e O(2^80) CPU, which is kinda-sorta feasible (Pieter pointed out that Bitcoin\n\u003e POW has computed more SHA256 hashes than that). But it also requires O(2^80)\n\u003e storage, which is utterly infeasible (there is something on the order of\n\u003e 2^35 bytes of storage in the entire world).  Even assuming doubling every\n\u003e single year (faster than Moore's Law), we're four decades away from an\n\u003e attacker with THE ENTIRE WORLD's storage capacity being able to mount a\n\u003e collision attack.\n\u003e\n\u003e\n\u003e References:\n\u003e\n\u003e https://en.wikipedia.org/wiki/Collision_attack\n\u003e\n\u003e https://vsatglobalseriesblog.wordpress.com/2013/06/21/in-2013-the-amount-of-data-generated-worldwide-will-reach-four-zettabytes/\n\u003e\n\u003e\n\u003e --\n\u003e --\n\u003e Gavin Andresen\n\u003e\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"}