Topic: Bitcoin maleabity attack - who made it and is it still running? - page 3. (Read 3862 times)

Yeah, something is definitely up, my transactions have been stuck for 2+ hours, they were medium priority which usually takes upto 6 blocks and there have been 10 blocks since then and they still haven't moved, I think they might get stuck for infinity. If only I knew that there's another stress test I would have added extra fee.

Thanks for the link.

What if there is another wave of malleability attack whilst the spam attack is underway, it could really turn things upside down. 

http://statoshi.info/dashboard/db/transactions
right now there is some sort of "turbulence" there.
the reason of "turbulence" is https://bitcointalksearch.org/topic/m.12623681

increasing tx fee right, well there must be only one responsable, a miners, it's in their interest to increase the fee at all cost

so i'll not be surprised if they are again the one to blame for this

Attack seems to be back on and seems to have been predicted by mempool increase:

The problem in your example is not changing some code.  It's an architectural question.  What is the meaning of a "transaction", in other words what is the object that a transaction id references?  Binding time issue.  if there is lack of clarity here, then there is no hope for a clean software design or bug free operation.

Reasonable people running old software have no problem switching to new software.  Anyone who has used computers for more than a few years understands that technology changes and people have to keep up.  It's the way the industry works.  The most these people have a right to expect is a migration path from old software to new software that enables them to keep their coins.

There is at least one poster on this forum who is claiming credit for this, FWIW.

At this point, years after the bug has been identified, there really isn't much of an excuse for not having plugged this hole.  But then, the philosophy of the so called leaders is not to make and execute any decisions that might inconvenience anyone. In other words, abdicate leadership.  A strong leader has to make decisions and take responsibility for the consequences, including the possibility that people won't follow him and he may have to find a new job or even a new career.

This has been delaying all the transactions and been the cause for many vendors and other service providers to increase the tx fee.

Does anyone knows or at least has a suspicion on who's responsible for this bug exploit?

For example, anyonecanpay sighash flag allows arbitrary parties to add funds to a transaction. It's what makes lighthouse possible, but every time someone updates the transaction the txid changes.

Because they are widely used (or had been historically-- we're getting to the point where .this is less true). Just blocking the transactions for non-trivial amounts of users does not yield a good experience, to say the least. Forcing people to constantly rev their software reduces decentralization-- and who precisely has the authority to go decide what is "old" or "actively maintained"?--if people are happy happy with what they're running, I am not eager to disrupt that.  I am also not eager to try to dictate how often authors of wallet software must revise their software (again, something that would reduce decentralization-- by pushing out development teams with less resources).  As to why you should care and go help move them along: it's cheap to do, and the failure to do so holds the ecosystem back.--- the same reason I've done so.

If you note the patch I linked to, my change was only a few characters--- why? because the code was already written a long time ago... but not activated due to waiting for the ecosystem to catch up; we're ready.

Why is the mempool increasing in size so quickly if the attack is now stopped? It's now 909.7 MB which is the largest size I've ever seen, not that I regularly keep a track of it. It's the largest size in the lat seven days according to tradeblock. Something must be causing it, and it's not unconfirmed transactions this time. I thought its size would reduce after the attack stopped.

When malleability attack is running you will see this:



Attack ended 10/5 about 10:00 and is not ongoing right now.

I am a code developer, but my main work is not bitcoin-related. I am employee in small it-company.
Bitcoin technolodgy is a hobby.

I understand you are a developer, but which industry do you serve as an employee or an employer ?

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

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.

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

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.

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.

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

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