(Solved) Is there any delay when transfering bitcoins?

[g4qoj7]

I'm planning to buy some bitcoins at my campus and pay in cash.
However, I don't want to give the money until I'm sure the bitcoins have been transferred to my wallet.

Is it an instantaneous operation? I mean, Will I see the bitcoins in my running client some seconds after the seller send me them? How long does it take?


Gracias por adelantado.

[Scott J]

It is not instant.

https://en.bitcoin.it/wiki/FAQ#Why_do_I_have_to_wait_10_minutes_before_I_can_spend_money_I_received.3F

[Meni Rosenfeld]

For your purposes it is instant.

You will receive notification about the transfer within seconds. You will not be able to spend them right away, and if your counterparty is a criminal mastermind with custom software he has a tiny chance of reversing it if you don't wait for a block confirmation.

[MoonShadow]

I'm planning to buy some bitcoins at my campus and pay in cash.
However, I don't want to give the money until I'm sure the bitcoins have been transferred to my wallet.

Is it an instantaneous operation? I mean, Will I see the bitcoins in my running client some seconds after the seller send me them? How long does it take?


Gracias por adelantado.

Your client should be able to see the transaction within a few seconds, assuming that it is a valid transaction, but it won't let you spend it until it's been included into a block and 'confirmed' several times.  As the other responder said, he would have to be a master cracker to take it back before one confirmation and God after six confirmations.

[DeathAndTaxes]

It depends on how much you trust him.  Transfers are nearly instantaneous.  The only way you won't see it in a few seconds is if your wallet isn't up to date.  If you wallet currently has a 0 BTC balance use the faucet and get a tiny amount of coins for free to verify your wallet is working and is up to date. 

Although Bitcoin is nearly instantaneous the level of security depends on the # of confirmations.

0-confirms:
It "could" be double spent (reversed) but honestly it is very very very very unlikely.  It is slightly more likely that afterwards a bear will jump out from behind a tree and beat you with a wrench until you give him access to your private key.  Bears eat bitcoins and they understand cryptography.  Always watch for bears.

1-confirm:
If you wait ~10 minutes (although it can vary) the tx will be hashed into the next block and your wallet (technically client) will show 1-confirm.   A double spend here would be even more difficult as your friend would need a massive amount of hashing power to create an alternate chain and extend it past the legit chain.  Even with 10% of the network his chances are very remote.

6-confirms:
It takes ~60 minutes and at this point the only realistic way you could be defrauded is if your friend can 51% attack the network.  If your friend can do that well we all have problems but I doubt someone with a ~$20M hashing farm is going to try and scam you out of a couple dollars.

TL/DR version:
For casual small face to face purchases with someone you know (or can beat up) 0-confirms should be nearly instantaneous and is "good enough" security.  One thing you should never do is trust someone else client, browser, etc.  Very easy to fake a transaction that way.  Only trust your hardware, internet, client.

[John (John K.)]

It depends on how much you trust him.

Transfers are nearly instantaneous.  To see it in your wallet it should be up to date but you can see it on 3rd party sites like blockchain.info even if your wallet is behind.

0-confirms could be double spent (reversed) but honestly it is very very very very unlikely.  More likely that afterwards a bear will jump out from behind a tree and beat you with a wrench until you give him access to your private key.  Always watch for bears.

If you wait ~10 minutes (although it can vary) it will be 1-confirm.  A double spend here would be even less likely as your friend would need a massive amount of hashing power.

6-confirms takes ~60 minutes and at this point the only way you could be defrauded is if your friend can 51% attack the network.

TL/DR version:
for casual small face to face purchases with someone you know (and can beat up) 0-confirms should be nearly instantaneous and is "good enough" security.

+1.
0-confirm will do unless you're dealing with tons of coins and a mastermind.

[g4qoj7]

Scott, Meni, Moonshadow, Death&taxes and Johnthedong THANK YOU!

[Stephen Gornick]

0-confirms:
It "could" be double spent (reversed) but honestly it is very very very very unlikely.

That is not an accurate statement.  Unless proper precautions are taken, a 0/unconfirmed race attack can be successful -- maybe 50% of the time even.
The precautions include configuring the client so that there are no incoming connections allowed and to explicitly have outgoing connections to the top miners.

I've actually been surprised that there haven't yet been reports of anyone in the marketplace forum or on the #bitcoin-otc marketplace losing their bitcoins received to a double spend race attack yet.  It takes really no technical skill -- just use the same wallet in two places and try to spend from the same coin to two different addresses.   Eventually one of those times the one seen by the recipient will differ from the one seen by the miner who eventually gets that block.

1-confirm:
If you wait ~10 minutes (although it can vary) the tx will be hashed into the next block and your wallet (technically client) will show 1-confirm.   A double spend here would be even more difficult as your friend would need a massive amount of hashing power to create an alternate chain and extend it past the legit chain.  Even with 10% of the network his chances are very remote.

