Published on: 2016-01-12T23:22:17+00:00
Zooko, a contributor to the Bitcoin development mailing list, suggests that the thread is omitting consideration of multi-target attacks. He explains that if an attacker is happy to find a collision with any one out of a large number of potential victims, they get an advantage proportional to the number of potential victims. Therefore, it would be wise to estimate how many public keys will eventually be in use. Zooko recommends a recent blog post by DJB for more information about the "Attacker Economist" approach.It is advised to worry about 80-bit collision attacks as they are likely to cost less than $1 million in the next ten to twenty years. If one agrees to lock up funds with someone else and they control the public key, they become susceptible to these attacks. It is suggested to avoid pay-to-script-hash addresses and instead use payment protocol and "raw" multisig outputs when dealing with significant amounts of money. Alternatively, one can ask for a hierarchical deterministic (BIP32) seed and derive a public key for them to use. To ensure maximum security, one should follow security in depth and validate all input secure coding principles.In an email conversation on January 11, 2016 at 11:57 PM, Tier Nolan corrected an error in a code block on the Bitcoin development mailing list. The original script had a syntax error in the order of the parameters for CHECKSIG and OP_DROP, and Tier Nolan swapped the positions of const_pub_key and prev_hash in the script to correct it.In a discussion on the bitcoin-dev mailing list, Gavin Andresen asked about how long it would take for a 2^84 attack where the work is an ECDSA private to public key derivation. However, another participant in the discussion suggested that the EC multiply may not actually be necessary and proposed using compressed public keys and a sha256 call instead. Gavin Andresen defended the choice of SHA256D over RipeMD160 for an update to the digital currency's software in a Bitcoin developer email thread. He argued that the tradeoff between crypto strength and code complexity is important and that "the strength of the crypto is all that matters" was not security-first. Another developer disagreed and stated that code complexity shouldn't be a concern, but rather the security versus space tradeoff.Peter Todd shared his experience of raising an issue with segregated witnesses on the BIP process in response to a comment by Gavin Andresen. Todd expressed concerns that it could make validationless mining easier and more profitable. The issue was discussed on IRC, and Todd plans to write the code to implement a fix and submit it as a pull-req against the segwit branch.Gavin Andresen proposed eliminating the risk of a potential attack by having only one witness program version in a Bitcoin-dev email thread in 2016. Pieter Wuille disagreed with this suggestion and argued for maintaining Bitcoin's 128-bit security target for witness scripts. The proposal remains under discussion.In an email exchange on January 8, 2016, Gavin Andresen asked if there was a similar attack scheme possible if the network had switched to Schnorr 2-of-2 signatures. However, he quickly corrected himself and acknowledged that the scheme would still work with Schnorr.Gavin Andresen discussed the tradeoff between crypto strength and code complexity in relation to segwitness in an email thread dated January 8, 2016. He highlighted two ways of stuffing the segwitness hash into the scriptPubKey but suggested keeping the design as simple as possible. He admitted that using a 32-byte hash could compromise short-term scalability but believed it was a no-brainer.In a forum thread, Gavin Andresen responded to concerns about the security of Bitcoin's code complexity. He acknowledged the importance of a "security first" mindset but pointed out the tradeoff between crypto strength and code complexity. The message suggests ongoing discussions around the topic of Bitcoin security.Gavin Andresen asked about the timeline for a 2^84 attack on ECDSA private to public key derivation in a message. He also asked about a similar attack scheme assuming the switch to Schnorr 2-of-2 signatures.In an email exchange on the bitcoin-dev mailing list, Gavin Andresen and Pieter Wuille discuss the use of cryptography in Bitcoin. Pieter argues for using better cryptography that is up to par with security standards, while Gavin emphasizes the importance of simplicity and points out the potential vulnerabilities in the scripting language. They also discuss the security of SHA256(SHA256) over RIPEMD160(SHA256) and the implementation of segwit. The discussion revolves around collision attacks and the need for collision security to protect against such attacks. There are concerns about the vulnerability of nested hash construction RIPEMD160(SHA256()) and length extension attacks. Ethan Heilman provides an algorithm that can find targeted substrings and raises concerns about cascading the same hash function twice.
Updated on: 2023-08-01T17:33:58.387963+00:00