What Happens If You Send Btc At Same Time on 2 Different Devices?

[jerry0]

Example with say 1 btc.  Say it is in a hardware wallet.  You also then enter the seed phrase in another hardware wallet or it could be a software wallet.



Now let say you ask a friend to help you with this.  Basically both of you at the same time go in the process of trying to send that same 1 btc to another wallet address.   Thus each of you would send it to a different address.  Of course both of these addresses would be addresses that you own.  So imagine during this process where you both click next at the same time.  You both then copy the btc address you want to send to.  Now when at the confirmation screen and it ask you to confirm, both of you click yes at the same exact time. 



First off... I assume both wallets could get to the last part of confirming the receiving address before sending?  Now the moment it is sent... only one of the two transactions will go through correct?  If so, how would you know which one it would be?  Assuming you use the same sending fee... what happens?  Is it a matter of luck?  If one uses a higher sending fee than the other... then the higher sending fee would go through and not the other one?  So what happens after few minutes then when you check the blockchain transaction of each one?  Would one show confirmation but the other doesn't?  Would both eventually show at least one confirmation?  Would one of the transactions even get rejected the moment both of you click send?  What if you click send btc... but your friend takes a few seconds later to send btc?  Does that mean your transaction will work but his doesn't?  What if you send it first with a low transaction fee but he sends it just few seconds later with a very high transaction fee?  Does that matter?  I remember there was that replace by fee with electrum that was talked about... does that apply to this?



I heard this is actually called a double spend... is that correct?  So basically some people who want to scam would say okay I send you btc and then they send it... but they also send btc to another address at same time?  So they might send you the transaction id for you to check on blockchair to see the confirmations?  But the transaction they send to you... which they want cancelled... it would still show one or two confirmations... before it eventually will get rejected?  Is that how it works?



I remember someone mentioned if its small amounts you receive you only need one or two confirmations.  If it's medium amount you want at least three confirmations.  But if its high amounts, you want like 6 confirmations or something like that?  So how many confirmations minimum do you need before you know a transaction cannot be cancelled?  Obviously you don't want to see a confirmation and then you send the other person money or deposit cash in their bank account only to later find out the transaction got rejected.



Now what if it was two different devices but you are both sending it to the same btc address?  What happens there? 

[PrivacyG]

The Bitcoin network is pretty smart.  While I do not know the most accurate answer, I will try to use my logic to find it.

I would assume that a node which has already received a transaction containing specific UTXO's will not accept another transaction containing the same UTXO's but with a different recipient.  If it would, I could create a million different transactions and spam the mempool and the nodes.  The most accurate answer is probably that the transaction that goes on is the one seen first by nodes and unless Replace By Fee is used, it is also the transaction that gets mined into a block.

-
Regards,
PrivacyG

[jackg]

Afaik it would be based off the fee used and then based off how well the transaction propagates.

If a miner has a transaction and a rival one that spends the same inputs and costs the same, it'll just drop the rivla transaction and keep mining the one it already has.

So it is probability based somewhat but it might also be affected by transfer speeds between where it's broadcast from.

[o_e_l_e_o]

Now the moment it is sent... only one of the two transactions will go through correct?

Both will be broadcast. They will each end up in a variable number of individual mempools, but only one will be included in a block.

If so, how would you know which one it would be?

If you broadcast to two random nodes, then you don't.

Assuming you use the same sending fee... what happens?

Both are broadcast, both end up in some mempools, only one is mined.

Is it a matter of luck?

It's a matter of which transaction has the most connected nodes and the fastest route the network to see how many mempools it ends up in. From there, it is a matter of luck which one gets included in a block, although the one which present in more mempools than the other has a higher chance of being mined.

If one uses a higher sending fee than the other... then the higher sending fee would go through and not the other one?

No. Most nodes will accept whichever transaction they see first, and would ignore a double spend even if the fee is higher (unless the transactions are flagged as RBF).

So what happens after few minutes then when you check the blockchain transaction of each one?  Would one show confirmation but the other doesn't?

Depends on which transaction is present in the mempool the block explorer you are using is looking at.

Would both eventually show at least one confirmation?

No. Only one would (excluding the extremely unlikely scenario of two competing blocks at the same height, each including a different one of your transactions).

Would one of the transactions even get rejected the moment both of you click send?

If the first transaction propagated fast enough, then maybe.

What if you click send btc... but your friend takes a few seconds later to send btc?  Does that mean your transaction will work but his doesn't?

As above. The second transaction would be rejected as a double spend.

What if you send it first with a low transaction fee but he sends it just few seconds later with a very high transaction fee?  Does that matter?

No, unless you are opted in to RBF.

I remember there was that replace by fee with electrum that was talked about... does that apply to this?

If the transactions are flagged as RBF, then the higher fee paying one will win.

I heard this is actually called a double spend... is that correct?

It's an attempted double spend, yes.

So basically some people who want to scam would say okay I send you btc and then they send it... but they also send btc to another address at same time?  So they might send you the transaction id for you to check on blockchair to see the confirmations?  But the transaction they send to you... which they want cancelled... it would still show one or two confirmations... before it eventually will get rejected?  Is that how it works?

No. Except in very rare cases, a double spend can only reverse unconfirmed transactions. Once a transaction has a confirmation, it is very unlikely to be reversed.

I remember someone mentioned if its small amounts you receive you only need one or two confirmations.  If it's medium amount you want at least three confirmations.  But if its high amounts, you want like 6 confirmations or something like that?  So how many confirmations minimum do you need before you know a transaction cannot be cancelled?

