New transaction malleability attack wave? Another stresstest?

[ElectricMucus]

Furthermore, when we were initially planning to begin roll-out, Peter Todd (IIRC) brought forward some very real issues with the BIP that would have potentially been problematic, so there was a general feeling that BIP 62 had not been sufficiently reviewed/considered, and was therefore too risky.

What about removing malleability altogether?
Just a thought. I know you guy's won't do that because of dumb ideological reasons.

In case that is claimed to be not clear: Enumerate every necessary use case in the transactions and remove the ability to encode anything else into transaction data.

[1715253181]

1715253181

[dooglus]

The really juicy bit about this thing is that the core developers don't want to fix it because it might prevent future vaporware uses of the bitcoin protocol to be established.
https://np.reddit.com/r/Bitcoin/comments/3nfb2y/eli5_for_double_spends_bitcoin_being_sent_twice/cvnl2wo

Any idea what this is referring to?

schemes that make malleability irrelevant are subject to dangerous signature replay attacks if not handled very carefully

Is he saying that implementing BIP 62 opens up a new known attack vector?

[amaclin]

Is he saying that implementing BIP 62 opens up a new known attack vector?

That is I wanna say

[gmaxwell]

I'm curious, why is `SCRIPT_VERIFY_LOW_S` not a standard verification flag?

Because it would block ordinary transactions from many implementations.

I have been nagging implementers on and off for a long time to fix their behavior.  In this latest round it looks like Strongcoin, Bter, Kraken, anything using pybitcointools (full of really scary broken crypto, nothing should use it), electrum (just fixed because ThomasV is awesome), were things I could easily identify.

It's been slow going-- even BIP62 only applied that restriction to flagged transactions.

If anyone feels like playing detective, here is a report someone else ran for me of addresses which were violating low-S (before the recent attacks): https://people.xiph.org/~greg/high-s-reusecnt.log (leading number is how many times the pubkey was reused in the analysis window).

Getting more implementations to produce low-s for all their transactions would be very productive.

[HCLivess]

Mods deleted my post, because I bashed your whiny attitude. So let me stress this again.
Bitcoin needs all the bugs exploited so they can be fixed for a brighter future. That you worked with some fake txs is your own problem.

[amaclin]

Mods deleted my post, because I bashed your whiny attitude. So let me stress this again.
Bitcoin needs all the bugs exploited so they can be fixed for a brighter future. That you worked with some fake txs is your own problem.

OK. Why don't you... Yes, I've said: "you"
Why don't you fix this bug now?... Yes, I've said "now"
Why should core developers fix this for *your* bright future?
What is the reason for them to carry you on their necks to a bright future?

[ElectricMucus]

The really juicy bit about this thing is that the core developers don't want to fix it because it might prevent future vaporware uses of the bitcoin protocol to be established.
https://np.reddit.com/r/Bitcoin/comments/3nfb2y/eli5_for_double_spends_bitcoin_being_sent_twice/cvnl2wo

Any idea what this is referring to?

schemes that make malleability irrelevant are subject to dangerous signature replay attacks if not handled very carefully

Is he saying that implementing BIP 62 opens up a new known attack vector?

What I meant was the idea that what goes into transaction should be "open to the user".
Imagine you had a database and added to the ability to store arbitrary information into each row, this is why rational databases exist which require you to define the type of data you want to store before you do add that information. The game of whack-a-mole is because even when they remove malleability for necessary transaction data it still doesn't prevent that attack because each entry has "scrap space" after that.
My suggestion is to abandon that concept because it's not a sane approach to storing data but a software engineering nightmare.

[dexX7]

I'm curious, why is `SCRIPT_VERIFY_LOW_S` not a standard verification flag?

Because it would block ordinary transactions from many implementations.

I have been nagging implementers on and off for a long time to fix their behavior.  In this latest round it looks like Strongcoin, Bter, Kraken, anything using pybitcointools (full of really scary broken crypto, nothing should use it), electrum (just fixed because ThomasV is awesome), were things I could easily identify.

Oh, I see, thanks! This was what I feared.

I assume the issue is mostly one of awareness and the (lack of) seeing the need to take action.

Given that the transformation seems fairly simple, it would probably help to guide the process a bit: publish information about the issue and how to tackle it. A more radical approach and counter messure could be to setup miners/nodes, which actively mutate transactions to comply. Users with non compliant transactions would be affected, which likely causes some confusion (though certainly not more than during the "attack"), but it could help to pin down specific implementations that need to be improved.