There is a variation of the Finney Attack that could defraud just as easily with a 1-confirmation as with a 0/unconfirmed though the same recommendation above (to allow no incoming) prevents that variation from becoming successful as well.
 - http://bitcointalk.org/index.php?topic=36788.msg463391#msg463391

[DeathAndTaxes]

That is not an accurate statement.  Unless proper precautions are taken, a 0/unconfirmed race attack can be successful -- maybe 50% of the time even.
The precautions include configuring the client so that there are no incoming connections allowed and to explicitly have outgoing connections to the top miners.

How about we try it as a bet.  You say it is 50% successful?  Tell you what I will give you 10:1 odds.  You should be 500% profitable then right?  To break even you only need to be successful 10% of the time.  How it works is you try to double spend me.  If successful you keep the double spend and I pay you 10:1.  If you fail i just keep the funds you failed trying with.  You can name the stakes and time.  You can keep sending me money until you want to quit or I lose 100 BTC.  Let me know when you want to play.

I've actually been surprised that there haven't yet been reports of anyone in the marketplace forum or on the #bitcoin-otc marketplace losing their bitcoins received to a double spend race attack yet.  It takes really no technical skill -- just use the same wallet in two places and try to spend from the same coin to two different addresses.   Eventually one of those times the one seen by the recipient will differ from the one seen by the miner who eventually gets that block.

Um you don't think the buyer won't happen to notice the tx go INVALID as soon as his client sees both versions of the double spend?

To accomplish a double spend you can't just double spend you must
a) send tx A to victim (A)
b) send tx B to the the attacker (B).
c) complete the actual transaction (in person is going to take at least a minute or two)
   c1) ensure that tx B is propogated to majority of pools.
   c2) ensure that tx A isn't propogated to majority of pools.  
   c3) ensures that victim (A) doesn't see double spend B
e) get away with item of value before victim detects deception and stops tx.

It is possible and yes if you are moving 28 million dollars in bearer bonds you should wait for 6+ confirmations (maybe 144 confirmations) but there is a significant challenge to even a 0-confirm double spend and a face to face tx of low value is low risk from such a complex attack which requires nearly perfect timing.

There is a variation of the Finney Attack that could defraud just as easily with a 1-confirmation as with a 0/unconfirmed though the same recommendation above (to allow no incoming) prevents that variation from becoming successful as well.
 - http://bitcointalk.org/index.php?topic=36788.msg463391#msg463391

A finney attack in person would require the attacker to
a) be able to generate blocks in very short time span "on demand" (i.e. like I said "massive amount of hashing power")
b) generate a block and hold it before the tx.
c) complete the tx (likely minutes)
d) broadcast the held block before the network finds another block.

Every 12 seconds the block is held the attacker loses 1 BTC in expected value (due to the chance of another block being found and broadcasted).  Finney attack is useful against instant delivery high value irreversable online tx because the attack has a cost to the attacker which is directly related to length of time and value of the tx.  

Even online one can greatly reduce the effectiveness by simply waiting.  The attack has a cost to the attacker of roughly 1 BTC per 12 seconds.  Finney attack is hardly applicable for a face to face meeting which may take minutes involving a small sum of money.  Attacker's break even point is 5 BTC in value per minute elapsed between time block is created and held and time tx is completed.  

Trying a Finney attack here means the most likely outcome is the attacker simply loses a block (and 50 BTC).

[MoonShadow]

0-confirms:
It "could" be double spent (reversed) but honestly it is very very very very unlikely.

That is not an accurate statement.  Unless proper precautions are taken, a 0/unconfirmed race attack can be successful -- maybe 50% of the time even.
The precautions include configuring the client so that there are no incoming connections allowed and to explicitly have outgoing connections to the top miners.

I've actually been surprised that there haven't yet been reports of anyone in the marketplace forum or on the #bitcoin-otc marketplace losing their bitcoins received to a double spend race attack yet.  It takes really no technical skill -- just use the same wallet in two places and try to spend from the same coin to two different addresses.   Eventually one of those times the one seen by the recipient will differ from the one seen by the miner who eventually gets that block.

1-confirm:
If you wait ~10 minutes (although it can vary) the tx will be hashed into the next block and your wallet (technically client) will show 1-confirm.   A double spend here would be even more difficult as your friend would need a massive amount of hashing power to create an alternate chain and extend it past the legit chain.  Even with 10% of the network his chances are very remote.

There is a variation of the Finney Attack that could defraud just as easily with a 1-confirmation as with a 0/unconfirmed though the same recommendation above (to allow no incoming) prevents that variation from becoming successful as well.
 - http://bitcointalk.org/index.php?topic=36788.msg463391#msg463391

