[TESTED IT] Changing the transaction after broadcasting, what happens?

[mynonce]

If someone broadcasts a transaction 1 from an unspent txo to an address 1 and then, let's say after 10 minutes without a new block, they broadcast a new transaction 2 using the same unspent txo to an address 2, how do miners handle these? (Both transactions don't use RBF 'Replace By Fee')


EDIT:

I tested it ...

1. transferred 12,000 satoshi to the address 1PCPavJ1zyYn9rCu2p1e47vMPC11NWRCm9
relevant for the test: tx hash e0af61939fa152f941e3b6f80fb3662dbb1d7d6895542824df36ded40b5d1bf9 vout 0

2. after block 734,778 created two transactions using the same UTXO (tx hash e0af61939fa152f941e3b6f80fb3662dbb1d7d6895542824df36ded40b5d1bf9 vout 0):

(a) send 11,770 satoshi to the address 1AR7Ei6GVDxWPUyZ94pmUo6UNDSiVq5Qk1 (230 satoshi fee -> ~1 sat/byte)
(b) send 10,000 satoshi to the address 1Ba6okpMikNQRTaTifoKYc6z3m8gKfqXQ4 (2000 satoshi fee -> ~10 sat/byte)

3. broadcast transaction (a) via https://blockchair.com -> got the message:

Thanks, your transaction has been broadcast to the Bitcoin blockchain, its hash:
2c88d249902586908e55116527ff8cb4c14975bd233cb93a2b759db43a3fe358

4. waited ~1 minute, then broadcast transaction (b) via different providers:

https://blockchain.info
result: Code: -26, Error: txn-mempool-conflict

https://blockstream.info
result: sendrawtransaction RPC error: {"code":-26,"message":"txn-mempool-conflict"}

https://btc.network
result: Not a valid transaction hash!

https://bitaps.com
result: Mempool accept test failed: txn-mempool-conflict

... and others gave the same error code 26.

Transaction (a) has been confirmed in block 734,779 and transaction (b) rejected by all providers.


Then I found this:

source https://bitcoin.stackexchange.com/questions/58188/validation-error-error-26-258-txn-mempool-conflict

Question:
I am getting this error message. What does it mean? Validation Error: Error #-26: 258: txn-mempool-conflict

Answer (by JBaczuk):
This error means that you're trying to spend the same transaction output more than once.

More specifically, when you submit a transaction, a check is done (on the node) against the previous outputs of your new transaction to see if they are already trying to be spent by a transaction in the memory pool.

The check is in validation.cpp in the bitcoin source.

 




EDIT (2):

Tested it!

Fun experiment, with the expected outcome.

Yes, and that it is working and the broadcast transactions are being checked before the confirmation on the block, there is another proof:

I broadcast transaction (b) after transaction (a) had been confirmed. The nodes gave the error code -25 (missingorspent) instead of error code -26 (txn-mempool-conflict).

[1715022879]

1715022879

[1715022879]

1715022879

[Upgrade00]

So the parent UTXO is already confirmed in this scenario. Basically what you are suggesting is a double spend, when one tried to cancel out an initial transaction by double spending it.

Miners would likely favour the transaction with the higher fee. If the first transaction used a really low fee (in comparison with the surrent ferrate) it could get stuck in the mempool and remain unconfirmed, up till the time the second transaction is created, then the second one would likely be confirmed first if the fee paid is significantly higher.

Edit: missed the last part, as pointed out by BlackHatCoiner, this would only work if RBF is activated when creating the first transaction.

[BlackHatCoiner]

unspent tx

You mean unspent transaction output?

If you don't use RBF, then the nodes should not accept your second transaction as it tries to double-spend the previous outputs, something you've stated you don't want in your first transaction.

[Cryptomiles1]

So the parent UTXO is already confirmed in this scenario. Basically what you are suggesting is a double spend, when one tried to cancel out an initial transaction by double spending it.
Miners would likely favour the transaction with the higher fee. If the first transaction used a really low fee and is unconfirmed at the time the second transaction was created, then the second one would likely be confirmed first.

