rich1.0npub108dfgewsuqzm6cvllzmxsv0xnn69rrjnyg5pa32a727k89ndh3xqmsr4hphttps://nostr.ae/npub108dfgewsuqzm6cvllzmxsv0xnn69rrjnyg5pa32a727k89ndh3xqmsr4hpnjumphttps://nostr.ae📅 Original date posted:2016-01-07 📝 Original message:On Jan 7, 2016 5:22 PM, "Gavin Andresen via bitcoin-dev" < bitcoin-dev at lists.linuxfoundation.org> wrote: > > On Thu, Jan 7, 2016 at 6:52 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote: >> >> Bitcoin does have parts that rely on economic arguments for security or privacy, but can we please stick to using cryptography that is up to par for parts where we can? It's a small constant factor of data, and it categorically removes the worry about security levels. > > Our message may have crossed in the mod queue: > > "So can we quantify the incremental increase in security of SHA256(SHA256) over RIPEMD160(SHA256) versus the incremental increase in security of having a simpler implementation of segwitness?" There are several clever ways to exploit even chosen prefix collisions using the scripting language. One could search for collisions where one message is some data and the other is a jump over a critical check. > > I believe the history of computer security is that implementation errors and sidechannel attacks are much, much more common than brute-force breaks. KEEP IT SIMPLE. Ask the Iranian nuclear program. Or those brainwallet users. > > (and a quibble: "do a 80-bit search for B and C such that H(A and B) = H(B and C)" isn't enough, you have to end up with a C public key for which you know the corresponding private key or the attacker just succeeds in burning the funds) > > > -- > -- > Gavin Andresen > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160107/9bdcb94f/attachment-0001.html>