QT strange DOUBLE SPEND (malleable)

[enuma]

Well newbies thats why bitcoin consider a near 100% transaction confirmed only once it hits the god damm 6 confirmations @ minimum. Exchanges and other services rely on txid to simply cut the long time you have to wait for the 6 confirmations.

[1714186768]

1714186768

[1714186768]

1714186768

[1714186768]

1714186768

[1714186768]

1714186768

[1714186768]

1714186768

[DeathAndTaxes]

Well newbies thats why bitcoin consider a near 100% transaction confirmed only once it hits the god damm 6 confirmations @ minimum. Exchanges and other services rely on txid to simply cut the long time you have to wait for the 6 confirmations.

Yes but there isn't anything magical about 6 confirmations.  I would say the network considers a transaction confirmed once it is confirmed.  How many confirmations you should wait depends on your risk threshold.  For most tx 2 confirmations provides a high level of security.  For some transactions you probably want to wait more than 6.

Satoshi never indicated 6 was some magical barrier it simply was the output of his example on the risk of reversal.  If an attacker has 10% of the network, and you want a less than 0.1% chance of the attacker being able to reverse your transaction you need to wait for 6 confirmations.   However if the attacker has say 20% of the network you would need to wait for 10 confirmations to reduce the attackers chances to 0.3%.

Meni wrote a good paper on the economics of transaction reversing because the attacker has a cost (in terms of potentially lost block rewards) trying to re-org the blockchain.  So the more important factor is what is the VALUE of your transaction.

For example if you assume the attacker has 48% of the network (if they have 51% no amount of confirmations will keep you safe) then you need at least this many confirmations to make the attack non-economical

48%
<= 4 BTC = 1 confirmation
6 BTC = 2 confirmations
8 BTC = 3 confirmation
9 BTC = 4 confirmation
10 BTC = 5 confirmations
12 BTC = 6 confirmations
13 BTC = 7 confirmations
14 BTC = 8 confirmations
15 BTC = 9 confirmations
16 BTC = 10 confirmations

Hopefully we can eventually kill the "6 is good for everyone" way of thinking.
https://bitcoil.co.il/Doublespend.pdf

Many merchants hinder the user experience by demanding an excessive amount of confirmations relative to the transaction risk.  For example someone accepting 0.01 BTC for some game credits shouldn't be demanding 6 confirmations.  The user wants to play right away and making them wait 30-120 minutes just creates the (false) perception that Bitcoin is slow.  Even 1 confirmation provides a higher level of security than other payment methods.

[2GOOD]

All this is true.. confirmed tx is what matters, but this attack is very annoying. It happened to me again today, but this time the clone tx confirmed first and I had to delete mine with pywallet. I have no problem with that but the regular user probably would.

[DeathAndTaxes]

All this is true.. confirmed tx is what matters, but this attack is very annoying. It happened to me again today, but this time the clone tx confirmed first and I had to delete mine with pywallet. I have no problem with that but the regular user probably would.

The QT client (and all clients) should be patched to delete or "hide" duplicates, and give user the option to no spend unconfirmed change.  

That would make the "mutate tx attacks" a non-issue (other than you can't assume tx id won't change which is more of an issue for service providers than end users).

[hostmaster]

All this is true.. confirmed tx is what matters, but this attack is very annoying. It happened to me again today, but this time the clone tx confirmed first and I had to delete mine with pywallet. I have no problem with that but the regular user probably would.

The QT client (and all clients) should be patched to delete or "hide" duplicates.  That would make the "spam attacks" a non-issue (other than you can't assume tx id won't change).

Agreed. I have similar issues poping up with my QT

[sidhujag]

All this is true.. confirmed tx is what matters, but this attack is very annoying. It happened to me again today, but this time the clone tx confirmed first and I had to delete mine with pywallet. I have no problem with that but the regular user probably would.

