enuma
Newbie
Offline
Activity: 34
Merit: 0
|
|
February 11, 2014, 04:23:57 PM |
|
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.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
February 11, 2014, 05:06:39 PM |
|
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.pdfMany 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 (OP)
|
|
February 11, 2014, 09:15:09 PM |
|
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
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
February 11, 2014, 09:34:59 PM Last edit: February 11, 2014, 10:55:10 PM by 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
|
|
February 11, 2014, 09:43:39 PM |
|
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
Legendary
Offline
Activity: 2044
Merit: 1005
|
|
February 11, 2014, 09:59:40 PM |
|
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
Legendary
Offline
Activity: 1148
Merit: 1018
|
|
February 11, 2014, 10:52:26 PM |
|
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
Legendary
Offline
Activity: 2128
Merit: 1005
ASIC Wannabe
|
|
February 11, 2014, 11:24:38 PM |
|
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
|
|
February 12, 2014, 01:20:15 AM |
|
Do alt-coins have this problem?
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
February 12, 2014, 01:26:54 AM Last edit: February 12, 2014, 01:40:27 AM by 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
Newbie
Offline
Activity: 51
Merit: 0
|
|
February 12, 2014, 01:32:32 AM |
|
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
Newbie
Offline
Activity: 47
Merit: 0
|
|
February 12, 2014, 01:37:16 AM |
|
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
Legendary
Offline
Activity: 1400
Merit: 1013
|
|
February 12, 2014, 02:23:47 AM |
|
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
|
|
February 12, 2014, 02:36:40 AM |
|
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
Legendary
Offline
Activity: 1484
Merit: 1005
|
|
February 12, 2014, 05:50:40 AM |
|
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.
|
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
|
|
|
DoomDumas
Legendary
Offline
Activity: 1002
Merit: 1000
Bitcoin
|
|
February 12, 2014, 06:09:44 AM |
|
+1 this is not a big issue, thanks for pointing that
|
|
|
|
nibyokwy
Newbie
Offline
Activity: 51
Merit: 0
|
|
February 12, 2014, 08:50:58 AM |
|
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
|
|
|
|
|