Sorry to intrude..
what if the first later confirmed, i have been among such case before whereby sending out transaction and was to slow and i couldn't able to way for the previous and i got initiated another transaction and the both confirmed the point of waiting for the previous.

please reply and don't find any offense towards my questions.
I want to learn more

[mocacinno]

So the parent UTXO is already confirmed in this scenario. Basically what you are suggesting is a double spend, when one tried to cancel out an initial transaction by double spending it.
Miners would likely favour the transaction with the higher fee. If the first transaction used a really low fee and is unconfirmed at the time the second transaction was created, then the second one would likely be confirmed first.

Sorry to intrude..
what if the first later confirmed, i have been among such case before whereby sending out transaction and was to slow and i couldn't able to way for the previous and i got initiated another transaction and the both confirmed the point of waiting for the previous.

please reply and don't find any offense towards my questions.
I want to learn more

I have a hard time understanding what you're saying... But basically, one unspent output can only be spent in one confirmed transaction.
Once a transaction spending a certain unspent output is confirmed, all unconfirmed transactions spending the same unspent output become invalid.

As a fictional example:
I fund address 1Address with an unspent output with value 0.001 BTC in transaction with transactionid abcdefghijklmnop and the transaction gets confirmed.
At this point, i can create transactions with tx id qsdfkmjiuqdsfqsdf and miuqpdfiousdfsdf both using unspent output abcdefghijklmnop with value 0.001 as an input. HOWEVER, only one of these transactions can EVER make it into a block. Once one of the two transactions gets confirmed, the other one gets kicked from all the mempools of all the nodes that have the other transaction in their mempool. If a miner would put the other transaction into a block, the block would become invalid and all the nodes of the network would reject said block.

[Upgrade00]

Sorry to intrude..
what if the first later confirmed, i have been among such case before whereby sending out transaction and was to slow and i couldn't able to way for the previous and i got initiated another transaction and the both confirmed the point of waiting for the previous.

Two transactions from the same input cannot get confirmed. Once the first one is confirmed, it is considered to be a spent transaction output and cannot be spent again. That would be a major flaw.

please reply and don't find any offense towards my questions.
I want to learn more

You don't have to apologize for asking a question. Everyone in this community is here to help and learn from one another.
Okay, maybe not "everyone" 

[Eternad]

AFAIK base on my observation when I'm sending transaction using 25blocks confirmation fee on electrum, Once I sent the transaction even if it's still unconfirmed. The Bitcoin that I sent is already removed on my wallet balance which impossible for me to do another transaction. The only option is to broadcast or adjust transaction fee to make it faster. But I think as explained above the first transaction will govern since transaction on Bitcoin wallet will just queue it.

[mynonce]

unspent tx

You mean unspent transaction output?

If you don't use RBF, then the nodes should not accept your second transaction as it tries to double-spend the previous outputs, something you've stated you don't want in your first transaction.

Yes, unspent transaction output.

But if one miner accepts the second transaction and their block is valid, so the network would accept it (this block) too, or not?

...
Two transactions from the same input cannot get confirmed. Once the first one is confirmed, it is considered to be a spent transaction output and cannot be spent again. That would be a major flaw.

We assume that both transactions are valid before being in a mined block. If transaction 2 has eg. a higher fee, how do the network/miners handle it?

[Charles-Tim]

If someone broadcasts a transaction 1 from an unspent txo to an address 1 and then, let's say after 10 minutes without a new block, they broadcast a new transaction 2 using the same unspent txo to an address 2, how do miners handle these? (Both transactions don't use RBF 'Replace By Fee')

This is not possible or it becomes invalidated. Only the first transaction will be valid. Why want to spend the same input in two transactions? The only time this would be possible is when the mempool is congested and your transaction has been dropped from the mempool which can probably happen after 14 days you broadcast the transaction. If your transaction is dropped from mempool, you will be able to rebroadcast another transaction using the same input.

[DaveF]

unspent tx