We're not talking about someone buying a car with bitcoins.  Do you really have any idea of the technical difficulty in doing something like this?  Imagine the cost to the scammer to just set this up once.  No one would do this to take a person who knows his name for a couple hundred dollars.

[Stephen Gornick]

How it works is you try to double spend me.  If successful you keep the double spend and I pay you 10:1.

I like those odds!

I did specify that following proper precautions (i.e., no incoming transactions being one of them) will protect the recipient.  Using the bitcoin.org client following the default mode is not a proper protection against someone trying to perform a race attack.

I'ld consider taking you up on your bet if you are using default configuration -- i.e., the client determines which 8 nodes you get connected to.  That will likely mean you are not directly connected to any pool (and are at least one hop from a pool).

Then I will make a transaction with a spend to myself and only broadcast that to the top four pools.  A few milliseconds later I will, from another node with a copy of the same wallet, announce the double spend to a well connected node that is not one of those four with the hope that the transaction will get relayed to a node you happen to be connected to.  It will then be a race -- will the original transaction from one of the four pools reach you first, or will your client see the double-spend transaction first?  I wouldn't be surprised if following these steps that your client will show the double spend and the original transaction is what gets mined at least 33% of the time. [Update: Since those four pools only account for about 66% of hashing strength, I dropped the number for the double-spend success percentage guess to 33%.]

Um you don't think the buyer won't happen to notice the tx go INVALID as soon as his client sees both versions of the double spend?

Does the client do anything different now?  I thought the client, having a double-spend transaction, just stays at 0/unconfirmed forever.  Yes, you'll probably notice that the transaction isn't confirming tens of minutes later but it isn't like seconds after receiving the transaction you get a red popup with a warning.

Trying a Finney attack here means the most likely outcome is the attacker simply loses a block (and 50 BTC).

What I was trying to point out is that a merchant accepting on 1-confirmation can be just as vulnerable to the finney attack as the 0-confirmation should proper precautions (i.e., not allow incoming transactions, be well connected) not be implemented.

So, maybe we can learn something here.  I'ld like to see the results of an experiment that determines, using the default configuration for the client on a typical consumer network connection (w/UPnP), how successful the race attack actually is.

For the attacker this can be done using just two node instances each with a copy of the same wallet.  (i.e., probably don't even need to go the extra step of having a script running on each of four nodes, to ensure the transaction gets announced simultaneously to the four large pools.)  

[realnowhereman]

I may be wrong; but I don't believe a double spend results in neither spend attempt going through -- it results in one only of the spend attempts going through. So a double spend attempt fails 50% of the time.

The other 50% of the time the successful second spend means that the TX listed as 0/unconfirmed never makes it into a block, and so stays at 0/unconfirmed -- which is exactly what it is.

A nice feature for the client would be a 0/DOUBLESPEND if a second conflicting TX is detected.

Personally I don't think it would be unreasonable for miners to reject both transactions.  There is no risk of DOS on genuine transactions as both transactions are verifiably from the same person (their signature proves it); and they are also demonstrably a scammer.

[Meni Rosenfeld]

I may be wrong; but I don't believe a double spend results in neither spend attempt going through -- it results in one only of the spend attempts going through. So a double spend attempt fails 50% of the time.

The other 50% of the time the successful second spend means that the TX listed as 0/unconfirmed never makes it into a block, and so stays at 0/unconfirmed -- which is exactly what it is.

A successful double spends means that the double spender got the goods he supposedly paid for, and kept his bitcoins. If the receiver waits a few seconds to see if any of his peers knows of a conflicting transaction, there's about 99% chance of discovering a double-spend attempt and refusing to deliver the goods. Thus, double-spend attempts would fail 99% of the time.

The double-spender may or may not receive his coins back, but as he got no good, it was not a successful attempt.

A nice feature for the client would be a 0/DOUBLESPEND if a second conflicting TX is detected.

Yes.

Personally I don't think it would be unreasonable for miners to reject both transactions.  There is no risk of DOS on genuine transactions as both transactions are verifiably from the same person (their signature proves it); and they are also demonstrably a scammer.

This is a fundamental protocol change which is not needed and may have unintended consequences.

[realnowhereman]

I may be wrong; but I don't believe a double spend results in neither spend attempt going through -- it results in one only of the spend attempts going through. So a double spend attempt fails 50% of the time.

The other 50% of the time the successful second spend means that the TX listed as 0/unconfirmed never makes it into a block, and so stays at 0/unconfirmed -- which is exactly what it is.

A successful double spends means that the double spender got the goods he supposedly paid for, and kept his bitcoins. If the receiver waits a few seconds to see if any of his peers knows of a conflicting transaction, there's about 99% chance of discovering a double-spend attempt and refusing to deliver the goods. Thus, double-spend attempts would fail 99% of the time.

Sorry; quite right.  I didn't complete the thought.  What I meant was to say "even a successful double spend attempt fails 50% of the time".  By that I mean that that successfully getting the right target node to receive the two spend attempts will result in it receiving them in the wrong order sometimes; with no way for the attacker to know.

Personally I don't think it would be unreasonable for miners to reject both transactions.  There is no risk of DOS on genuine transactions as both transactions are verifiably from the same person (their signature proves it); and they are also demonstrably a scammer.

This is a fundamental protocol change which is not needed and may have unintended consequences.

It's not a protocol change at all.  Miners can already pick what transactions they include on whatever basis they wish.  "Because you're a scammer" doesn't seem like an bad reason to me.

[Kush]

its not instant in most cases.

[Stephen Gornick]

A nice feature for the client would be a 0/DOUBLESPEND if a second conflicting TX is detected.

Yes.

But the client probably won't know about both transactions until there is a conflict where a block comes in with the conflicting information.  This is because invalid transactions don't get relayed and for any node, one of those two will be considered invalid.

The client would need to connect to an external listening service to know that a double spend attempt had occurred.  No such service exists.   Though TransactionRadar.com, http://blockchain.info/double-spends, and elsewhere are tools in the same space.

[DeathAndTaxes]

Then I will make a transaction with a spend to myself and only broadcast that to the top four pools.

Who will then relay it to a 1,000 or so nodes.  It is in a pools best interest to maintain a large # of connections to other nodes and pools to ensure a found block is propagated to a large portion of the network in one hop to win any block race.

A few milliseconds later I will, from another node with a copy of the same wallet, announce the double spend to a well connected node that is not one of those four with the hope that the transaction will get relayed to a node you happen to be connected to. It will then be a race -- will the original transaction from one of the four pools reach you first, or will your client see the double-spend transaction first?

Yes I understand the concept however your assumption is that the second well connected node will win a race against all the connections from 4 major pools despite 4 major pools having a headstart and win that race at a high enough frequency to offset the losses when a minor pool mines "my" tx anyways.

There are two competing tx
TX A = payment to your self
TX B = payment to me (which you intend to have reversed by A)

For the double spend to work you need:
1) TX A seen first by majority of hashing power/pools
2) TX B seen by enough nodes to propogate to me before the "path" gets blocked.

