Topic: Bitcoin instant transactions are less secure - page 2. (Read 359 times)
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.
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.
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.
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
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
I think the OP is speaking more from hearsay than from his own experiences doing Bitcoin transactions:
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.
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.
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.
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.
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.
Jump to: