New transaction malleability attack wave? Another stresstest?

[amaclin]

What problem? Malleability? THIS IS NOT A PROBLEM.

It's problem for wallet software. Read above.

http://www.youtube.com/watch?v=unYrzvtC4Q0

[JorgeStolfi]

I think about you same too.
P.S. Do you have anything to talk about this problem not about me?

What problem? Malleability? THIS IS NOT A PROBLEM.

Sorry. I know too little about bitcoin, malleability, etc. I am newbie. You are right. I am not advanced user. Thank you for notice it.

Sarcasm does not go easily through the internet.  You should use ""even when you think it is obvious.

[siameze]

P.S. I am as an advanced user...

...there will be only one way to use bitcoin: to make one transaction in wallet -> wait until confirmation -> doing next transaction... It is stupid and very not comfortable way of bitcoin using.
What do you think about this?

I think that you are not advanced bitcoin user.

Just wanted to quote this for my "best of amaclin" compilation. Best if read while drinking Stoli and imagining amaclin's voice that of crazy Russian hacker from YouTube.

[ElectricMucus]

I think about you same too.
P.S. Do you have anything to talk about this problem not about me?

What problem? Malleability? THIS IS NOT A PROBLEM.

Sorry. I know too little about bitcoin, malleability, etc. I am newbie. You are right. I am not advanced user. Thank you for notice it.

Sarcasm does not go easily through the internet.  You should use ""even when you think it is obvious.

I think that has more to do with assburgers than internets,

[sho_road_warrior]

Looks like 0.11.1 will do something about the attack -> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011500.html

[Zombier0]

I made some money on this attack, im happy

[killaz]

I made some money on this attack, im happy

dirty money?

[shorena]

I made some money on this attack, im happy

How would you have made money due to the attack?

[mezzomix]

I made some money on this attack, im happy

How would you have made money due to the attack?

Maybe he tricked someone with a broken implementation into sending him money multiple times.

[Quickseller]

I made some money on this attack, im happy

How would you have made money due to the attack?

Easy. Send a tx to yourself, use those inputs for a second transaction to someone else who accepts 0/unconfirmed transactions, then mutate the txid of the first transaction, making the 2nd transaction invalid, allowing you to double spend the 2nd transaction.

[Perlover]

I made some money on this attack, im happy

How would you have made money due to the attack?

Easy. Send a tx to yourself, use those inputs for a second transaction to someone else who accepts 0/unconfirmed transactions, then mutate the txid of the first transaction, making the 2nd transaction invalid, allowing you to double spend the 2nd transaction.

You could do a double-spending without this attack
This attack doesn't help in this...

[Perlover]

Besides BIP 62, which will take time to finalize, what can be done to prevent this attack? What steps can wallets and payment processors take? Thanks for being a good sport.

Stop relying on others to validate your transactions and watch the blockchain for you.
Also, (this is the biggest one) don't categorize transactions based on transaction ID, then store them away and never check them again.

It's not that hard. But it's hard when the wallet is already built from the ground up under the assumption that "Once we see a transaction, even with 0 confirmations, it's as good as done."

Stop making that assumption, and code your wallets accordingly.

Also, there needs to be vigilance on the user side as well.

If you spend unconfirmed change, you are risking the chain being broken.
If you accept unconfirmed transactions with unconfirmed inputs, you are at a large risk of being double spent if you don't wait for at least one confirmation.

The only sure-fire way to prevent becoming a victim is to wait for confirmations.

Yes, these are gold rules... But many companies don't follow these rules.
The gold rule for bitcoin receivers to wait at least 1 confirmation. But many companies who paid to me don't follow these rules and after this attack i should resolve some unpaid trasnactions from them... They think that paid to me (they pay to me through some gateways) but i don't have bitcoins.

This attack has benefited. But for many it is better understood, it is necessary to continue the attack for a long time.

During time of this attack i thought that a bitcoin price will be dropped but one only grown

[Quickseller]

I made some money on this attack, im happy

How would you have made money due to the attack?

Easy. Send a tx to yourself, use those inputs for a second transaction to someone else who accepts 0/unconfirmed transactions, then mutate the txid of the first transaction, making the 2nd transaction invalid, allowing you to double spend the 2nd transaction.

You could do a double-spending without this attack
This attack doesn't help in this...

It makes it much easier. More nodes will accept the mutated transaction then would accept a transaction that outright conflicts with an existing transaction in it's mempool so the chances of getting the mutated transaction confirmed are greater.

[Perlover]

It makes it much easier. More nodes will accept the mutated transaction then would accept a transaction that outright conflicts with an existing transaction in it's mempool so the chances of getting the mutated transaction confirmed are greater.

If you make a first transaction will be first to yourself and after immadiatly you will pay to other who accept 0-confirmed tx - yes, this can help to you if your first tx will be duplicated by attacker firstly and be accepted by miners. Ok. But it's difficult way. Ok, you are right, may be it will help.

[yakuza699]

That attack won't work.If you want to malle a tx you gotta do it the same second as the other tx.Lets say you send it to a gambling site ok but you have to wait at least few seconds for the deposit to show up and for the outcome.If there's at least 1 second delay the first tx will be propagated through the nodes already.

[letsplayagame]

Looks like 0.11.1 will do something about the attack -> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011500.html

"Make the node require the canonical 'low-s' encoding for ECDSA signatures when
relaying or mining.  This removes a nuisance malleability vector."

Are there any negatives to this fix?

[gmaxwell]

Are there any negatives to this fix?

I suggest reading this thread.

Seriously. such an embarrassment.  So much grunting and flinging of poo and people don't bother to read messages of actual substance.

[mezzomix]

Are there any negatives to this fix?

If all miners use this rule, a few users with old clients that create high S signatures will not be able to get a confirmation for their transactions. A solution would be to fix their client, wait until the network forgot about this transaction an send new a transaction with a low S signature. Or somebody changes the transaction to low S by using the malleability mechanism.

[tl121]

Are there any negatives to this fix?

I suggest reading this thread.

Seriously. such an embarrassment.  So much grunting and flinging of poo and people don't bother to read messages of actual substance.

Here's my summary of the substance.

The "negative" is that old, defective implementations will no longer work.  Users of these defective implementations will have to upgrade, or if that is not possible, they will have to export their private keys and switch to newer software.

Some of us believe that this is not a "negative", rather that it is a "positive".  The fix is not just a convenience fix, it is a security fix, because the continued existence of the bug admits for denial of service attacks.  It also enables malevolent cancellation of transactions that depend on unconfirmed transactions.

[amaclin]

Users of these defective implementations will have to upgrade, or if that is not possible, they will have to export their private keys and switch to newer software.

This is very close to hardfork.
Yes. I do understand that it is not a hardfork in strict terms.