Topic: (Solved) Is there any delay when transfering bitcoins? (Read 1596 times)

Fair enough.  Apologies.  I'm too used to the humourless to realise.

Come on, I was trying to make a joke... I know exactly what you meant, but it was funny and reminded me of Carrier's rule.

For the original poster, why not wait 10 to 20 minutes? (for about 1 to 2 confirms.) That should be enough. I don't think you're buying more than $10,000 worth of bitcoins with cash at your campus.

Personally, when I buy bitcoins, I tell the person I'm dealing with that I will deposit the money to their bank account. That's usually at least 1 hour later, or often times the next day. I have more than 6 confirms up to 100+ confirms by then that the bitcoins are in my address.

Sure we can do it as an experiment instead and any funds I receive will be returned.

So doing this between two people makes this more exciting, but why not just run 3 clients and try to double spend to yourself?

Heh, I guess should have asked -otc trust or someone with 5,997 forum posts. 

So that configuration is fine, but I want to make sure that the terms are, this is an experiment and is not the wager / challenge as was described above.  i.e., If you do get any BTC payments from me that you'll return them?  If so, then I'll go ahead and make an attempt on trial #1.

I use manual portforwarding instead of UPnp but the end result should be the same.  I just checked bitcoind and I have 21 connections.  13 outgoing, 8 incoming.  The bitcoind is unmodified except for api calls which allow excluding tx w/ low/no fee from work generation.


I don't use -otc so I guess you will need to find another endpoint.

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...

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.  

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

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.


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 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.

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.

its not instant in most cases.

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.


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.

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.

Yes.

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

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.

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%.]


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.


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.)  

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.

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.


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.


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).

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.


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.
 - https://bitcointalksearch.org/topic/m.463391