Bitcoin maleabity attack - who made it and is it still running?

[forzendiablo]

i read somewhere that somebody said its him doing the attack yet i cannot find this post.

so my questio nis - who did this attack and is it still running?

[1715414735]

1715414735

[1715414735]

1715414735

[1715414735]

1715414735

[EthanB]

Anybody with a little bit of programming/bitcoin knowledge can easily perform this; hence there are many people doing it in an attempt to force improvement through the bitcoin network because it has already proven to be detrimental.
It is still occurring.

[dothebeats]

It is still ongoing as of this moment, and the certain user who performed it is this one: https://bitcointalk.org/index.php?action=profile;u=197593

You can find the thread regarding the attack here: https://bitcointalk.org/index.php?topic=1198032.0

[Kprawn]

I find it strange that all these technical loopholes have been found recently, and not a lot before that. I wonder how all of this fits into the Bitcoin Core vs Bitcoin XT debate.

It's pure speculation, but things has gone crazy, since this whole split has happened. The person doing this malleability attack has a lot of technical information of the inner

workings of Bitcoin, so it's probably a engineer or a developer? 

[dothebeats]

I find it strange that all these technical loopholes have been found recently, and not a lot before that. I wonder how all of this fits into the Bitcoin Core vs Bitcoin XT debate.

It's pure speculation, but things has gone crazy, since this whole split has happened. The person doing this malleability attack has a lot of technical information of the inner

workings of Bitcoin, so it's probably a engineer or a developer? 

Check the user that I've just linked to here and also read the whole thread that I've just linked. The user claims that he doesn't use bitcoins and as I see it, is a pro-bankster. Cool, right? He seems to have a lot of knowledge regarding that certain attack vector on bitcoin.

[EthanB]

I find it strange that all these technical loopholes have been found recently, and not a lot before that. I wonder how all of this fits into the Bitcoin Core vs Bitcoin XT debate.

It's pure speculation, but things has gone crazy, since this whole split has happened. The person doing this malleability attack has a lot of technical information of the inner

workings of Bitcoin, so it's probably a engineer or a developer? 

Bitcoin has been growing extremely rapidly the past few years, and this brings a lot more pressure to any faults and flaws within the code.
More eyes and more incentive these days.

[Mickeyb]

I find it strange that all these technical loopholes have been found recently, and not a lot before that. I wonder how all of this fits into the Bitcoin Core vs Bitcoin XT debate.

It's pure speculation, but things has gone crazy, since this whole split has happened. The person doing this malleability attack has a lot of technical information of the inner

workings of Bitcoin, so it's probably a engineer or a developer? 

Isn't this the same old transaction malleability that has already happened last year? Markets have then reacted much wilder and we have seen major drops in price. I thought this is the same old problem.

As I know a BIP 62 is here to solve this problem but this BIP 62 still hasn't been finished and deployed successfully!

[celebreze32]

The attacker can't steal your money. All the attacker can do is change your transaction ID, then re-transmit it very quickly to send Bitcoins to the same address they were originally intended to be sent to. One of the transaction IDs has to be accepted by the network,and the other has to be discarded. Your Bitcoins still get sent to the address they were intended to go to, but sometimes they arrive with a different transaction ID than you were expecting if your transaction gets attacked.

[twister]

The attacker can't steal your money. All the attacker can do is change your transaction ID, then re-transmit it very quickly to send Bitcoins to the same address they were originally intended to be sent to. One of the transaction IDs has to be accepted by the network,and the other has to be discarded. Your Bitcoins still get sent to the address they were intended to go to, but sometimes they arrive with a different transaction ID than you were expecting if your transaction gets attacked.

Yes that's all they can do but it affects certain transaction which rely on the transaction ID, for example if you're live betting and you send in a bet, it gets accepted but then the other one is sent with different ID and the 2nd one gets confirmed and by that time the odds have changed, one other affect of it is, someone I know reloads his mobile using BTC, so he sended the BTC and waited but never received his reload because his transaction under original ID was never confirmed and the other one did but the website didn't recognize that as it relies on the Tx ID.

And OP it is still going on, I did many transactions today and couple of those were resent using different ID and thankfully it didn't affected anything, other than the Blockchain.info warning saying that this address has double spends.

[Q7]

From what I can see, it's somebody who is out to destroy bitcoin. What is there to gain by carrying out the attack only to cause inconvenience to the users. Obviously it is the trust and reputation factor that is at risk here because people see bitcoin as a reliable payment system. I'm also surprised that after so many years there is still loophole in the system that can be exploited.

[tl121]

From what I can see, it's somebody who is out to destroy bitcoin. What is there to gain by carrying out the attack only to cause inconvenience to the users. Obviously it is the trust and reputation factor that is at risk here because people see bitcoin as a reliable payment system. I'm also surprised that after so many years there is still loophole in the system that can be exploited.

The problem is that a known bug in the bitcoin protocol has festered for years.  If the "core" developers had been doing their job, this problem would have been fixed long ago.

[amaclin]

Check the user that I've just linked to here and also read the whole thread that I've just linked.
The user claims that he doesn't use bitcoins and as I see it, is a pro-bankster.
Cool, right? He seems to have a lot of knowledge regarding that certain attack vector on bitcoin.

1) I use bitcoins. But I do not hold them. Sorry for some misunderstanding. My English is not perfect.
Let me give an example:
I eat watermelons. But I do not buy watermelons for investing.
Because I do not think that I would be able to sell the watermelon tomorrow with profit.
And I advise to everyone not to invest and hodl watermelons.

