Bitcoin Double Spend

[imjose]

Bitcoin transactions are irreversible.

So when I broadcast a txn to the network, with payment to a merchant, wouldn't the merchant receive the bitcoin that I have sent him even if there is no confirmation..!

How can I double spend the bitcoin (this time with a higher txn fee), since my public key would get debited and the merchant's public key would get credited as soon as I broadcasted my txn to the network..?

Please help to understand.

[cypherblock]

Only transactions that are in a block on the blockchain are permanent (and really only for sure if there are a few blocks on top of the block the tx is in). So when you broadcast a transaction it does not go immediately into a block. It sits in what is called the mempool of bitcoin nodes that receive that broadcast. Only later when the transaction has been put into a block and the block has been broadcasted and accepted by the network does the transaction become fixed and typically after a few blocks have been made on top of that block do we consider it permanent and irreversible.

[imjose]

Only transactions that are in a block on the blockchain are permanent (and really only for sure if there are a few blocks on top of the block the tx is in). So when you broadcast a transaction it does not go immediately into a block. It sits in what is called the mempool of bitcoin nodes that receive that broadcast. Only later when the transaction has been put into a block and the block has been broadcasted and accepted by the network does the transaction become fixed and typically after a few blocks have been made on top of that block do we consider it permanent and irreversible.

So, it means that the merchant wouldn't be able to make another txn with the bitcoin that I gave him until unless there is at-least one confirmation..?

And as long as there is no confirmation, my public key won't get debited and I can create another txn to someone else..?

[DannyHamilton]

Bitcoin transactions are irreversible.

This is false.

True statements would be:
Well confirmed bitcoin transactions are prohibitively expensive to reverse.  Unconfirmed transactions in some situations can be trivially easy to eliminate.

So when I broadcast a txn to the network, with payment to a merchant, wouldn't the merchant receive the bitcoin that I have sent him even if there is no confirmation..!

No.  He might receive the transaction, but he wouldn't know for certain if he will have the ability to spend those bitcoins in the future.

How can I double spend the bitcoin (this time with a higher txn fee),

You simply create a new transaction that spends at least one fo the same inputs and convince a miner (or mining pool) to confirm it for you.

since my public key would get debited and the merchant's public key would get credited as soon as I broadcasted my txn to the network..?

This is completely wrong.  Bitcoin NEVER debits or credits ANY public keys.  It doesn't matter if the transaction is confirmed or unconfirmed, that's just not how bitcoin works.

Now, you might be using an account at a service (such as Coinbase.com), and that service might choose to debit or credit the account that they provide you, but they can just reverse the debit and the credit in their accounting system if they want to.

You also might be using a wallet that hides the details of how bitcoin works. Such a wallet might present an interface that looks like an account and that updates wallet balances to look like there is debiting and crediting going on. However, this is all an attempt by your wallet to show you something that feels familiar. It has nothing to do with how bitcoin actually works, and can cause confusion if you try to apply your knowledge of account based credit and debit systems to the underlying transaction input and output based blockchain system.

[DannyHamilton]

So, it means that the merchant wouldn't be able to make another txn with the bitcoin that I gave him until unless there is at-least one confirmation..?

They can, but it would be a very bad idea.  Since your transaction might disappear and cease to exist, then if they choose to spend your transaction, that means that their transaction might also disappear and cease to exist.  This means that the person that the merchant is paying might be concerned about that risk and refuse to supply theproduct or service that the merchant wants until BOTH your transaction AND the merchant's transaction confirms  If your transaction vanishes, then the merchant might be accused of attempting a scam (and the merchant might accuse you of attempting a scam as well).

Smart merchants that care about their reputation will only spend confirmed transaction outputs.

And as long as there is no confirmation, my public key won't get debited and I can create another txn to someone else..?

Your public key will never get debited.  That's not how Bitcoin works.  There are no balances at the technical level of the bitcoin blockchain.  There are only transaction inputs and transaction outputs.

But to answer the question that you are trying to ask...

If there is no confirmation, it would be possible for you to send the same bitcoins (spend the same transaction outputs) in another transaction to someone else.  If you could convince a miner (or mining pool) to confirm this new transaction, then the old transaction would become invalid and would disappear.

[imjose]

So, it means that the merchant wouldn't be able to make another txn with the bitcoin that I gave him until unless there is at-least one confirmation..?

They can, but it would be a very bad idea.  Since your transaction might disappear and cease to exist, then if they choose to spend your transaction, that means that their transaction might also disappear and cease to exist.  This means that the person that the merchant is paying might be concerned about that risk and refuse to supply theproduct or service that the merchant wants until BOTH your transaction AND the merchant's transaction confirms  If your transaction vanishes, then the merchant might be accused of attempting a scam (and the merchant might accuse you of attempting a scam as well).

Smart merchants that care about their reputation will only spend confirmed transaction outputs.

