Bitcoin instant transactions are less secure

[Alikhaki123]

As you know, each Bitcoin transaction usually takes a few seconds, and confirmation of the same transaction starts ten minutes after that. During this time, interaction is permitted and may also be reversible. Deceptive users try to cheat. If you can't wait for approval, request a small transaction fee or use the Unsafe Interactions Detection System, which can enhance security. For higher amounts, e.g. US$1,000, it makes sense to wait for 6 confirmations or more. Any confirmation can reduce the risk of reverse transactions exponentially.

[1713581944]

1713581944

[1713581944]

1713581944

[1713581944]

1713581944

[ranochigo]

Fees only serves to help with the speed at which you're going to get a confirmation, ie. the number of blocks before you get a confirmation. It doesn't help with the security, in any way if you include a large fee but you accept it before it gets a confirmation. If the transaction is small enough, includes sufficient fees and has no opt-in RBF, then you could possibly accept it without any confirmations.

Anything above a single confirmation should be sufficient, unless you're talking about a million dollars. It is extremely unlikely for anyone to execute a 51% attack against a $1000 transaction. There is no reason to extend the wait and would just cause unnecessary hassle.

[Poker Player]

I think the OP is speaking more from hearsay than from his own experiences doing Bitcoin transactions:

As you know, each Bitcoin transaction usually takes a few seconds, and confirmation of the same transaction starts ten minutes after that.

If you pay the highest fee, it might start 10 minutes on average but it is not strange to have to wait for more than an hour for the next block confirmation. To talk about instant transactions, however much they are immediately transmitted to the blockchain, I would say is inaccurate. If we were talking about LN, like Jack Maller's Strike, as you can see in the following 1-minute video, I think we could talk about instant transactions, but not about normal transactions on the blockchain, even if you pay a high fee to make them go fast.

[franky1]

a 51% attack is about undoing a block(and transaction within) after its confirmed
and this costs $250k per block. and depending on that hashpower it could cost many blocks(time=$) to go back and then redo the block and then try to catch up with the network
 
so a pool trying to do this must want to undo a transaction of that value+ for him to even bother trying.
meaning why waste $250k trying to under a transaction worth only $10k
so most are safe with value upto $250k with 1 confirm


as for zero confirm scenarios. well they can be ignored and never get put into a block if the sender then passes a different preferred spend destination of his same funds with a higher fee.

the approach is to
a. not allow instant release of service or goods without confirm
or
b. if goods or services provide good margin/profit(little cost) where the genuine customers outweigh the 1% theft concern. meaning on balance you still make a profit even with acceptable loss.. then take the risk of instant payment

back in the good old days of cheques. this is what they did. they knew/assumed 1% of customers will write a duff cheque. and so they weight the risk vs cost.. and the convenience vs inconvenience

[pooya87]

There is no such thing as "instant transactions" in bitcoin. You are talking about "unconfirmed transactions".

In bitcoin when you send a transaction, almost always it propagates to all nodes within seconds. These transactions reside in nodes memory pool (assuming they remain valid). During this time they are called "unconfirmed" and they can be double spent which is why it has never been safe to accept an unconfirmed transaction.
When the next new block is mined (which could take from a second to a couple of hours) it could contain that unconfirmed transaction if it was paying a high enough fee compared to others or if the mempool didn't contain enough higher paying transactions to fill the block. This is referred to as being "confirmed" and as you said it becomes increasingly harder to reverse these transactions.

For higher amounts, e.g. US$1,000, it makes sense to wait for 6 confirmations or more. Any confirmation can reduce the risk of reverse transactions exponentially.

There are a couple of things that are usually ignored by people when talking about number of confirmations.
1. The network state.
Under normal circumstances (eg. right now) there is nothing going on so the chances of a chain split and a reorg is minimal but during a fork or a network disruption like 2017 or anything that could increase this risk the number of confirmation one demands has to increase. In some cases you may even wait for more than 200.

