New transaction malleability attack wave? Another stresstest?

[arnuschky]

Hey all,

we're seeing a lot of malleated transactions on our nodes. Anyone else?

Tx listed on https://blockchain.info/double-spends are also all malleated (click on links, if marked as "conflicted" blockchain.info has seem two versions of the same* tx).

What's the point? Another stresstest?

* or close enough

[amaclin]

yes

[RussianRaibow]

Hey all,

we're seeing a lot of malleated transactions on our nodes. Anyone else?

Tx listed on https://blockchain.info/double-spends are also all malleated (click on links, if marked as "conflicted" blockchain.info has seem two versions of the same* tx).

What's the point? Another stresstest?

* or close enough

Here is a case of such double-spending - https://bitcointalk.org/index.php?topic=1197096.0

Even after 29 days of broadcast, while one Tx has already got confirmed, another is still hanging in some node's mempool...

https://live.blockcypher.com/btc/tx/07dd024065a6ef12652670618e510503e1af4e0f4d75ddc6f4d2a55f002c9bc0/

[chronicsky]

It's strange , i have something very similar....
I do not own a miner or anything but just now i sent some payments though it doesn't show up in my blockchain wallet unless i login. I see two txs to same address of same amount , one confirmed and one not. and there is a incoming tx which is not confirmed and probably double -spent but which is not possible , it was sent using CoinBase...
Anyone knows, what's going on ?

[amaclin]

https://www.reddit.com/r/Bitcoin/comments/3n5zvw/can_someone_help_explain_what_happened_here/
https://www.reddit.com/r/Bitcoin/comments/3n72yq/ongoing_bitcoin_malleability_attack_low_s_high_s/
https://www.reddit.com/r/Bitcoin/comments/3n62l8/bitcoins_stuck_with_blockchaininfo_shared_coin/
http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high

[arnuschky]

Interestingly, it seems that the later transactions (ie, the malleated one, not the original one) that are confirming.
At least in our case.

Can someone confirm this? More importantly, if your transactions are being malleated, which one is confirming?
Yours or the other one?

Some explanation: Malleated transactions face the same difficulty as doublespends: they need to be accepted
by a miner before the original tx (or the miner needs to replace the original tx). The first case isn't very likely,
the second requires the miner to run some non-standard software (Peter Todd's RBF-FSS).

If it's mostly malleated transactions that are confirming, we're facing something new. Either someone is
colluding with miners, or many miners are running RBF-FSS, or there's a bug.

[chronicsky]

The real problem am facing here because of this is not 0 confirmation but something else...
one incoming tx is pending , which will sooner or later be ok i suppose....
BUT, i sent some coins and now when i open my wallet and check - it shows me two similar tx to same address - one confirmed and one not....
How does it affect me ??





The bitcoins has been deducted twice and am not getting it back i suppose...


any ideas?

[arnuschky]

The real problem am facing here because of this is not 0 confirmation but something else...
one incoming tx is pending , which will sooner or later be ok i suppose....
BUT, i sent some coins and now when i open my wallet and check - it shows me two similar tx to same address - one confirmed and one not....
How does it affect me ??



The bitcoins has been deducted twice and am not getting it back i suppose...

any ideas?

This is the malleability problem: someone is creating copies of transactions that result in the same result but look different to the network (different transaction id).
In your screenshot, you see that both transactions are "doing" the same thing. They are basically the same tx under a different name.
As long as one of the two confirms, you're good. You can ignore the one that does not confirm.

And no, bitcoins aren't deducted twice, don't worry. Only confirmed ones count towards your balance.
Note that your wallet software might be confused and thus show an incorrect balance until the unconfirmed tx is discarded.

[chronicsky]

The real problem am facing here because of this is not 0 confirmation but something else...
one incoming tx is pending , which will sooner or later be ok i suppose....
BUT, i sent some coins and now when i open my wallet and check - it shows me two similar tx to same address - one confirmed and one not....
How does it affect me ??



The bitcoins has been deducted twice and am not getting it back i suppose...

any ideas?

This is the malleability problem: someone is creating copies of transactions that result in the same result but look different to the network (different transaction id).
In your screenshot, you see that both transactions are "doing" the same thing. They are basically the same tx under a different name.
As long as one of the two confirms, you're good. You can ignore the one that does not confirm.

And no, bitcoins aren't deducted twice, don't worry. Only confirmed ones count towards your balance.
Note that your wallet software might be confused and thus show an incorrect balance until the unconfirmed tx is discarded.

Actually i checked and the balance has been deducted twice , means i will get this btc back once the unconfirmed tx clears? but we can't say it will even clear right

[shorena]

-snip-
Actually i checked and the balance has been deducted twice , means i will get this btc back once the unconfirmed tx clears? but we can't say it will even clear right

Well for bitcoin core you could just rescan the wallet, Im not sure how you would do that with... what looks like blockchain.info.

[chronicsky]

-snip-
Actually i checked and the balance has been deducted twice , means i will get this btc back once the unconfirmed tx clears? but we can't say it will even clear right

Well for bitcoin core you could just rescan the wallet, Im not sure how you would do that with... what looks like blockchain.info.

yeah that's blockchain.info

Seems it's finally time i switch to bitcoin core as well..

Hope fully soon it will be ok....

Thanks

[amaclin]

This is the malleability problem: someone is creating copies of transactions

OK. This is not "someone". It is me.
Right now the stress-test is paused. I reserve a right to resume it.
Ask me anything.

[chronicsky]

This is the malleability problem: someone is creating copies of transactions

OK. This is not "someone". It is me.
Right now the stress-test is paused. I reserve a right to resume it.
Ask me anything.

if it's really you! you owe me some btc
I mean really , why

[amaclin]

I mean really , why

Because I am able to do it.

[chronicsky]

I mean really , why

Because I am able to do it.

With Great power comes great responsibility my child......

PS - all tx removed , got mail by Blockchain.info , incoming one removed , will send it again and duplicate txs also removed...

and yes , duplicate txs had deducted the btc which i got back now

[amaclin]

With Great power comes great responsibility my child......

Not in bitcoin world. Responsibility for whom? I do not know you. You do not know me.
There is no third party who can punish me, because I am wrong and you are right.

[chronicsky]

With Great power comes great responsibility my child......

Not in bitcoin world. Responsibility for whom? I do not know you. You do not know me.
There is no third party who can punish me, because I am wrong and you are right.

well, wateva...
Do as you like...

[basil00]

OK. This is not "someone". It is me.

I am not surprised.  You were my prime suspect.

This "attack" probably stops spam scripts that generate long chains of unconfirmed txs.  It might actually be a good thing to leave this running.

[amaclin]

This "attack" probably stops spam scripts that generate long chains of unconfirmed txs.

The main word is "probably".
Spam engine should not broadcast predefined set of transactions, but should monitor all transactions on the network from different nodes and build on-the-fly next transaction on top of previous one received from the peer. Splitting the "chain" to a "binary tree" just adds more fun

Better way to stop spam is to malle spammer chain txs on mining pool.

It might actually be a good thing to leave this running.

I do not think so. I do not see any benefits for me running it. Today.

[basil00]

Splitting the "chain" to a "binary tree" just adds more fun

This is also the correct way to do it.

I do not see any benefits for me running it.

Perhaps to remind the community not to rely on chains of unconfirmed txs.

Btw, I wonder if it is possible to design scripts immune to this attack, e.g.

Code:

OP_SIZE 73 OP_EQUALVERIFY <pubKey> OP_CHECKSIG

The wallet software needs to "mine" a 73byte sig (not very hard).
The malleated sig is always 1 byte bigger, so cannot be used.