Isn't that basically the definition of a Ponzi scheme (or something similar to multi-level marketing)? It sure sounds like it.

This Coindesk article says that


I think I understand the first part; as transactions are created, hundreds of transactions are created that are identical except for a mutated signature are created in the network. The second part confuses me a bit, though. Do the exchange's accounting systems get out of sync because some of the original transactions aren't going through because a mutated version has already been confirmed in the blockchain? So for example, Mt. Gox, which was using an automated system to approve withdrawals (as stated in the article), would consider a withdrawal transaction approved before it was actually confirmed in the blockchain. Once a mutated version of that transaction was confirmed in the blockchain, Mt. Gox's accounting system had a problem because a transaction it assumed was confirmed (and therefore had already "lost" the Bitcoins for) wasn't actually confirmed.

I'm mostly clear on this, so I just want to make sure I'm 100%.


Unlike the unspent change problem, this *did* allow Mt. Gox to lose Bitcoins because they simply issued a new transaction. Now, both the original transaction (or the mutated version of the original) AND the completely new transaction could be confirmed in the blockchain, thus giving the individual who started the withdrawal multiple times the amount of their original withdrawal, right?

Correct me if I'm wrong, but this also relates to whatever accounting practices Mt. Gox was using because they didn't realize that overall, the # of Bitcoin inputs into their wallets wasn't matching the outputs, and that apparently this had been happening over the last few years, right? (It also seems like they just generally had accounting or financial problems independent of this, seeing as they've now declared bankruptcy)



I'm still a little unclear on what the problem is in this case. Say you spend change from a transaction that hasn't been confirmed yet. If the transaction is mutated, and that mutated transaction is confirmed, your original transaction won't go through. Is this just a problem because it allows a malicious user to DDOS part of the network (or part of the network) by submitting numerous duplicate transactions that won't cost them anything because the transactions still involve the same inputs and ouputs and only one will go through?

Basically, I'm confused as to how this is a double-spend problem because only one of the transactions will go through, so only that many Bitcoins will be sent/signed over. It's not possible for someone to use this to receive twice the number of Bitcoins that they have as unspent change, right?


This was (and still is) my assumption, but has any evidence come to light supporting it? I haven't heard much about it since the initial report.

(I know Bitcoin isn't a system of address/wallet balances, and the thread that was linked to in the 2nd post of this thread was super helpful in clarifying that for me, so hopefully my terminology of "supply of outputs", for example, isn't too far off)

On a related note, the DDOS attacks that we've been hearing about are able to occur because malicious users can look at any transactions involving an exchange and create numerous mutated versions of those transactions, thus spamming the network. Is this correct?

I'm trying to build a rough, layman's understanding of how transaction malleability works (just for my own understanding; I'm not doing anything with it). This is the rough outline I have so far based on what I've read; is this correct?

1. In the simplest case, Alice wants to send bitcoins to Bob. This creates a transaction record that consists of a signature, which proves that Alice actually holds the bitcoins she's transferring to Bob, an ID (the txid?) for the previous transaction(s) in which Alice received these coins, Bob's address, and the amount.

2. The transaction record is broadcast to the entire miner network, who verify it, add it to a block, and attempt to "solve" that block.

3. In order for Bob to spend the bitcoins that he receives, he needs to refer to it in the blockchain (using the same type of ID that Alice used in step 1). This ID is created by hashing the pieces of the transaction record.

4. Transaction malleability comes into play because, as the wiki page states, the signature doesn't cover all of the data in a transaction that's hashed to create the transaction hash. Specifically, the signature doesn't cover itself, but the hash *does* include the signature. Therefore, it's possible to change either the format of the signature or the script used to make the signature in a way that won't invalidate the validity of the transaction, but that *will* change the hash.

5. Both transactions are submitted to miners and included in blocks, and whichever block is completed first, the transaction included in that block is considered to have 1 confirmation.

Here's where I'm a little unclear. Transaction malleability isn't a problem after a transaction has at least one confirmation, right? Once a transaction has at least one confirmation, any other identical transactions (identical except for the signature, that is) won't be verified by miners, I don't think. The issue arises if a bitcoin processor/exchange allows someone to spend coins they withdrew before waiting for at least one confirmation?

This means that it's not possible for both transactions to be in the blockchain, so people/organizations affected by this won't have to go through the blockchain to find people who double-withdrew, right?

I'm still getting a grasp on this, but any feedback is most welcome.

Thanks for pointing that out. Not sure why that didn't come up in my search of the forum, but it's a very enlightening thread.

In the Bitcoin Foundation's statement on transaction malleability it says that


I see that the wiki article was created in January 2013 (i.e. well before the current situation with Mt. Gox, Bitstamp, etc.), but a search of bitcointalk.org didn't turn up any posts about the subject before 2013. Were there mailing list/forum posts, commit messages, etc. that stated that developers of custom wallets shouldn't use txid's as unique references to transactions before those transactions are confirmed in the blockchain (and should use the reference implementation instead)?