2. The client type.
A full node will be aware of any chain split or generally speaking any form of disruption in the network. An SPV client on the other hand may not even figure it out for a long time and remain on the wrong chain.
There is also more "centralized" non-custodial wallets where they only rely on a single server (most of phone wallets) that have a much higher risk.
In cases like this the number of confirmation required for security is much higher.

3. The amount and the payer.
Finally the only factor people are aware of. For higher amounts you want more confirmation and vice versa. Also if you know who is paying you (eg. a friend sending you money he owed) you may require a different number of confirmation. For example a food truck doesn't care about confirmation because the risk of someone double spending a bitcoin payment for a hotdog is the same as the risk of someone giving them fake cash bills, it's the acceptable risk of running a business.
Speaking of amount, it is not arbitrary. It also relates to the cost of the attack as @ranochigo pointed out. Since in order to reverse a confirmed transaction you'll have to perform a 51% attack and the cost of that is extremely high, $1000 can not be considered a high amount.

[tranthidung]

each Bitcoin transaction usually takes a few seconds, and confirmation of the same transaction starts ten minutes after that.

Bitcoin transactions are not instant. Sometimes, you feel that your transactions are instantly confirmed but it does not mean Bitcoin transactions are instant.

Block time on average is 10 minutes, per protocol. Depend on the interaction between network hashpower and difficulty, blocks can be solved slower or faster than the average rate of 10 minutes, for each 14 days. 14 days are for 2016 blocks, that is a period between two difficulty retargets (adjustments).

Some times, in a same 14D period, two blocks can be found within seconds or a few minutes shorter than 10 mins. However, it does not happen too often.

For higher amounts, e.g. US$1,000, it makes sense to wait for 6 confirmations or more. Any confirmation can reduce the risk of reverse transactions exponentially.

Usually, exchanges credit your deposit to your balance after 2 confirmations.

For your personal deal, 3 to 6 confirmations are the best for your safety. Bitcoin transactions are far secured than altcoin transactions.

That's my point though - you don't need 51% of the hashrate to still have a chance to reverse a transaction. If you have 51% of the hashrate, and can sustain that indefinitely, then theoretically with enough time you have a 100% chance to reverse any transaction since the last hardcoded block. But even with a much smaller fraction of the hashrate there is still a chance you can reverse a transaction. For 3 confirmations, the numbers look like this:

Percentage of hashrate		Chance of reversing 3 confirmations
----------------------		----------------------------------
51% or more		100%
40%		66.4%
30%		32.5%
20%		10.3%
10%		1.3%
5%		0.2%

If I'm selling something like a house or a car for several tens of thousands or hundreds of thousands of dollars worth, then even a 1% chance of reversal is too high for me. For the sake of an additional 30 minutes, I'm waiting for some more confirmations. If I'm selling some second hand books or something for a few bucks, then 3 confirmations is more than enough.

[slaman29]

As you know, each Bitcoin transaction usually takes a few seconds, and confirmation of the same transaction starts ten minutes after that. During this time, interaction is permitted and may also be reversible. Deceptive users try to cheat. If you can't wait for approval, request a small transaction fee or use the Unsafe Interactions Detection System, which can enhance security. For higher amounts, e.g. US$1,000, it makes sense to wait for 6 confirmations or more. Any confirmation can reduce the risk of reverse transactions exponentially.

Double spend attacks are no longer easy to carry out, and most sites already can detect the moment the spender tries to doublespend the coins. Even with RBF flagged sites will invalidate the original transactin.

I think these days even 1 confirmation is enough but most sites require just 3, I haven't seen 6 confirmations in a very long time now:)

[o_e_l_e_o]

Some times, in a same 14D period, two blocks can be found within seconds or a few minutes shorter than 10 mins. However, it does not happen too often.

Actually, more often than you might think. Mining blocks is a Poisson process, and so the probability of finding a block within the next x seconds can be given by the equation:

1-e^(-x/600)