And as long as there is no confirmation, my public key won't get debited and I can create another txn to someone else..?

Your public key will never get debited.  That's not how Bitcoin works.  There are no balances at the technical level of the bitcoin blockchain.  There are only transaction inputs and transaction outputs.

But to answer the question that you are trying to ask...

If there is no confirmation, it would be possible for you to send the same bitcoins (spend the same transaction outputs) in another transaction to someone else.  If you could convince a miner (or mining pool) to confirm this new transaction, then the old transaction would become invalid and would disappear.

Thank you Danny for explaining it..

[deisik]

Bitcoin transactions are irreversible.

This is false.

True statements would be:
Well confirmed bitcoin transactions are prohibitively expensive to reverse.  Unconfirmed transactions in some situations can be trivially easy to eliminate

This is six of one and half a dozen of the other. I can just as well say that someone could buy all bitcoins out there, already mined or to be mined, and then reverse any transaction he may feel inclined to. And I assume he might not actually need to buy all bitcoins...

Just enough to make mining no longer relevant

[franky1]

So, it means that the merchant wouldn't be able to make another txn with the bitcoin that I gave him until unless there is at-least one confirmation..?

They can, but it would be a very bad idea.  Since your transaction might disappear and cease to exist, then if they choose to spend your transaction, that means that their transaction might also disappear and cease to exist. 

kind of..
but what danny is describing as 'bad' is actually CPFP child-pays-for-parent. a future mining pool feature that prompts a mining pool to push the first transaction into the next block by raising the first transactions priority because the second transaction has a generous fee to so that both transactions to be deemed high priority.

CPFP is 'supposedly' meant to attempt to help merchants who receive funds with 0 fee(low priority), to then 'spend' that unconfirmed tx to another address they also own by adding a fee which is enough to make the first transaction a priority and 'hopefully' get the first tx into the next block before the customer tries to double spend.

the downside is that the customer can also use CPFP to do the same thing and pay themselves (double spend) using the exact same tactic. so CPFP is not a guarantee to prevent double spends. but atleast allows a merchant an oppertunity to raise the priority to speed up which block it will get confirmed in, to reduce the chances of a double spend.

but as i said the customer can do the same thing. so its still a case of fastest first and highest fee first wins

[deisik]

So, it means that the merchant wouldn't be able to make another txn with the bitcoin that I gave him until unless there is at-least one confirmation..?

They can, but it would be a very bad idea.  Since your transaction might disappear and cease to exist, then if they choose to spend your transaction, that means that their transaction might also disappear and cease to exist.

kind of..
but what danny is describing as 'bad' is actually CPFP child-pays-for-parent. a future mining pool feature that prompts a mining pool to push the first transaction into the next block by raising the first transactions priority because the second transaction has a generous fee to so that both transactions to be deemed high priority.

CPFP is 'supposedly' meant to attempt to help merchants who receive funds with 0 fee(low priority), to then 'spend' that unconfirmed tx to another address they also own by adding a fee which is enough to make the first transaction a priority and 'hopefully' get the first tx into the next block before the customer tries to double spend.

the downside is that the customer can also use CPFP to do the same thing and pay themselves (double spend) using the exact same tactic. so CPFP is not a guarantee to prevent double spends. but atleast allows a merchant an oppertunity to raise the priority to speed up which block it will get confirmed in, to reduce the chances of a double spend.

but as i said the customer can do the same thing. so its still a case of fastest first and highest fee first wins