There is no number of confirmations which say a transaction cannot be cancelled. Theoretically, an attacker with enough hashpower could reverse any number of confirmations (back to the last hardcoded checkpoint). In reality, 6 confirmations is extremely difficult to reverse and can be considered final for all intents and purposes. If someone managed to reverse 6 confirmations, then the price of bitcoin would tank and your reversed transaction will be worthless anyway.

Now what if it was two different devices but you are both sending it to the same btc address?  What happens there?

Exactly the same as above.

[sheenshane]

I heard this is actually called a double spend... is that correct?  So basically some people who want to scam would say okay I send you btc and then they send it... but they also send btc to another address at same time?  So they might send you the transaction id for you to check on blockchair to see the confirmations?  But the transaction they send to you... which they want cancelled... it would still show one or two confirmations... before it eventually will get rejected?  Is that how it works?

You know the Bitcoin network is really good and smart, once the transaction has a confirmation even it's one confirmation, it will be confirmed and once there's a confirmation, it's an irreversible transaction.

All comments above are right, this is just an addition and a friendly reminder.
The safe transaction should always have to wait for at least 3 confirmations on the network, that's usually considered as a safe transaction and can't even be canceled through RBF.  You can't broadcast two the same transaction at once, it should always be one transaction.

[dansus021]

the answer is who got confirmation first it can depend on connection aor anything else but like everyone else said is only one that get approved u can try right know with little amount if still curious about it  if the fee expensive u can try it on different chain because blockchain principal is same

[witcher_sense]

You know the Bitcoin network is really good and smart, once the transaction has a confirmation even it's one confirmation, it will be confirmed and once there's a confirmation, it's an irreversible transaction.

A bitcoin transaction getting one confirmation means it has already been added to the block, but it still can't be considered irreversible due to possible reorganizations of blockchain or unresolved forks. The node you control maintains its own copy of the blockchain, but it has to change the recent history from time to time to stay in consensus with other nodes of the network. To be sure that a particular transaction is a permanent record in a blockchain, you need to wait until your node receives a sufficient number of blocks (6 or more).

All comments above are right, this is just an addition and a friendly reminder.
The safe transaction should always have to wait for at least 3 confirmations on the network, that's usually considered as a safe transaction and can't even be canceled through RBF. 

RBF has nothing to do with cancelling the transaction that has already been confirmed by the bitcoin network -- it only works with those that still unconfirmed. Therefore, even one confirmation is enough to render further RBF transactions useless.

You can't broadcast two the same transaction at once, it should always be one transaction.

As has already been noted, you can broadcast as many the same transactions as you want, but only one of them will be mined. Also, I think that a node spamming the network with double spend attempts may be banned by neighboring nodes.

[o_e_l_e_o]

To be sure that a particular transaction is a permanent record in a blockchain, you need to wait until your node receives a sufficient number of blocks (6 or more).

This is not an accurate statement. On one hand, 6 confirmations is unnecessary for small value transactions, since an attacker with enough hashpower to overcome 6 confirmations would make more money by just mining honestly than they would by double spending a transaction after 6 confirmations except for very large value transactions. For most individual users, 3 or so confirmations is enough. Even if there is an accidental chain split, then usually the transaction would already be included in the other chain too, but at worst the transaction will just go back to being unconfirmed but will still be included in the other chain at some point.

And considering that statement from the other angle, 6 confirmations still does not mean a transaction is a "permanent record" in the blockchain. Transactions with any number of confirmations (back to the last hardcoded block - 295,000) could be theoretically reversed with enough attack power. It just becomes exponentially more difficult with each additional confirmation.

[Charles-Tim]

A bitcoin transaction getting one confirmation means it has already been added to the block, but it still can't be considered irreversible due to possible reorganizations of blockchain or unresolved forks.

In chain reorganization, two blocks are mined, but the two blocks contain the same transactions which are included into the block by miners. If block A and B are mined at the same time, and new blocks mined are building on block A, that means block B would be invalidated, but the invalid transactions in block B are also included in blockchain A (block A has the transactions too). This means that it can not be considered as reversible as the transaction is confirmed on block A. If a transaction does not exist on the valid chain, that means probably it has not occured, that it is not included in a block at all. But if there are reorg transactions that is not included in the valid block, it would still be included on a block in the longest chain.

[NeuroticFish]

Example with say 1 btc.  Say it is in a hardware wallet.  You also then enter the seed phrase in another hardware wallet or it could be a software wallet.

1. Your BTC is not in any wallet. It's on the blockchain. The wallet only handles the keys.
2. As said, both tx are sent. One (if you have one with bigger fee, it may be that one, but not necessarily) will get into a block.
From what I see, here's the trick: it depends on how you 1 BTC "looks like". See, the coins in your wallet consist in inputs (let's say transactions coming to you).
If your 1 BTC consists from multiple inputs and the unconfirmed tx didn't use any of the inputs the (now) confirmed tx did, then the second tx will also get confirmed.
If the unconfirmed tx tries to use at least one input that's already spent (same goes if there's only one input there), then the unconfirmed tx will not be included into any block and (eventually) dropped from mempool(s).

[o_e_l_e_o]

In chain reorganization, two blocks are mined, but the two blocks contain the same transactions which are included into the block by miners.

Not necessarily. The two blocks can contain any transactions the individual miners want, which means that that any given transaction may appear in both blocks, only in either one of the two blocks, or in neither of the two blocks.

If block A and B are mined at the same time, and new blocks mined are building on block A, that means block B would be invalidated, but the invalid transactions in block B are also included in blockchain A (block A has the transactions too).

Only if all the transactions from the now stale Block B had already been mined in Block A or Block A+1. Otherwise the transactions in Block B would return to the mempool and move from having 1 confirmation to being unconfirmed. It's not common by any means, but it has happened, and transactions have been double spent in this way before.