I you set x to be 2 minutes (120 seconds), then you'll find that 18.1% of blocks, almost one fifth, are found within 2 minutes of the last block. To drop below the "1% of blocks" range, you have to lower your time limit to only 6 seconds.

[franky1]

Some times, in a same 14D period, two blocks can be found within seconds or a few minutes shorter than 10 mins. However, it does not happen too often.

Actually, more often than you might think. Mining blocks is a Poisson process, and so the probability of finding a block within the next x seconds can be given by the equation:

1-e^(-x/600)

I you set x to be 2 minutes (120 seconds), then you'll find that 18.1% of blocks, almost one fifth, are found within 2 minutes of the last block. To drop below the "1% of blocks" range, you have to lower your time limit to only 6 seconds.

um no..
you really are going wrong alot this month

what it is, is this
imagine there are 20 pools
one with 15exa
nine with 5exa each
ten with 3 exa each

totalling 90exa

the big pool(15exa) can go through the entire nonce sequence in 50 minutes
the nine pools(5exa) each go through the nonce range in 150minutes each
the ten pools(3exa) each go through the nonce range in 500minutes each

the odds of big pool getting a block in 10 minutes is ~20%
the odds of one of the nine (5xa) is ~6.6%
the odds of one of the ten(3exa) is 4%

and it plays out like this (using excel and rand function)
block 1
pool 15exa  37                  (rand*50)
pool 5exa   147                  (rand*150)
pool 5exa   84                  (rand*150)
pool 5exa   127                  (rand*150)
pool 5exa   13                  (rand*150)
pool 5exa   49                  (rand*150)
pool 5exa   31                  (rand*150)
pool 5exa   113                  (rand*150)
pool 5exa   61                  (rand*150)
pool 5exa   93                  (rand*150)
pool 3exa   95                  (rand*250)
pool 3exa   28                  (rand*250)
pool 3exa   123                  (rand*250)
pool 3exa   21                  (rand*250)
pool 3exa   164                  (rand*250)
pool 3exa   224                  (rand*250)
pool 3exa   51                  (rand*250)
pool 3exa   82                  (rand*250)
pool 3exa   63                  (rand*250)
pool 3exa   211                  (rand*250)

block 2

pool 15exa   6
pool 5exa   52
pool 5exa   111
pool 5exa   109
pool 5exa   74
pool 5exa   59
pool 5exa   38
pool 5exa   22
pool 5exa   54
pool 5exa   128
pool 3exa   130
pool 3exa   172
pool 3exa   11
pool 3exa   64
pool 3exa   36
pool 3exa   140
pool 3exa   152
pool 3exa   225
pool 3exa   156
pool 3exa   50

and if you run it enough times you see that its no where even close to 18% of pools getting a block nearly at the same time.
what you do work out is the 'fastest first' of each block if you add it all up and average it over 2016 times is that the average works out as a block ~ every 10 minutes.
where by the big pool(15exa) gets more blocks on average than the other pools

[Trojane]

Programmers and excutives of this currency haven't made stricter securities as a matter of fact . you could only safely purchase these coins but that doesn't guarantee them being 100% secured for now

[o_e_l_e_o]

-snip-

Your numbers are wrong and also irrelevant.

It doesn't matter who controls what hash power, as long as the total hash power is roughly the same as it was at the last difficulty retarget and so the average block time is still close to 600 seconds. If this is not the case, then you can adjust the numbers in the equation I gave above. We are considering the entire network here, not individual miners.

As I stated above, bitcoin mining is a Poisson process. You can read about this here: https://en.wikipedia.org/wiki/Poisson_point_process

You can model the distribution using the equation (as given on the linked page above):

P{N = n} = Λⁿ * e^-Λ / n!

