Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckM<div class="post"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=360.msg3024#msg3024">Quote from: gavinandresen on July 15, 2010, 01:05:21 AM</a></div><div class="quote"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=360.msg2982#msg2982">Quote from: bdonlan on July 14, 2010, 10:37:56 PM</a></div><div class="quote">As you can see, this tries to be more secure by hashing twice. However, this actually reduces security. To break pure SHA256, an attacker needs to find a d' such that SHA256(d') == SHA256(d), for a known d. This is also sufficient to break Hash(). However the attacker can also attack the outer layer of the hash, finding a d' such that SHA256(SHA256(d')) == SHA256(SHA256(d)), even though SHA256(d') != SHA256(d). As you can see, the double hashing here makes it _easier_ to break the hash!<br/></div><br/>If I understand correctly, you've got two chances to find a collision instead of one.<br/><br/>So this decreases the security of SHA256 by a factor of 2... which is just Not a Big Deal.&nbsp; Bitcoin is using, essentially SHA255 instead of SHA256.&nbsp; It'll still take longer than forever to find a collision...<br/></div><br/>It's true that it's not a big deal, but what concerns me is that someone went out of their way to implement an unproven hashing method, without thinking it through to realize that it actually decreases security. Things like this reduce one's confidence in the system as a whole - after all, if such a mistake exists, what other problems may be lurking?<br/><br/>What we really need is a documented protocol, so it can be audited by third parties. I'm working on reverse-engineering it from the source, but it's slow going - the intent of much of the scripting system is poorly documented.</div> text/html