New transaction malleability attack wave? Another stresstest?

[amaclin]

Is the attack ongoing again?

yes

Yesterday it caused me to waste an hour of time because funds in my trezor were unspendable,

Complain to yourself and the developers of your software/hardware.

I had to restore wallet from seed on another device then create new trezor wallet to send the funds there. Annoying...

Any suggestions?

[1714048805]

1714048805

[1714048805]

1714048805

[dothebeats]

Is the attack ongoing again?

Yesterday it caused me to waste an hour of time because funds in my trezor were unspendable, I had to restore wallet from seed on another device then create new trezor wallet to send the funds there. Annoying...

Good thing you only wasted an hour. I'm waiting for over 6 hours for this particular transaction to confirm: http://btc.blockr.io/zerotx/info/844f88ef20fb5d2d2ecf897772d429d9bca1d3cab6314e5ed3017b48940f096a

[basil00]

Good thing you only wasted an hour. I'm waiting for over 6 hours for this particular transaction to confirm: http://btc.blockr.io/zerotx/info/844f88ef20fb5d2d2ecf897772d429d9bca1d3cab6314e5ed3017b48940f096a

This tx will not confirm.  It belongs to a tx chain that has already been invalidated by a malleated tx (original is here).

[shorena]

Good thing you only wasted an hour. I'm waiting for over 6 hours for this particular transaction to confirm: http://btc.blockr.io/zerotx/info/844f88ef20fb5d2d2ecf897772d429d9bca1d3cab6314e5ed3017b48940f096a

This tx will not confirm.  It belongs to a tx chain that has already been invalidated by a malleated tx (original is here).

Bit-x signature payout gone wrong. This is exactly what you should not do currently, spend unconfirmed inputs.

[amaclin]

Bit-x signature payout gone wrong. This is exactly what you should not do currently, spend unconfirmed inputs.

LOL. They say on their ad that they are professionals in crypto.
But they are blockchain spammers. They even do not know how to combine several payouts to one transaction.

[Warren Buffet]

Bit-x signature payout gone wrong. This is exactly what you should not do currently, spend unconfirmed inputs.

LOL. They say on their ad that they are professionals in crypto.
But they are blockchain spammers. They even do not know how to combine several payouts to one transaction.

Bit-X is a cloud mining ponzi with an eyewash of legitimacy. They have 1 Phs vouch from BitFury and selling unmetered hash power. Reliable, professional etc. are all vague words flying in bitcoin industry.

[dothebeats]

Good thing you only wasted an hour. I'm waiting for over 6 hours for this particular transaction to confirm: http://btc.blockr.io/zerotx/info/844f88ef20fb5d2d2ecf897772d429d9bca1d3cab6314e5ed3017b48940f096a

This tx will not confirm.  It belongs to a tx chain that has already been invalidated by a malleated tx (original is here).

So does this necessarily mean that any outputs in that transaction won't be received by the address it was sent to? If so, the balance won't be affected if the transaction was invalidated, right?

[saddambitcoin]

I had to restore wallet from seed on another device then create new trezor wallet to send the funds there. Annoying...

Any suggestions?
[/quote]

Well, my only suggestion now is to use a different wallet because the trezor is not currently able to rescan its transaction and ignore the 0 confirmation duplicated tx.

Regarding your sentiment to "pay to third party banks and use your national currency", no thank you I will choose to be a victim!

[basil00]

So does this necessarily mean that any outputs in that transaction won't be received by the address it was sent to? If so, the balance won't be affected if the transaction was invalidated, right?

The entire tx chain (from the tx I linked to) has been invalidated.  This means that the sender needs to create new txs otherwise you'll never get paid.

[amaclin]

Regarding your sentiment to "pay to third party banks and use your national currency", no thank you I will choose to be a victim!

Quoted.  Let us talk about it later.

[dothebeats]

So does this necessarily mean that any outputs in that transaction won't be received by the address it was sent to? If so, the balance won't be affected if the transaction was invalidated, right?

The entire tx chain (from the tx I linked to) has been invalidated.  This means that the sender needs to create new txs otherwise you'll never get paid.

Thanks for the clarification. Already requested a separate payout with the reason you have just stated in here.

[unholycactus]

Regarding your sentiment to "pay to third party banks and use your national currency", no thank you I will choose to be a victim!

Quoted.  Let us talk about it later.

Is your argument that since you pay a bank to use their service, it's more secure?
How is putting your trust in a single entity more secure?

[RussianRaibow]

In which part of the world, it is Sunday now ?

It's a rather rainy Sunday in the UK right now.

Stop posting BS for signature payment only. Check my post date. I posted 2 days ago. That was not a Sunday.

[BitcoinNewsMagazine]

I had to restore wallet from seed on another device then create new trezor wallet to send the funds there. Annoying...

Any suggestions?

Well, my only suggestion now is to use a different wallet because the trezor is not currently able to rescan its transaction and ignore the 0 confirmation duplicated tx.

Regarding your sentiment to "pay to third party banks and use your national currency", no thank you I will choose to be a victim!

If myTrezor.com is currently not able to handle the duplicate transactions gracefully what wallet are you using with your Trezor and how well is it working?

[btcash]

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.

Apparently you used the low/high s attack (http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high).

How is it possible that so many transactions were affected if v2 transaction are protected against this kind of attack?

The advantage for programs using v2 transactions is that they can generally be constructed to be non-malleable by third parties, so v2 transactions can more safely be used for applications like the initial bond part of establishing a micropayment channel.

http://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implemented

https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki

NOTICE: This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment.

Why? Apparently rules 1-6 have been implemented, 7 only affects special outputs and 8,9 shouldn't be a problem (for third party malleability)
EDIT: Ok, all txs are version 1. Version 2 hasn't implemented yet.

[ElectricMucus]

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

Wrong. There are no "100%-safe" ways at all.
First way is "risky & cheap". Second way is "no-so-risky as first, but not-so-cheap"
Bitcoin itself is risky. If you do not want to be a victim - pay to third party banks and use your national currency.

You are my personal hero of the day.

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



Also, see my sig.

[Luke-Jr]

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.

Apparently you used the low/high s attack (http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high).

How is it possible that so many transactions were affected if v2 transaction are protected against this kind of attack?

The advantage for programs using v2 transactions is that they can generally be constructed to be non-malleable by third parties, so v2 transactions can more safely be used for applications like the initial bond part of establishing a micropayment channel.

http://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implemented

https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki

NOTICE: This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment.

Why? Apparently rules 1-6 have been implemented, 7 only affects special outputs and 8,9 shouldn't be a problem (for third party malleability)

Rules 2-6 are also not implemented, and BIP 66 extended rule 1 to all transactions, regardless of their version.

But the main reason it isn't suitable right now is the "Block validity" section, which uses block version >=3 to trigger it.
We already are on block version 3 for BIP 66, so this needs to be updated for another version.

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.

[dexX7]

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

[Luke-Jr]

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

You're conflating standards with the IsStandard filter.
The former is defined by common use, while the latter is miner/relay policy entirely up to the individual user to decide.
You can decide to filter with SCRIPT_VERFIY_LOW_S if you like, but maybe 5% of legit transactions will probably be filtered if you do so.
If everyone did, then those 5% would never confirm until someone malleated them.

[Zombier0]

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