Bitcoin Forum
November 17, 2017, 05:23:05 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: I could not answer this BTC security question  (Read 773 times)
mishrahsigni
Jr. Member
*
Offline Offline

Activity: 44


View Profile
February 08, 2013, 03:16:11 PM
 #1

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
1510939385
Hero Member
*
Offline Offline

Posts: 1510939385

View Profile Personal Message (Offline)

Ignore
1510939385
Reply with quote  #2

1510939385
Report to moderator
1510939385
Hero Member
*
Offline Offline

Posts: 1510939385

View Profile Personal Message (Offline)

Ignore
1510939385
Reply with quote  #2

1510939385
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1510939385
Hero Member
*
Offline Offline

Posts: 1510939385

View Profile Personal Message (Offline)

Ignore
1510939385
Reply with quote  #2

1510939385
Report to moderator
1510939385
Hero Member
*
Offline Offline

Posts: 1510939385

View Profile Personal Message (Offline)

Ignore
1510939385
Reply with quote  #2

1510939385
Report to moderator
Gabi
Legendary
*
Offline Offline

Activity: 1078


If you want to walk on water, get out of the boat


View Profile
February 08, 2013, 03:22:18 PM
 #2

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
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 08, 2013, 04:12:14 PM
 #3

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
Sr. Member
****
Offline Offline

Activity: 285

Bitcoin.org maintainer


View Profile
February 08, 2013, 08:35:01 PM
 #4

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/

Donation: 18XXXQs1vAQGBAZbXKA322r9Zy1nZac2H4
Walter Rothbard
Sr. Member
****
Offline Offline

Activity: 476


Bytecoin: 8VofSsbQvTd8YwAcxiCcxrqZ9MnGPjaAQm


View Profile WWW
February 08, 2013, 08:44:23 PM
 #5

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
Legendary
*
Offline Offline

Activity: 1974



View Profile
February 08, 2013, 08:45:09 PM
 #6

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

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!