Bitcoin Forum
May 01, 2024, 09:39:40 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: [TESTED IT] Changing the transaction after broadcasting, what happens?  (Read 252 times)
mynonce (OP)
Full Member
***
Offline Offline

Activity: 233
Merit: 253


View Profile
May 04, 2022, 10:30:30 AM
 #21

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).
1714556380
Hero Member
*
Offline Offline

Posts: 1714556380

View Profile Personal Message (Offline)

Ignore
1714556380
Reply with quote  #2

1714556380
Report to moderator
1714556380
Hero Member
*
Offline Offline

Posts: 1714556380

View Profile Personal Message (Offline)

Ignore
1714556380
Reply with quote  #2

1714556380
Report to moderator
1714556380
Hero Member
*
Offline Offline

Posts: 1714556380

View Profile Personal Message (Offline)

Ignore
1714556380
Reply with quote  #2

1714556380
Report to moderator
TalkImg was created especially for hosting images on bitcointalk.org: try it next time you want to post an image
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
o_e_l_e_o
In memoriam
Legendary
*
Offline Offline

Activity: 2268
Merit: 18509


View Profile
May 04, 2022, 12:23:42 PM
 #22

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.
mynonce (OP)
Full Member
***
Offline Offline

Activity: 233
Merit: 253


View Profile
May 04, 2022, 05:51:00 PM
 #23

Now, we know how the network works  Smiley

Your idea ...

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

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

Maybe some 'experts' here know this?
d5000
Legendary
*
Offline Offline

Activity: 3892
Merit: 6140


Decentralization Maximalist


View Profile
May 04, 2022, 05:51:55 PM
 #24

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

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
o_e_l_e_o
In memoriam
Legendary
*
Offline Offline

Activity: 2268
Merit: 18509


View Profile
May 04, 2022, 07:15:54 PM
 #25

... 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  Huh
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. Smiley
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!