Bitcoin Forum
May 22, 2024, 12:42:33 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Explain the gox transaction malleability issue like you are five  (Read 10169 times)
ManeBjorn
Legendary
*
Offline Offline

Activity: 1288
Merit: 1004



View Profile
February 11, 2014, 06:25:59 PM
 #41

Now this is going on.

http://www.coindesk.com/massive-concerted-attack-launched-bitcoin-exchanges/

dorobotsdream
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
February 11, 2014, 06:33:57 PM
 #42

...

Malleability is a potential and hypothetical issue nuisance, which only became possible to exploit at MtGox for two reasons: because Gox failed to correctly implement Bitcoin specification properly, and also because it failed to implement proper workarounds for this issue. You correctly pointed out second reason, but the first is more important to point out, in my opinion, because this is why other exchanges are much less likely to be affected, if likely at all.
Gox didn't follow the specification, which required tx signature to be encoded with ASN1/DER encoding. This requirement was specified in April 2011: https://en.bitcoin.it/wiki/Protocol_specification#Signatures
Instead they used some sloppy format which was not DER encoding but was still accepted by SSL library and old reference client. When tighter checks were implemented in bitcoin reference client (the main reason for which was actually to prevent malleability issue), their transactions, which violated bitcoin spec, were rejected. Basically, their transactions looked like what hackers would employ to exploit this issue. That allowed hackers to pick these rejected transactions up, malleate them to "fix" the signature format, and re-submit. Ironically, hackers were helping MtGox to propagate their malformed transactions through the network.

I have looked up the change logs of the Bitcoin client of the previous year, and I have yet to find any sign that the client switched to more stringent checks. There are some code changes on github that you referred to earlier, but even if those made it into the default client they wouldn't go as far as to fix the problem, because these code changes still leave open lots of room for malleability. But with access to good mining equipment it would be somewhat easy to race the original transaction being transmitted on the bitcoin network with your manipulated version.

I would still like to see an actual instance of the original Mt. Gox transaction and the transaction that got in the blockchain instead and who mined that.
dorobotsdream
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
February 11, 2014, 08:08:44 PM
 #43

Code:
2 + 3 = 5
is a mathematically true statement.

Code:
2 + 3 + 0 = 5
is mathematically true, and in fact is the same statement.

They've got different hash values though, because hash functions care about binary representations, not mathematical equivalence.

 Cheesy Good one

If you compare the signature on the bitcoin transaction (on an input of it actually, like a transaction is composed of multiple checks.) with a traditional  Roll Eyes  wet handwritten signature, then the malleability is like the signature being done in another color of ink. A grafologist would still conclude that the purported sender could have made that signature, if he didn't know that the real sender always used a very specific color and composition of ink.
freebitcoinwin
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
February 11, 2014, 08:34:12 PM
 #44

Good explanation. Thank you.
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!