About Ongoing Bitcoin Malleability Attack

[OmegaStarScream]

Yes before you link to that CoinKite article , I already read it . however I still don't get it ... Our funds are logically not going to be compromised or anything however when I send BTC what should do so the other user actually receive them and he don't get the attack ? nothing ?  It's simply by luck ? I can send 1 BTC and simply "hope" so he will receive them ? if he don't my BTC are screwed ?  because this make no sense honestly and is this attack permanent ?

[LiteCoinGuy]

In order to understand the transaction malleability attack, it helps to first understand the basics of how Bitcoin transactions work. In simplified form, each transaction over the Bitcoin network consists of different types of data. This includes transaction inputs (refering to the addresses bitcoin come from), transaction outputs (refering to the addresses bitcoin are sent to), the amount of bitcoin sent, and more. All of this data is cryptographically signed, combined, and scrambled (“hashed”) into a unique and smaller piece of data: a hash. This hash is essentially the transaction ID. If a miner confirms the transaction, the transaction ID is included in a block and stored in the blockchain.

The problem that enables transaction malleability, however, is that effectively identical signatures can result in completely different hashes. The specifics of this are deeply cryptographic, and are very hard – if not impossible – to explain in plain English. But as one extremely simplified example to get an idea of the problem, a comparison would be that the numbers “145” and “0145” are effectively the same number in many cases. But when hashed, “145” and “0145” might actually produce completely different results.

In the case of the ongoing transaction malleability attack, the attacker picks transactions from the Bitcoin network, and tweaks signature data. As a result, all sorts of transactions have two completely different transaction IDs circulating on the Bitcoin network. And since a specific transaction can confirm only once, just one of the transaction IDs will be included in a block, while the other will be ignored.

Are transaction malleability attacks a problem?

The essence of the transaction malleability problem arises when someone uses the transaction ID – and nothing but the transaction ID – to check whether a transaction has been included in a block. This is a problem, of course, because the transaction ID may have been changed by the attacker, and his new transaction ID could have been included in the block rather than the original transaction ID. It might then seem as if the transaction itself never went through – though it effectively did.


tltr: You will never lose a Bitcoin because of this "attack". it is just a little bit annoying. the attack will be there as long as the attacker is doing it or we add a patch to bitcoin.

[OmegaStarScream]

There is no need for TL;DR for me , I read all . But if you say that we never lose our bitcoins then how do you explain last time on Bit-x.com (just an example) signature compaign , some people got affected with this attack and never received their coins , and Bit-x had to send us the payouts once again , so the first BTC that they sent and we never received them ... where are they if they are not "lost" ?

[d3former]

There is no need for TL;DR for me , I read all . But if you say that we never lose our bitcoins then how do you explain last time on Bit-x.com (just an example) signature compaign , some people got affected with this attack and never received their coins , and Bit-x had to send us the payouts once again , so the first BTC that they sent and we never received them ... where are they if they are not "lost" ?

It all depends on how many confirmations.  More then likely they had something set too low for confirmations settings.

[shorena]

There is no need for TL;DR for me , I read all . But if you say that we never lose our bitcoins then how do you explain last time on Bit-x.com (just an example) signature compaign , some people got affected with this attack and never received their coins , and Bit-x had to send us the payouts once again , so the first BTC that they sent and we never received them ... where are they if they are not "lost" ?

Let me make two examples, first the one where no problems occure but the whole things is a bit annoying.

Alice wants to send coins to Bob and issues a transation. The TX uses confirmed(!) inputs since Alice received the coins weeks ago. The TX gets modified along the way and Bobs wallet freaks out slightly. It could e.g. show a wrong balance because it shows the inputs from Alice twice. Once one of the two TX is confirmed, Bob does a rescan for the wallet and everything is fine.

Now a variant that might have happened with Bit-x, because they are a service and send coins on a regular basis.

Alice sends coins to Bit-x. The coins are added to her balance and she is happy. Before the transaction is confirmed Bit-x uses the coins to issue payment for their signature campaign. Because of the way transactions work, they point to the TX ID Bit-x received first. While they did this, the TX was modified and got another TX ID. Now we have two competing transactions. One where everything is fine and one where the follow up TX to the participants of the campaign gets invalid. If the modified TX gets confirmed (which happens) the follow up TX requires a TX ID that can not confirm. Thus it becomes invalid as well. Nodes start to drop it from their memory or at the very least no longer relay it.

The participants got no payment and Bit-x needs to make sure their code does not issue TX that use unconfirmed inputs.

[OmegaStarScream]

There is no need for TL;DR for me , I read all . But if you say that we never lose our bitcoins then how do you explain last time on Bit-x.com (just an example) signature compaign , some people got affected with this attack and never received their coins , and Bit-x had to send us the payouts once again , so the first BTC that they sent and we never received them ... where are they if they are not "lost" ?

Let me make two examples, first the one where no problems occure but the whole things is a bit annoying.

Alice wants to send coins to Bob and issues a transation. The TX uses confirmed(!) inputs since Alice received the coins weeks ago. The TX gets modified along the way and Bobs wallet freaks out slightly. It could e.g. show a wrong balance because it shows the inputs from Alice twice. Once one of the two TX is confirmed, Bob does a rescan for the wallet and everything is fine.

Now a variant that might have happened with Bit-x, because they are a service and send coins on a regular basis.

Alice sends coins to Bit-x. The coins are added to her balance and she is happy. Before the transaction is confirmed Bit-x uses the coins to issue payment for their signature campaign. Because of the way transactions work, they point to the TX ID Bit-x received first. While they did this, the TX was modified and got another TX ID. Now we have two competing transactions. One where everything is fine and one where the follow up TX to the participants of the campaign gets invalid. If the modified TX gets confirmed (which happens) the follow up TX requires a TX ID that can not confirm. Thus it becomes invalid as well. Nodes start to drop it from their memory or at the very least no longer relay it.

The participants got no payment and Bit-x needs to make sure their code does not issue TX that use unconfirmed inputs.

ty for the help so I see after you explained it it makes more sense (had to read couple of times the second part but finally got it xD )  . I thought there was only one issue & it seems like there is two