The QT client (and all clients) should be patched to delete or "hide" duplicates.  That would make the "spam attacks" a non-issue (other than you can't assume tx id won't change).

I thinkt he quick fix would be to do a rescan scheduled as maintenance once a night or whatever, if people still have issues they would need to manually dump their priv key and import it into a fresh install (renew their blockchain).

[Rampion]

All this is true.. confirmed tx is what matters, but this attack is very annoying. It happened to me again today, but this time the clone tx confirmed first and I had to delete mine with pywallet. I have no problem with that but the regular user probably would.

The QT client (and all clients) should be patched to delete or "hide" duplicates.  That would make the "spam attacks" a non-issue (other than you can't assume tx id won't change).

Agreed. I have similar issues poping up with my QT

Everybody is. Not only a visual annoyance but also a potencial pain in the ass if you do a lot of transactions per day, some of your transactions might break because of unconfirmed change.

[klondike_bar]

All this is true.. confirmed tx is what matters, but this attack is very annoying. It happened to me again today, but this time the clone tx confirmed first and I had to delete mine with pywallet. I have no problem with that but the regular user probably would.

The QT client (and all clients) should be patched to delete or "hide" duplicates.  That would make the "spam attacks" a non-issue (other than you can't assume tx id won't change).

Agreed. I have similar issues poping up with my QT

Everybody is. Not only a visual annoyance but also a potencial pain in the ass if you do a lot of transactions per day, some of your transactions might break because of unconfirmed change.

My bitcoin-QT just forced me to reindex the block chain - its about halfway after 12 minutes and hogging my ram. hopefully this will clear my issue where the wallet balance is different from the transaction-log-based balance.

I 100% agree that a simple 'hide duplicates' patch would solve the issue

[leannemckim46]

Do alt-coins have this problem?

[DeathAndTaxes]

Do alt-coins have this problem?

alt-coins are essentially carbon copies of bitcoin with hashing algorithm and names changed.  Any coin forked off the bitcoin or litecoin source would be equally affected.  A truly "custom" altcoin "may" have txid which are immutable but if you don't know for sure I would assume they are also affected.

[nibyokwy]

alt-coins are essentially carbon copies of bitcoin with hashing algorithm and names changed.  Any coin built of the bitcoin or litecoin source would be equally affected.  A truly "custom" altcoin "may" have txid which are immutable but if you don't know for sure I would assume they are affected as well.

yes. expect alt-coin havoc when griefers turn their attention to them. it would be wise for alt-coin maintainers to start applying the "don't spend unconfirmed change" patches.

[il--ya]

I know very well how it is resolved, the question is why the double spend appear in first place.

To start with, stop calling it a double-spend. It's not double spend until it's in the blockchain, it's double-spend attempts. And double spend is not possible.

[justusranvier]

The QT client (and all clients) should be patched to delete or "hide" duplicates, and give user the option to no spend unconfirmed change.  

That would make the "mutate tx attacks" a non-issue (other than you can't assume tx id won't change which is more of an issue for service providers than end users).

More fundamentally, all wallets need to assume a one-to-many relationship between txids and transactions and update their UIs accordingly.

[phzi]

This is why pro's use coin control variant clients like omg.

And yes, please... these are not double spends. Stop calling it that.

[tacotime]

Someone is running malicious code that receives tx and then retransmits them mutated.  Only one gets incorporated into the block chain eventually. Kind of a nuisance, i guess they're trying to mess up every exchange right now that operates on txids. Bitpay, coinbase, coinvoice all use custom daemons anyway so not a huge issue.

[DoomDumas]

This is currently happening to Bitcoin Wallet users as well:

https://plus.google.com/101256420499771441772/posts/bURxFhrKfcq

+1

this is not a big issue, thanks for pointing that

[nibyokwy]

this is not a big issue, thanks for pointing that

it's a big issue for casual users who wonder why their balance is wrong and transactions are unconfirmed: https://bitcointalk.org/index.php?topic=460944.0