{"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:On Thu, Jan 7, 2016 at 6:52 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e\nwrote:\n\n\u003e Bitcoin does have parts that rely on economic arguments for security or\n\u003e privacy, but can we please stick to using cryptography that is up to par\n\u003e for parts where we can? It's a small constant factor of data, and it\n\u003e categorically removes the worry about security levels.\n\u003e\nOur message may have crossed in the mod queue:\n\n\"So can we quantify the incremental increase in security of SHA256(SHA256)\nover RIPEMD160(SHA256) versus the incremental increase in security of\nhaving a simpler implementation of segwitness?\"\n\nI believe the history of computer security is that implementation errors\nand sidechannel attacks are much, much more common than brute-force breaks.\nKEEP IT SIMPLE.\n\n(and a quibble:  \"do a 80-bit search for B and C such that H(A and B) = H(B\nand C)\"  isn't enough, you have to end up with a C public key for which you\nknow the corresponding private key or the attacker just succeeds in burning\nthe funds)\n\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160107/f73f2f2c/attachment.html\u003e"}