Published on: 2014-02-10T20:55:21+00:00
In February 2014, a conversation took place regarding the issue of stalled transactions on MtGox. The discussion mentioned that if an attacker had a direct connection to MtGox, they could receive the transaction directly. However, it was not just attackers who used this script; some people also tried to fix their transactions with honest intent but ended up confusing MtGox's software.The conversation further discussed a potential attack on the Bitcoin blockchain involving renaming transaction IDs before confirmation. By doing so, an attacker could potentially add a new transaction while discarding the original as a double-spend. However, the actual problem with MtGox was that the produced transaction was poorly formatted, causing it to stall. An attacker with a direct connection to MtGox could fix the formatting and forward it normally to the network. They would then stress Gox support and refer to the original transaction ID to trick them into refunding Bitcoins to the attacker's virtual Gox-wallet. To prevent this, the new transaction should re-spend at least one of the coins from the first transaction.In September of 2014, many customers experienced stuck transactions due to MtGox spending immature coins. It was later discovered that these transactions had invalid DER encodings, which led to mutation being used to fix them. There were suspicions that someone may have been exploiting Gox's behavior by reusing already spent coins in new transactions.In a 2014 email exchange, Pieter Wuille expressed surprise at MtGox's announcement of transaction malleability, stating that it had been a known issue for years. He acknowledged that it made infrastructure interactions with Bitcoin more challenging. A question was raised about how attackers could benefit from renaming transaction IDs, fooling Gox support to refund paid Bitcoins. The questioner wondered why so many customers experienced payment defaults or delays when the attacker could double their own transaction. Pieter proposed defining a normalized transaction ID as a way to identify transactions unambiguously.Another discussion on the bitcoin-development mailing list criticized MtGox for blaming a documented bug and accused them of market manipulation. Pieter Wuille responded by noting that transaction malleability was already known and proposed a normalized transaction ID. The concern about off-list discussions and insider power was also raised, suggesting more technical details should be shared publicly. The writer called for transparent code evolution and questioned why revolutions always put the same old things back in power.A member of the Bitcoin-development mailing list expressed frustration with MtGox's lack of transparency and demanded more technical details on their scalability and usability problem. They argued that private off-list discussions were equivalent to insider trading, suggesting that releasing MtGox's code under an AGPLv3 license would solidify their position as transparent market leaders. Pieter Wuille responded by explaining the known issue of transaction malleability and proposing a normalized transaction ID. Another member emphasized that demanding access to MtGox's private code was not the solution and that customers could sue if they felt wronged.The writer expressed concern over off-list discussions and market manipulation, calling for technical details to be shared publicly. Pieter Wuille acknowledged transaction malleability as a known issue and proposed a standardized way to identify transactions. The writer called for transparency and code evolution and asked about a third-party archive of bitcointalk.org.Pieter, a Bitcoin developer, responded to MtGox's announcement about transaction malleability, noting that it had been a known issue for years. He mentioned two direct problems: wallets dealing poorly with modified txids and services using transaction IDs to detect unconfirming transactions. He proposed defining a normalized transaction ID as SHA256^2(normalized_tx + 0x01000000) to make people more aware of the issue. This proposal can be found on GitHub.
Updated on: 2023-08-01T07:39:20.409535+00:00