Topic: [TESTED IT] Changing the transaction after broadcasting, what happens? (Read 297 times)

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.

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.

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?

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.

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

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.

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.

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.

Tested it!

Read the first post (EDIT).

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.

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.

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.

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.

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

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.

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

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, 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?

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.

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"