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

It's not good news for bitcoin users.

Thanks for explaining your view on the things gmaxwell. I think this attack can only help bitcoin. Showing if the attack vector is really a problem, pushing the funding of code to go against.

I think the influence on the network is rather small anyway.

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.

The development of bitcoin was never decentralised, looking at it from a wider angle, the blockchain itself is a centralised system(the blockchain) on which we entrust the bitcoin economy. The meaning of decentralisation is that there is not a single entity but the blockchain itself, until there is someone who can make and overtake a mining rig so powerfull it will mine all the remaining blocks and will not share the technology.

This will however result in a non trustworthy blockchain and the whole thing crumbles before the one investing so hard to gain control will have the biggest loss. "Now you're king of the mountain, but it's all garbage!"

Only primitive organisms. Worms for example.
Ants have primitive centralization. They can build an anthill.
People can work in fully centralized community. They are launching rockets to Mars.

BTC lost  its decentralization when some smart guy decided to mine on his video card and another clever guy organized a pool.

People can work in fully centralized community. They are launching rockets to Mars.

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.

you are right, seems BTC is loosing decentralization
but that just means... nothing can be decentralised for real

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.

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?

Bitcoin is decentralized. Nobody can "push a fix soon".
Yes, I do understand, that today we have a very small number of miner pools.
And it is quite possible to developer team to communicate with admins and ask them to implement a "small and very good patch" in code.
What does it mean?
This means, that all words about the "real decentralization" have been forgotten.
And the community is under the control by core devs and pool owners.

Should we test this case?
I can resume malleability stress-test in any moment

Well according to this article, a fix might get pushed soon.

Should we test this case?
I can resume malleability stress-test in any moment

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