New Attack Vector

[usabitcoinbuyer]

Is there concrete evidence in the block chain?  Are there indeed altered transactions in the pool?  Is Mt. Gox blowing smoke?

In my opinion, the answers are no, possibly, and yes. 

The issue is that I create and broadcast a transaction with TxId "X".  Someone can tweak it to an equivalent (same send and receive addresses) transaction with TxId "Y".  Assuming everything else about the transactions are valid, either one (but not both) might get pulled into the blockchain.  I say there's no concrete evidence in the blockchain because the TxId only has an unambiguous meaning once it's incorporated into a block.  At any given time, it's possible that both "X" and "Y" flavors of a transaction could be floating around in different unmined tx pools, but any given miner should only accept one.  I think Mt. Gox is blowing smoke because everyone else seems to be able to deal with this issue satisfactorily, and the issue by itself doesn't explain all the problems folks are seeing at Gox.

[1714845560]

1714845560

[1714845560]

1714845560

[1714845560]

1714845560

[1714845560]

1714845560

[kano]

Interestingly other exchanges are having problems today also ...
Bitstamp and BTC-E
https://bitcointalk.org/index.php?topic=459836.0

[roy7]

Interestingly other exchanges are having problems today also ...
Bitstamp and BTC-E
https://bitcointalk.org/index.php?topic=459836.0

Bter also suspended BTC withdrawals.

[hozer]

Is there concrete evidence in the block chain?  Are there indeed altered transactions in the pool?  Is Mt. Gox blowing smoke?

In my opinion, the answers are no, possibly, and yes. 

The issue is that I create and broadcast a transaction with TxId "X".  Someone can tweak it to an equivalent (same send and receive addresses) transaction with TxId "Y".  Assuming everything else about the transactions are valid, either one (but not both) might get pulled into the blockchain.  I say there's no concrete evidence in the blockchain because the TxId only has an unambiguous meaning once it's incorporated into a block.  At any given time, it's possible that both "X" and "Y" flavors of a transaction could be floating around in different unmined tx pools, but any given miner should only accept one.  I think Mt. Gox is blowing smoke because everyone else seems to be able to deal with this issue satisfactorily, and the issue by itself doesn't explain all the problems folks are seeing at Gox.

Do you work for Gox?

Have you seen their code?

If not, then you are blowing smoke, and contributing a smokescreen to a market-manipulation coin-robbery of epic proportions.

If any exchange wants an independent review of their code, and a productive environment in which to fix any problems found,  I will do it at no cost for code that will be disclosed to the public. If you have proprietary exchange code, my retainer for an NDA starts at $5000.

We have a bunch of guys with NDAs and 'secret proprietary code' all running around issuing press releases about how the other guy sucks, while the handlers that pay their bills are scooping up all the bitcoins they can before the heroic developers, who have been working on this day and night, issue a magical fix and the price of bitcoin doubles.

If broadcasting transactions to the entire network was a good idea for bitcoin, it's probably a good idea to broadcast the code that runs exchanges too. Unless you like handing your money over to the banksters, in which case I guess I can take your money too.

[roy7]

It might be a good idea to patch this before some enterprising person with excess time on their hands (cough) makes a cloned transaction echobot.

Gotta say Enochian gets props for seeing this so far ahead of time. It's almost too bad someone didn't make an echo bot to force the issue 2 years ago, so it'd have been fixed one way or another before bitcoin was so massive.

[hozer]

It might be a good idea to patch this before some enterprising person with excess time on their hands (cough) makes a cloned transaction echobot.

Gotta say Enochian gets props for seeing this so far ahead of time. It's almost too bad someone didn't make an echo bot to force the issue 2 years ago, so it'd have been fixed one way or another before bitcoin was so massive.

While Bitcoin is brilliant in that it makes mining significantly more profitable than cracking passwords, we do not yet have an altcoin that creates currency from proof-of-exploit.

So while it's easy to see some of these holes, there are perverse financial incentives that make it significantly more profitable for news media to make superheros and villians of the developers and hackers, depending on which side of the market you are on. In the meantime they have shell companies that tie up all the people who DO see the holes with non-disclosure agreements, and exploit insider access to that information to take the unsuspecting public's money.

The first step is admitting you have a problem.

The second step is charging a retainer any time someone uses the word 'confidential', 'proprietary' or 'shareholder value'

[samson]

Well this really came back as a big issue didn't it.

[Rampion]

It might be a good idea to patch this before some enterprising person with excess time on their hands (cough) makes a cloned transaction echobot.

Yep, that might have been a good idea

[vineyard]

This actually is quite similar to another "corner case" that I've been wondering about.  Consider the following scenario:

User downloads installs bitcoin into a windows virtual machine, the copies the virtual machine to multiple locations.

Each of the virtual machines attempt to engage in transactions (receiving, sending, or even mining and block verification.)

What function is mitigating the collisions between clients, and which client becomes most authorative?  While I see how this could result in issues in transaction confirmation, wouldn't confirmations by those cloned entities result in confirmation corruption?

Collisions are handled by the Bitcoin protocol. When you submit a transaction to the network, miners will begin to try to add it to the block chain. When a miner successfully mines a block, it is added to the block chain and other miners see this and begin working off of the new top block. There is a chance that two blocks are submitted nearly at the same time - and some miners see one block and other see the other block. This results in a fork of the block chain. Some miners will be working on one prong of the fork, while others work on the other prong. At each new block, miners will always begin working on the longest prong. Eventually, the longer prong becomes so long that all mining stops on the shorter prong, and it is orphaned - never to surface again.

[DobZombie]

I believe the attack you describe is possible and real, but the effect is less troublesome. As soon as a modified echo of the transaction is included in a block, both sender and receiver will see this transaction too. The old transaction will linger on however, unconfirmed.

Ouch. I don't think he took all the variables when be made this call   

[TiagoTiago]

Perhaps i didn't read it right; does malleability cause any issues in the real world for anyone that only deals with confirmed transactions?

[DeathAndTaxes]

Perhaps i didn't read it right; does malleability cause any issues in the real world for anyone that only deals with confirmed transactions?

Potentially.

https://bitcointalk.org/index.php?topic=460944.0

The two issues that would face a user using a stock client would be incorrect reporting of duplicate tx and problems with spending unconfirmed change output.  Both are described in the linked thread. 

There are pull requests to provide better handling of both issues and eventually they will be included in the mainline client. These "fixes" don't make tx id immutable (that will require a protocol enhancement) but they will cause wallets to behave in a more expected manner when they encounter duplicate transactions. The long term solution is to make tx ids immutable (or at least immutable by third party) but that will take a lot longer as it may require a hard fork.

[crypto0sy]

For the record, there is another possibility of signature malleability.

For every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message. Note that the new signature has the same size as the original, as opposite as the malleabillity of padding.

i can complete right upto sending then i get an error.. and its not scriptsig64 i have a solution for tht

[AnnSerg77]

Why should Bitcoin protocol accept all openssl formats?
What we need is a protocol, not mad people whining in a forum. That sure won't make them change.
Thanks