If you take n to equal 0 (i.e. you won't find a block), and take lambda (Λ) to equal the number of blocks you would expect to find in a given time frame, then you can simplify that equation to

P = Λ⁰ * e^-Λ / 0!
P = 1 * e^-Λ / 1
P = e^-Λ

Therefore, the probability of not finding a block when you would expect to find Λ blocks is equal to e^-Λ. For example, the probability of not finding a block in 10 minutes, when you would ordinarily expect to find 1 block in 10 minutes, is e^-1 = 36.8%

Given the equation P = e^-Λ, then we can take the inverse to find the probability of finding a block: 1-P = 1-e^-Λ. So the probability of finding a block in 10 minutes is 1-e^-1 = 63.2%.

So, as I said above, the probability of finding a block in 2 minutes is therefore 1-e^-0.2 = 18.1%.

[kryptqnick]

As you know, each Bitcoin transaction usually takes a few seconds, and confirmation of the same transaction starts ten minutes after that. During this time, interaction is permitted and may also be reversible. Deceptive users try to cheat. If you can't wait for approval, request a small transaction fee or use the Unsafe Interactions Detection System, which can enhance security. For higher amounts, e.g. US$1,000, it makes sense to wait for 6 confirmations or more. Any confirmation can reduce the risk of reverse transactions exponentially.

Do you mean zero-confirmation transactions when you say 'instant' transactions? They are indeed unsafe and can be manipulated, but I think they're also the future of true global adoption (we just need to set a reasonable max limit for a transaction like this, and prosecute the cheaters when possible). That's because you don't need to wait, and you don't have to pay crazy fees, and these two are essential if we're dreaming of a future where you can pay with BTC at a supermarket. That being said, I've never seen anyone accept such transactions so far (at least one confirmation is a requirement for local exchanges I use, for instance).

[Keremgor]

 Best secure tx method with full wallet control is Grin s tx style ,even prevents rookie users to send wrong adress.

https://medium.com/@brandonarvanaghi/grin-transactions-explained-step-by-step-fdceb905a853

[tranthidung]

Actually, more often than you might think. Mining blocks is a Poisson process, and so the probability of finding a block within the next x seconds can be given by the equation:

1-e^(-x/600)

I you set x to be 2 minutes (120 seconds), then you'll find that 18.1% of blocks, almost one fifth, are found within 2 minutes of the last block. To drop below the "1% of blocks" range, you have to lower your time limit to only 6 seconds.

From real data, it's what I get.

• Data source: https://loyce.club/blockdata/time.txt.gz
• About 47% of blocks found from 2 to 10 minutes
• For the 601+s blocks: 50% of them are from 762s to 1380s with the median is at 992s

Details
All time

Code:

Summary for variables: blocktime_diff
     by categories of: blocktime_cat 

blocktime_cat |         N      mean        sd       p50       p25       p75       min       max
--------------+--------------------------------------------------------------------------------
        <= 5s |    3838.0       2.8       1.6       3.0       1.0       4.0       0.0       5.0
      6 - 10s |    4686.0       8.1       1.4       8.0       7.0       9.0       6.0      10.0
     11 - 20s |   10849.0      15.6       2.8      16.0      13.0      18.0      11.0      20.0
     21 - 30s |   11593.0      25.6       2.9      26.0      23.0      28.0      21.0      30.0
     31 - 60s |   34761.0      45.3       8.7      45.0      38.0      53.0      31.0      60.0
    61 - 120s |   64745.0      89.7      17.4      89.0      74.0     105.0      61.0     120.0
   121 - 300s |  155702.0     205.2      52.0     202.0     160.0     249.0     121.0     300.0
   301 - 600s |  169268.0     437.6      85.8     431.0     362.0     510.0     301.0     600.0
       601+ s |  241486.0    1178.8    1213.4     992.0     762.0    1380.0     601.0  463160.0
--------------+--------------------------------------------------------------------------------
        Total |  696928.0     571.9     850.8     394.0     165.0     784.0       0.0  463160.0
-----------------------------------------------------------------------------------------------

2020

Code:

Summary for variables: blocktime_diff
     by categories of: blocktime_cat 

blocktime_cat |         N      mean        sd       p50       p25       p75       min       max
--------------+--------------------------------------------------------------------------------
        <= 5s |     261.0       3.1       1.7       3.0       2.0       5.0       0.0       5.0
      6 - 10s |     323.0       8.1       1.3       8.0       7.0       9.0       6.0      10.0
     11 - 20s |     755.0      15.6       2.8      16.0      13.0      18.0      11.0      20.0
     21 - 30s |     964.0      25.7       2.9      26.0      23.0      28.0      21.0      30.0
     31 - 60s |    2789.0      45.1       8.7      45.0      37.0      53.0      31.0      60.0
    61 - 120s |    4693.0      89.7      17.6      89.0      74.0     105.0      61.0     120.0
   121 - 300s |   11373.0     205.8      51.9     203.0     161.0     250.0     121.0     300.0
   301 - 600s |   12705.0     438.8      85.9     433.0     364.0     511.0     301.0     600.0
       601+ s |   19359.0    1194.3     604.8    1009.0     770.0    1421.0     601.0    6790.0
--------------+--------------------------------------------------------------------------------
        Total |   53222.0     594.2     597.5     412.0     171.0     823.0       0.0    6790.0
-----------------------------------------------------------------------------------------------

2021

Code:

blocktime_cat |         N      mean        sd       p50       p25       p75       min       max
--------------+--------------------------------------------------------------------------------
        <= 5s |     161.0       3.1       1.6       3.0       2.0       5.0       0.0       5.0
      6 - 10s |     209.0       8.0       1.4       8.0       7.0       9.0       6.0      10.0
     11 - 20s |     471.0      15.6       2.9      16.0      13.0      18.0      11.0      20.0
     21 - 30s |     529.0      25.8       2.9      26.0      23.0      28.0      21.0      30.0
     31 - 60s |    1714.0      44.8       8.6      45.0      37.0      52.0      31.0      60.0
    61 - 120s |    2913.0      89.6      17.4      90.0      74.0     104.0      61.0     120.0
   121 - 300s |    6930.0     205.8      52.1     204.0     161.0     250.0     121.0     300.0
   301 - 600s |    7859.0     439.5      85.0     434.0     365.0     511.0     301.0     600.0
       601+ s |   12230.0    1217.5     650.8    1019.0     772.0    1440.0     601.0    8354.0
--------------+--------------------------------------------------------------------------------
        Total |   33016.0     609.7     626.3     422.0     173.0     836.0       0.0    8354.0
-----------------------------------------------------------------------------------------------

[o_e_l_e_o]

From real data, it's what I get.

Perfect. Thanks for the verification.

We can use the formula I gave above to calculate the probability with a specific time frame as you have. So, for example, if we are interested in the 11 - 20s bracket, we would calculate the probability of finding a block within 20 seconds, the probability of finding a block within 10 seconds, and then subtract the two. Given this, then for the brackets you have used then numbers look like this:

Bracket	Calculated	Actual
------------	------------	------------
⩽5s	0.8%	0.6%
6-10s	0.8%	0.7%
11-20s	1.6%	1.6%
21-30s	1.6%	1.7%
31-60s	4.6%	5.0%
61-120s	8.6%	9.3%
121-300s	21.2%	22.3%
301-600s	23.9%	24.3%
⩾601s	36.8%	34.7%

There is a slight skew away from "greater than 10 minutes" towards blocks being a bit faster than 10 minutes. This is due to the fact that the average block time is almost always under 10 minutes due to the constantly increasing hash rate.

[tranthidung]

There is a slight skew away from "greater than 10 minutes" towards blocks being a bit faster than 10 minutes. This is due to the fact that the average block time is almost always under 10 minutes due to the constantly increasing hash rate.

It is due to the fact that the Bitcoin difficulty retarget (or adjustment) is set for each 2016 block (~ 14 days). Most of retargets in history are positive that is what you implied. Hashrate increases first, blocks within 14 days will be found faster than before, and it's certainly that more blocks will be found shorter than 10 minutes or at least shorter than average time before most of difficulty retargets.

• The history of Bitcoin difficulty adjustment (in percent)

[ranochigo]

If you're talking about 0-conf transaction, you should choose how much risk you're willing to accept. DannyHamilton posted brief idea about it.

I used to think heuristics are sufficient to prevent fraud but that isn't really that applicable as time goes by. If every transaction has an opt-in RBF, then chances are, there would be an inherent degree of risk to every of your transactions and it isn't sufficient cushioning for most merchants. Bitpay used to have a pretty neat zero-conf for loads of TXes but I haven't had it in the recent years. The network has become more volatile and unpredictable so losses from these zero-conf TXes are potentially going to occupy a larger percentage.

The risk is of course, relative and that the measures taken are all valid. However, given that we've gotten so many off-chain solutions, I don't really think it is necessary for merchants to still be undertaking these risks with their transactions.

[o_e_l_e_o]

and it's certainly that more blocks will be found shorter than 10 minutes or at least shorter than average time before most of difficulty retargets.

The average block time over the entirety of bitcoin's existence is actually 9 minutes 32 seconds. If you replace 600 with 572 in my equations above, they come very close to the observed rates.

If every transaction has an opt-in RBF, then chances are, there would be an inherent degree of risk to every of your transactions and it isn't sufficient cushioning for most merchants.

If every transaction was opted-in to RBF, then the only situation in which it would reasonable to accept zero confirmation transactions in my opinion would be situations where you trust the other party to make good on a promise. If you wouldn't accept an "IOU" or someone verbally telling you that they'll pay you at a later date, then you shouldn't accept a zero confirmation transaction from that person.

However, given that we've gotten so many off-chain solutions, I don't really think it is necessary for merchants to still be undertaking these risks with their transactions.

Completely agree. If you want to accept payments instantly or make payments instantly, then just open a Lightning channel. There are plenty of wallets out there now which will do all the heavy lifting so to speak for you if you really can't be bothered to open a channel yourself.

and was easily broken into by hackers

Bitcoin has never been "broken into by hackers".

[DannyHamilton]

So, as I said above, the probability of finding a block in 2 minutes is therefore 1-e^-0.2 = 18.1%.

An interesting effect of the maths involved that MANY people get wrong is:

No matter how long you've been waiting for a block, if a block isn't found yet, you will always have an average of 10 more minutes to wait.
If a block has just been found, then the average wait until the next block will be 10 minutes.
If you've been waiting 5 minutes since the last block was found, then the average wait until the next block is found will be 10 minutes.
If you've been waiting 20 minutes since the last block was found, then the average wait until the next block is found will be 10 minutes.
If you've been waiting an hour since the last block was found, then the average wait until the next block is found will be 10 minutes.

Furthermore (if I remember my maths correctly, but correct me if I'm wrong on this one) your calculation isn't ONLY for the probability of finding a block within 2 minutes of the previous block. It's also the probability that a block will be found in the NEXT 2 MINUTES, no matter how long you've already been waiting.  So, after 10 minutes of waiting since the most recently found block, there's still an 18.1% probability that the next block will show up in the NEXT 2 MINUTES. After an hour of waiting since the most recently found block, there's still an 18.1% probability that the next block will show up in the NEXT 2 MINUTES.

[ranochigo]

While i agree that the network is more volatile (mainly due to popularity of opt-in RBF), there are still few ways to accept 0-conf transaction. For example,
1. On casino, you can't withdraw your coin before all deposit have at least 1 confirmation.

Actually, I remember I used to hear that certain gambling sites were implementing this before but eventually stopped doing this. An attack vector for this would be to deposit funds > If loss = Double spend, else confirm. The tactic was exploited through GHash.io previously, but I recall there were more instances of this happening and eventually it was stopped altogether or at least available only for non-optinRBF Txes.

0-conf TXes at low amounts would still be feasible in the case that the attacker exposes their identity in the first place and makes it easy to persecute if needed. Else, then it really doesn't make sense and even with $3 TXes, I never had the chance to get instant TXes anymore.