You mean unspent transaction output?

If you don't use RBF, then the nodes should not accept your second transaction as it tries to double-spend the previous outputs, something you've stated you don't want in your first transaction.

Yes, unspent transaction output.

But if one miner accepts the second transaction and their block is valid, so the network would accept it (this block) too, or not?

...
Two transactions from the same input cannot get confirmed. Once the first one is confirmed, it is considered to be a spent transaction output and cannot be spent again. That would be a major flaw.

We assume that both transactions are valid before being in a mined block. If transaction 2 has eg. a higher fee, how do the network/miners handle it?

Yes if both transactions are valid the 1st one mined gets put into a block and the other one is dropped.

That is always the risk with RBF, if a miner does not see the replacement transaction OR for whatever reason does not take it into their mempool the 1st one is still valid when it's mined.

-Dave

[Upgrade00]

But if one miner accepts the second transaction and their block is valid, so the network would accept it too, or not?

Yes. If RBF is enabled and the first transaction is still unconfirmed.

We assume that both transactions are valid before being in a mined block. If transaction 2 has eg. a higher fee, how do the network/miners handle it?

Both transactions cannot be in a "mined" block. Once one gets confirmed the other is invalid and if it has already been added to a block, so would the block too.

[mocacinno]

--snip--
This is not possible or it becomes invalidated. Only the first transaction will be valid. Why want to spend the same input in two transactions? The only time this should be possible is when the mempool is congested and your transaction has been dropped from the mempool which can happen after 14 days you broadcast your transaction. If your transaction is rldropped from mempool, you will be able to rebroadcast another transaction sending the same input.

Well... In the default node implementation it's not possible... That being said: it should be possible to fork the default node and include code to allow keeping two transactions spending the same unspent output in their mempool. That way, you could optimize fees even better (if you were a miner offcourse)...
This being said, the fact still remains that only one of the two transactions can ever end up in a block, and you are 100% correct that the default node implementation will not allow two transactions spending the same output in their mempools

[o_e_l_e_o]

We assume that both transactions are valid before being in a mined block. If transaction 2 has eg. a higher fee, how do the network/miners handle it?

There are various possible scenarios:

RBF disabled, transaction 1 broadcast several minutes before transaction 2:
Transaction 1 will already have spread throughout the network and be in most/all nodes' mempools. Transaction 2 will be rejected by the majority of nodes as an attempted double spend, regardless of the fees. It would be highly unlikely for transaction 2 to be confirmed.

RBF disabled, both transactions broadcast at the same time:
Both transactions will spread throughout the network. Some nodes will accept transaction 1 and some will accept transaction 2. For the majority, this will be based on which one they see first, and not on the fees. Which transaction ends up being confirmed will be down to a combination of which one pays the higher fee, how much hashing power sees each transaction, and luck.

RBF enabled:
Transaction 2 will replace transaction 1 if it pays a higher fee, otherwise it will be rejected.

[witcher_sense]

If someone broadcasts a transaction 1 from an unspent txo to an address 1 and then, let's say after 10 minutes without a new block, they broadcast a new transaction 2 using the same unspent txo to an address 2, how do miners handle these? (Both transactions don't use RBF 'Replace By Fee')

Miners can handle this easily: they include only one of the multiple conflicting transactions and collect fees from including it in case of a successful finding of a new block. Were they not incentivized to refuse other double spends, the interval between bitcoin blocks would increase significantly due to constant DDoS attacks from malicious actors. Many have already correctly said that the chances of a second non-RBF transaction being included in a block before the first one are minimal, however, you can still try to circumvent the limitations of the network by contacting miners directly. Real-world example: a hacker has stolen your funds and broadcasted a non-RBF transaction attaching relatively low fees. If you notice that immediately, you can create the other transaction that will spend the same UTXOs but to a different address. Next, you contact some mining pool operator and bribe them to include your second transaction instead of that sent by a hacker.

[DannyHamilton]

