Topic: [TESTED IT] Changing the transaction after broadcasting, what happens? - page 2. (Read 291 times)

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.

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

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.

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.

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


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