{"type":"rich","version":"1.0","author_name":"npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","author_url":"https://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-01-07\n📝 Original message:\u003e \"The problem case is where someone in a contract setup shows you a\nscript, which you accept as being a payment to yourself. An attacker could\nuse a collision attack to construct scripts with identical hashes, only one\nof 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\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\u003e\n\u003e ... but I'm unconvinced:\n\u003e\n\u003e \"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\u003e\n\u003e I 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\nYes, this is what I worry about. We're constructing a 2-of-2 multisig\nescrow in a contract. I reveal my public key A, you do a 80-bit search for\nB and C such that H(A and B) = H(B and C). You tell me your keys B, and I\nhappily send to H(A and B), which you steal with H(B and C).\n\nSending along a proof does not help, you can't prove that you do not know\nof a collision. Pre-committing does help, but is a very non-obvious\nsecurity requirement, something I strongly believe is far riskier in\npractice.\n\nBitcoin does have parts that rely on economic arguments for security or\nprivacy, but can we please stick to using cryptography that is up to par\nfor parts where we can? It's a small constant factor of data, and it\ncategorically removes the worry about security levels.\n\n-- \nPieter\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160108/e2e921fb/attachment.html\u003e"}