Bitcoin Forum

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 (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):


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).

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.

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.

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.

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.

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"  ::)

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.

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?



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?

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.

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

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

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.

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 :)

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.

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.

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.

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.

Tested it!

Read the first post (EDIT).

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.

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.

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 (https://bitcoin.stackexchange.com/questions/54986/to-run-bitcoin-core-testnet-on-ubuntu-16-04) but syncing is time consuming and for small tests it is not worth it.

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).

So the difference here is that once transaction A has been confirmed, then the UTXO it is spending gets removed the UTXO set.

When transaction A is in the mempool, and you broadcast transaction B, then you get the error "mempool conflict" since transaction B is valid but is attempting to spend the same UTXO as another transaction in the mempool (transaction A). After transaction A is confirmed and spends that UTXO, then that UTXO is removed from the database that each node keeps of unspent outputs. When transaction B comes along and now tries to spend that output, the node can no longer find it in the data set, and so returns the error that it is missing.

Now, we know how the network works  :)

Your idea ...


... maybe this could cause an unexpected error, because if one node has transaction 1 in their mempool and gets the confirmed block with transaction 2  ???

Maybe some 'experts' here know this?

Correct if we see it from the perspective of someone looking at the blockchain at a later moment where the transaction has already a lot of confirmations.

However, looking at it in "real time", one of both transactions could land in a stale block (popularly known as "orphan"). If a service which accepts 1-conf transactions is that unlucky to be better connected to the miner who mined the stale block than to the one who mines the later "canonical" block, then a double spend attack could succeed.

Thus in theory it would be interesting if someone conducted the same experiment the OP made, but on a continuous basis (e.g. during 24 hours and trying to get included 2 transactions per block) and sending both txes at the same time from different locations (preferrably also geographically on distinct locations, e.g. one on a server in the US and the other in Asia) and see if the outcome matches the "theoretical probability" of this kind of attack to succeed. Of course one could also use Testnet but the outcome wouldn't be that interesting as the network structure of testnet should be drastically different.

Then it simply drops transaction 1.

Whenever a node receives and verifies a new block, it updates its UTXO set, removing all the UTXOs which have been spent and adding all the new UTXOs which have been created. This means that when the node receives a block containing transaction 2, then the UTXO which transaction 1 spends is removed from its UTXO set (since it has just been spent in transaction 2). Transaction 1 therefore becomes invalid, and is dropped from the mempool. No error needed. :)