[rawbot]

And you guys have the nerve to call other crypocurrencies "shitcoins".

[EternalWingsofGod]

It is an annoyance to have my normal transactions reading as double spends from blockchain both of them are from the same source and won't fail but having a warning message appear and having it spam the network is urksome.

I wonder if any of us can double bitcoin due to this attack

Not unless we do a Bitcoin update to a new core client and have it deviate again 

[amaclin]

Not unless we do a Bitcoin update to a new core client and have it deviate again 

s/unless/if

[EternalWingsofGod]

Not unless we do a Bitcoin update to a new core client and have it deviate again 

s/unless/if

Was referencing OK pay and block 225430, I presume that when we do finally decide on what to do with 1mb it will be smooth as we all have had a long notice.
https://bitcoinmagazine.com/articles/bitcoin-network-shaken-by-blockchain-fork-1363144448

[amaclin]

paused

[JorgeStolfi]

This is great news. It exposes the vulnerabilities and weaknesses of bitcoin and allows for better cryptocurrencies, like Litecoin, to grow.

Do you mean that Litecoin does not have the mealleability bug?

[unamis76]

Apparently this is still ongoing, had it happen on a transaction of mine. The question is why and how...

Does one have to control a significant number of nodes to disrupt a lot of transactions?

[amaclin]

Does one have to control a significant number of nodes to disrupt a lot of transactions?

No need to have even one node.
The stress-test is paused right now. You can see the statistics and network health here:
http://statoshi.info/dashboard/db/transactions
Third chart "Transactions Accepted vs. Rejected"

[mallard]

This is great news. It exposes the vulnerabilities and weaknesses of bitcoin and allows for better cryptocurrencies, like Litecoin, to grow.

Litecoin is almost identical to Bitcoin, so shouldn't Litecoin also be vulnerable to the same attack?

[int03h]

No doubt someone will call me a troll .. which is the standard behavior toward people that share their opinion which happens to be contrary to the shared (although now seemingly badly fragmented, which may be a good thing in the long run. If there is descent there may still be hope) consciousness of the all holy developers (assuming of course the fragmentation isn't just a manufactured front to confuse everyone even more than they already are) :

Malleability is what the "venerable" Mr Karples blamed the fall of Mt. Gox on .. whether or not this is true can perhaps be disputed, BUT,  IF I was a developer of a piece of software that based it sole purpose of existence on the TRUST of its ability to reliably  transact in an accurate and secure fashion, I image it would be a high priority to fix any possible exploits that might expose its total lack of ability to do this - which this attack - ONCE AGAIN PROVES.  If this happens to be because of a toolkit that is broken then I would take it upon myself to provide alternative tools that might produce better results -i.e. instead of shitting on people, allowing them to eat mutated transaction that could potentially put them out of business and then call it "a good test". It's like poisoning your baby to see if it's strong enough to walk. Ridiculously retarded.  PS:  I am not calling the attacker retarded. He is highlighting a valuable lesson that needs to be learned at some point. I wonder if it will happen any time soon?

I believe it is almost November - time to light another candle.. I need to check and see if the accounting system has been deprecated yet. meh .. you know I don't actually care. This whole thing dying a slow and horrible death and the fucking retarded attitude towards the whole ecosystem makes me very very sad.

I bet this post gets deleted by his highness gmaxwell .. whatever..  

[amaclin]

I image it would be a high priority to fix any possible exploits that might expose its total lack of ability to do this - which this attack - ONCE AGAIN PROVES.

I have to repeat: fixing this particular "exploit" is more dangerous than leaving it "as is".

[int03h]

I image it would be a high priority to fix any possible exploits that might expose its total lack of ability to do this - which this attack - ONCE AGAIN PROVES.

I have to repeat: fixing this particular "exploit" is more dangerous than leaving it "as is".

I think the thing I am trying to express is that I am neither for nor against the exploit or the fix or non fix.. the point is Bitcoin is a solution stack and should be provided as such- MT Gox was the first most visible point when malleability became an issue- it should have been addressed conclusively then, why this word remain in our lexicon astonishes and perplexes me.

Credit card companies don't give people credit cards with gay abandon not knowing how it will be settled on the back end. Bitcoin should be no different if it wishes to compete with them (I believe our ideological best use scenario).