2) I am not pro-bankster.
I just say, that keeping money in pockets is better than investing in watermelons

[unamis76]

You can check if it's still running here, on the third graph

[maokoto]

Some scam sites have taken advantage of this attack as an excuse to dissappear/lost deposits/lost withdrawals. Been a hard week for some.

[christycalhoun]

Would there be a way for the attacker to use this explout to steal bitcoins from people? I am not an expert on this stuff.

[gmaxwell]

The problem is that a known bug in the bitcoin protocol has festered for years.  If the "core" developers had been doing their job, this problem would have been fixed long ago.

There are a dozen different malleability vectors in the protocol as originally designed; some are quite useful and important intentional features-- others are not.  Though the harm from malleability is very moderate-- and because of the intentional features and the potential for ordinary double spends, wallets must have basically sane handling for it--, unwanted third party malleability is a nuisance. In Bitcoin Core's wallet the nuisance can be greatly mitigated by setting spendzeroconfchange=0.

Because of it being a nuisance all of vectors for malleability except for one were blocked as non-standard transactions in Bitcoin Core years ago.  The remaining one could not be simply blocked because it requires transactions to confine their signatures to a particular form-- low-S-- and all software was violating before the issue was known.  Because of this applying that final constraint would have blocked almost all transactions on the network-- something not justified for a nuisance level attack. Bitcoin Core changed constrain its own transactions to this form in 2013 but it has taken a long time for other software to update themselves. Fortunately, the final remaining type of malleability was ever so slightly trickier to exploit, so people haven't been doing so at scale. In the meantime a proposal was made, as part of BIP62, for a v3 transaction type where parties creating transactions could opt into the protective behavior if they were recent enough to support it. Unfortunately BIP62 is fairly complex and no one outside of a small group of contributors to Bitcoin Core have cared at all about advancing it.  So we've been breaking up parts of them and applying them to the consensus incrementally (e.g. BIP66).

Current git master Bitcoin Core enforces the requirement for all transactions it relays or mines, once this is in a release and widely deployed it will end this irritation; but it will also block most transactions from small portion of the network on software which is out of date or hasn't been updated to produces anti-malleability-friendly low-S signatures (on the order of 5% of all transactions now; due to ongoing efforts to harass parties to fix their wallet software).

I've called for assistance several times in identifying the origin of a list of lowS violating transactions in order to help speed deployment of this, but it seems that the Bitcoin community is a lot more interested in whining and throwing blame then stepping up and doing a little bit of the non-development work needed to get this deployed.

[Mickeyb]

Would there be a way for the attacker to use this explout to steal bitcoins from people? I am not an expert on this stuff.

No I don't think so. Only a great danger of double spending as far as I know!

[tl121]

The problem is that a known bug in the bitcoin protocol has festered for years.  If the "core" developers had been doing their job, this problem would have been fixed long ago.

There are a dozen different malleability vectors in the protocol as originally designed; some are quite useful and important intentional features-- others are not.  Though the harm from malleability is very moderate-- and because of the intentional features and the potential for ordinary double spends, wallets must have basically sane handling for it--, unwanted third party malleability is a nuisance. In Bitcoin Core's wallet the nuisance can be greatly mitigated by setting spendzeroconfchange=0.

Because of it being a nuisance all of vectors for malleability except for one were blocked as non-standard transactions in Bitcoin Core years ago.  The remaining one could not be simply blocked because it requires transactions to confine their signatures to a particular form-- low-S-- and all software was violating before the issue was known.  Because of this applying that final constraint would have blocked almost all transactions on the network-- something not justified for a nuisance level attack. Bitcoin Core changed constrain its own transactions to this form in 2013 but it has taken a long time for other software to update themselves. Fortunately, the final remaining type of malleability was ever so slightly trickier to exploit, so people haven't been doing so at scale. In the meantime a proposal was made, as part of BIP62, for a v3 transaction type where parties creating transactions could opt into the protective behavior if they were recent enough to support it. Unfortunately BIP62 is fairly complex and no one outside of a small group of contributors to Bitcoin Core have cared at all about advancing it.  So we've been breaking up parts of them and applying them to the consensus incrementally (e.g. BIP66).

Current git master Bitcoin Core enforces the requirement for all transactions it relays or mines, once this is in a release and widely deployed it will end this irritation; but it will also block most transactions from small portion of the network on software which is out of date or hasn't been updated to produces anti-malleability-friendly low-S signatures (on the order of 5% of all transactions now; due to ongoing efforts to harass parties to fix their wallet software).

I've called for assistance several times in identifying the origin of a list of lowS violating transactions in order to help speed deployment of this, but it seems that the Bitcoin community is a lot more interested in whining and throwing blame then stepping up and doing a little bit of the non-development work needed to get this deployed.

Please explain (or reference an explanation) as to why malleability features would be quite useful.

Also, I would like to understand why people care about old implementations that aren't being actively maintained by people who are following bitcoin.  Please explain why it matters what happens to these old implementations?  Why should you or anyone else waste effort to dig up these issues?

[knowhow]

Those attack can be anyone from credit cards companys ,google or any person with huge skills trying to get into the team of bitcoin,we will never know why and who are attacking it,to destroy well if there is a hole to attack the team should be working in something to close it before too late,i cant imagine bitcoin being hacked and controlled by some hacker..... destroying all crypto instantly.

[amaclin]

we will never know why and who are attacking it

never say never.
it was me behind this particular stress-test
i am not from bank company and do not work for google