I could not answer this BTC security question

[mishrahsigni]

my friend asked me "so, I send you a coin from my BTC account, and you get it and it is verified... but between the time I send it, and you verify it, what is stopping me from sending a copy of that coin elsewhere?".  This assumes a user could hack the wallet and make a duplicate coin, which I have no idea how possible that would be (what DOES prevent me from hacking my wallet?)

Can someone share with me what the correct answer to that question  is?


Thanks

[1715134384]

1715134384

[1715134384]

1715134384

[1715134384]

1715134384

[1715134384]

1715134384

[Gabi]

To start there is no "BTC account". So "hacking" the wallet is meaningless, there are just private keys, you already know them, since they are your keys.

What stop him to send more transactions with this coin? Oh, nothing. He can send that coin to other addresses. But if you wait for at least 1 confirmation, then ONLY ONE of these transactions will be confirmed. The others will be happily rejected.
So, he send you a coin and instantly make another transaction to send that coin to another address. The net receive the transactions and accept only the first one. A miner will find a block and confirm the transactions by putting them in the block, he will of course put only 1 transaction in the block. So, the instant 1 confirmation happen, you can be sure if you received the coin (and then it is your forever) or not.

[DeathAndTaxes]

Simple version ...  That is why we wait for confirmations.  

Unconfirmed transaction should only be trusted as much as you trust the sender.  If I send you a check, how do you know it won't bounce. If you trust me you can trust my check, if you don't then you can't and shouldn't.  Also you need to put the amount and thus the risk in context.  Selling a $5 steam game to someone on the forum?  0-confirm might be fine.  Launching a network of Bitcoin ATMs which instantly dispense up to $1,000 cash upon a 0-confirm transaction? Well that is a good way to go bankrupt.


As Gabi pointed out there is nothing that prevents you from "hacking" your client (wallet).  It is open source software. Trying to make it hackproof would just be "feel good security" and not prevent double spends as the protocol is open and anyone can make an alternative client even one designed solely for double spend attacks.  Now in reality there are some technical challenges to successfully performing a double spend but they have nothing to do with your client.  They have to do with how other nodes and miners handle unconfirmed transactions with the same input (double spend).  To avoid a potentially false sense of security unless you have very detailed knowledge of how the network works and have a specific need to make delivery upon 0-confirm notification, you should treat unconfirmed transactions as untrusted.

[blockgenesis]

The average time needed to validate a transaction (and cancel all double-spend attempts) is only 10 minutes. So, it is not a problem for most use cases.

And for the business that really needs instant transactions, it is possible (but yet not really developed) to detect double-spend attempts. Because during a instant transaction fraud attack, there is two public waiting transactions from the same Bitcoin address.

Here is a more detailed article on that subject :
http://bitcoinmagazine.com/instant-transaction-fraud-an-explanation/

[Walter Rothbard]

my friend asked me "so, I send you a coin from my BTC account, and you get it and it is verified... but between the time I send it, and you verify it, what is stopping me from sending a copy of that coin elsewhere?".  This assumes a user could hack the wallet and make a duplicate coin, which I have no idea how possible that would be (what DOES prevent me from hacking my wallet?)

Can someone share with me what the correct answer to that question  is?


Thanks

What stops him is that the network is constantly communicating and minting new blocks to record transactions.  One transaction will make it into a block, the other will be rejected as an invalid double spend by any node that possesses that block.

[DannyHamilton]

The average time needed to confirm a transaction (and significantly limit all double-spend attempts) is only 10 minutes. So, it is not a problem for many use cases.

FTFY