If #1 happens but not #2 then I never see a 0-confirm tx
If #2 happens but not #1 then I get "paid" (confirmed).

In an isolation attack you have a good chance of accomplishing both #1 & #2 but that wasn't discussed.

I wouldn't be surprised if following these steps that your client will show the double spend and the original transaction is what gets mined at least 33% of the time.

I am willing to try it out.
The key point being that #1 & #2 both happen for you to "win".  Getting your tx into a block is easy but getting it into a block and me still seeing a 0-confirm is difficult.

I willl pay you 10:1 for anything you send to 17KBkkH3rfqTRUqV4mYD4XMFzy7GZ8y2Ai (newly generated address from my wallet) which shows 0-confirm but later is orphaned.  Obviously anything you send here that isn't orphaned I keep.

[Meni Rosenfeld]

"even a successful double spend attempt fails 50% of the time"

Divergent series can converge much faster than convergent series, because they don't have to converge.

[Stephen Gornick]

I willl pay you 10:1 for anything you send to 17KBkkH3rfqTRUqV4mYD4XMFzy7GZ8y2Ai (newly generated address from my wallet) which shows 0-confirm but later is orphaned.  Obviously anything you send here that isn't orphaned I keep.

I've only expressed interest when the condition is that the target is using the default configuration (accepts incoming) and is on a typical consumer network (e.g., w/ UPnP).   You've not stated that you'ld follow this configuration.

This experiment isn't too hard to perform, yet I've not seen anyone report attempting it and reporting either success or failure at double spending.  It probably should be performed where the target is on a separate network from the attacker, so I couldn't do both sides of the experiment myself.

For the purpose of having at least attempted the experiment, will anyone serve as the target?   The target would be a clean install of the client using the defaults, on a consumer network (w/  UPnP).    In each trial, I make double spend attempts of 1 BTC.  For any trial where the target shows at least two confirmations with my 1 BTC payment then that trial has failed and the target returns that 1 BTC to me.

If a double spend is successful, this will mess up the target's wallet (e.g., leave a 0-unconfirmed transaction) so use a clean install.  (wipe the wallet.dat and the addr.dat before the client is launched.  Keep the blockchain files though.).

Looking for someone with a trust rating in the -otc as I'ld like assurance that I'll get my 1 BTC back.  

[realnowhereman]

"even a successful double spend attempt fails 50% of the time"

Divergent series can converge much faster than convergent series, because they don't have to converge.

Yeah; I did anticipate it could be read like that which is why I explained it in the next sentence, which you didn't quote...