If someone broadcasts a transaction 1 from an unspent txo to an address 1 and then, let's say after 10 minutes without a new block, they broadcast a new transaction 2 using the same unspent txo to an address 2, how do miners handle these? (Both transactions don't use RBF 'Replace By Fee')

Are you asking what is most likely to happen based on the most common configurations of nodes and mining pools?

In this case, most nodes will reject the second transaction since they already have the first transaction in their mempool.  A mining pool will most likely eventually confirm the first transaction and broadcast the block. The second transaction will then be seen as invalid by all nodes and mining pools that have accepted the block and will be rejected.

An alternate scenario is if the first transaction is sent with the Replace By Fee (RBF) flag turned on.  In that case, if the second transaction is sent with a higher fee, most nodes will replace the first transaction in their mempool with the second one and will relay it to peers. Most mining pools will do the same. A mining pool will eventually confirm one of the transactions (probably the second transaction) and broadcast the block. The confirmed transaction (probably the second one) will be seen as the "valid" transaction, and the remaining unconfirmed transaction will then be seen as invalid by all nodes and mining pools that have accepted the block and will therefore be rejected.

Or are you asking what the protocol allows to happen, and technically could happen if some nodes and some mining pools choose to run non-typical configurations?

In this case, it is possible that any particular node might choose to accept the second transaction into its mempool regardless of the RBF flag or transaction fee. There is nothing in the protocol that prevents any single node from choosing to accept this second transaction if they want to. It is also possible that any particular mining pool might choose to accept the second transaction into its mempool regardless of the RBF flag or transaction fee and include it in the blocks it is working on.  Again, there is nothing in the protocol that prevents any particular mining pool from choosing this transaction over the other unconfirmed transaction. A mining pool will eventually confirm one of the transactions (most likely the first one, but it could be the second one). The confirmed transaction will be seen as the "valid" transaction, and the remaining unconfirmed transaction will then be seen as invalid by all nodes and mining pools that have accepted the block and will therefore be rejected.

[hatshepsut93]

A second transaction spending the UTXO of a previously broadcasted and unconfirmed transaction can be confirmed even without RBF if certain time has passed and nodes started purging the first transaction from their mempools. It can happen on practice if you make a transaction with very low fee, and the fees remain consistently high so the transaction is not getting confirmed for many days.

[mynonce]

Tested it!

Read the first post (EDIT).

[o_e_l_e_o]

Tested it!

Fun experiment, with the expected outcome.

The critical point here is that you waited a full minute before broadcasting transaction 2, which gave enough time for transaction 1 to fully spread throughout the entire network and be accepted in to the mempool of every node you then tried to broadcast transaction 2 to, resulting in transaction 2 being rejected.

A follow up experiment would be to do the same thing again, but broadcast transaction 2 only a second or two later to a different service from transaction 1 and see what happens. Depending on how well various nodes are connected and how fast transaction 1 spreads through the mempool, then you may end up with the same result as here, or you may end up with some block explorers seeing transaction 1 and some seeing transaction 2, and a race to see which transaction gets confirmed.

[NeuroticFish]

Question:
I am getting this error message. What does it mean? Validation Error: Error #-26: 258: txn-mempool-conflict

Answer (by JBaczuk):
This error means that you're trying to spend the same transaction output more than once.

More specifically, when you submit a transaction, a check is done (on the node) against the previous outputs of your new transaction to see if they are already trying to be spent by a transaction in the memory pool.

I read it as: mempool already has a valid tx spending the same inputs and that doesn't allow to be replaced. This means a conflict and your new tx is rejected.
It's a fun experiment. And indeed, the outcome is 100% expected. I would have been expecting though that you'd do such experiment(s) on testnet, not on main.

[pooya87]

Tested it!

Read the first post (EDIT).

By the way, you could test things on testnet where things are meant to be tested!
The easiest and cheapest way is to use Electrum. After installation you can just run Electrum using --testnet command line parameter on any OS. You can also find testnet faucets on google to claim some free coins for your tests.
It's pretty much similar for bitcoin core but syncing is time consuming and for small tests it is not worth it.