If he can do the same thing, then this whole effort is meaningless. If the customer is not going to make a try at double-spend, this would only incur additional expenses (time and money wise), and if he does try (he will obviously try what's best to get there), this as you said won't change a thing

[franky1]

So, it means that the merchant wouldn't be able to make another txn with the bitcoin that I gave him until unless there is at-least one confirmation..?

They can, but it would be a very bad idea.  Since your transaction might disappear and cease to exist, then if they choose to spend your transaction, that means that their transaction might also disappear and cease to exist.

kind of..
but what danny is describing as 'bad' is actually CPFP child-pays-for-parent. a future mining pool feature that prompts a mining pool to push the first transaction into the next block by raising the first transactions priority because the second transaction has a generous fee to so that both transactions to be deemed high priority.

CPFP is 'supposedly' meant to attempt to help merchants who receive funds with 0 fee(low priority), to then 'spend' that unconfirmed tx to another address they also own by adding a fee which is enough to make the first transaction a priority and 'hopefully' get the first tx into the next block before the customer tries to double spend.

the downside is that the customer can also use CPFP to do the same thing and pay themselves (double spend) using the exact same tactic. so CPFP is not a guarantee to prevent double spends. but atleast allows a merchant an oppertunity to raise the priority to speed up which block it will get confirmed in, to reduce the chances of a double spend.

but as i said the customer can do the same thing. so its still a case of fastest first and highest fee first wins

If he can do the same thing, then this whole effort is meaningless. If the customer is not going to make a try at double-spend, this would only incur additional expenses (time and money wise), and if he does try (he will obviously try what's best to get there), this as you said won't change a thing

kinda..

at the moment (without CPFP active) if a customer sends zero fee.. a merchant has no tool.. and just has to wait for the tx to get accepted, more often then not tx with zero fee's end up getting dropped off the mempool and forgotten due to not being accepted into a block after many hours.
so at the moment merchants have a 3% change of the tx getting confirmed.

however CPFP makes it high priority.. again not a guarantee the merchant will win the double spend fight against a customer.. but atleast makes it now a 50% chance(more of a fair fight). it also means also knowing the result of winning or losing a double spend fight within 10minutes-1 hours, du to the priority increase each side is fighting.. instead of many hours just sitting there hoping the customer isnt gonna try anything.

all in all a merchant can send funds to himself to prioritise a tx to increase chances and reduce delay of it getting confirmed.., but as danny said, trying to spend an unconfirmed transaction to a third party is silly as its just adding another person into the mix of people that are at risk and could end up getting annoyed should things not go in their favour

[deisik]

So, it means that the merchant wouldn't be able to make another txn with the bitcoin that I gave him until unless there is at-least one confirmation..?

They can, but it would be a very bad idea.  Since your transaction might disappear and cease to exist, then if they choose to spend your transaction, that means that their transaction might also disappear and cease to exist.

kind of..
but what danny is describing as 'bad' is actually CPFP child-pays-for-parent. a future mining pool feature that prompts a mining pool to push the first transaction into the next block by raising the first transactions priority because the second transaction has a generous fee to so that both transactions to be deemed high priority.

CPFP is 'supposedly' meant to attempt to help merchants who receive funds with 0 fee(low priority), to then 'spend' that unconfirmed tx to another address they also own by adding a fee which is enough to make the first transaction a priority and 'hopefully' get the first tx into the next block before the customer tries to double spend.

the downside is that the customer can also use CPFP to do the same thing and pay themselves (double spend) using the exact same tactic. so CPFP is not a guarantee to prevent double spends. but atleast allows a merchant an oppertunity to raise the priority to speed up which block it will get confirmed in, to reduce the chances of a double spend.

but as i said the customer can do the same thing. so its still a case of fastest first and highest fee first wins

If he can do the same thing, then this whole effort is meaningless. If the customer is not going to make a try at double-spend, this would only incur additional expenses (time and money wise), and if he does try (he will obviously try what's best to get there), this as you said won't change a thing

kinda..

at the moment (without CPFP active) if a customer sends zero fee.. a merchant has no tool.. and just has to wait for the tx to get accepted, more often then not tx with zero fee's end up getting dropped off the mempool and forgotten due to not being accepted into a block after many hours.
so at the moment merchants have a 3% change of the tx getting confirmed

I didn't consider that possibility. Then I agree that sending funds to oneself makes sense for a merchant if a transaction has small or no fee attached (for the sake of getting faster confirmation times). But is it worth doing if the merchant can just request at least one confirmation by the blockchain, thereby making it entirely the buyer's problem (whether he pays the fee or not)?

Most exchanges require at least three confirmations to credit funds to a trader's account

[franky1]

I didn't consider that possibility. Then I agree that sending funds to oneself makes sense for a merchant if a transaction has small or no fee attached (for the sake of getting faster confirmation times). But is it worth doing if the merchant can just request at least one confirmation by the blockchain, thereby making it entirely the buyer's problem (whether he pays the fee or not)?

Most exchanges require at least three confirmations to credit funds to a trader's account

ofcourse waiting for atleast 1 confirm is the ultimate goal.  but exchanges that has offered nothing upfront can happily continue offering nothing until its confirmed..

but how many times have you gone to a restaurant. or a bar.. where you have set a bartab for the evening. and once you have ate the food and drank the drinks. you want to pay.. do you then see the merchant still happy to wait 6 hours for it to confirm..

in some cases if a customer 'mistakenly' sends a zero confirm on a trade that cannot wait around for hours. then its right to try to increase the odds the transaction would get accepted sooner and in the merchants favour.

my point is that CPFP is not a negative. (countering dannys 'bad idea') opinion.. but its not a guaranteed 100% double spend cure either. some merchants wont bother or care for CPFP, bt sometimes some trades are time sensitive

[deisik]

my point is that CPFP is not a negative. (countering dannys 'bad idea') opinion.. but its not a guaranteed 100% double spend cure either. some merchants wont bother or care for CPFP, bt sometimes some trades are time sensitive

Now I see your point and agree with it, though not because this feature can help prevent double-spends. If it does actually facilitate transactions (by shortening confirmation times), then it just can't be "bad"...

Unless there are other hidden drawbacks that might outweigh its usefulness, of course