Bitcoin Forum
October 01, 2022, 03:28:35 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Where does the transaction not successfully mined go to?  (Read 167 times)
Zaguru12 (OP)
Newbie
*
Offline Offline

Activity: 26
Merit: 47


View Profile
June 25, 2022, 08:34:20 AM
Merited by NotATether (5), Welsh (4), o_e_l_e_o (4), Davidvictorson (2), Hyphen(-) (2), Freeveto (2), ETFbitcoin (1), DdmrDdmr (1)
 #1

Memory pool is said to be the temporary storage where transaction is stored before been transfer to the candidate block.

The candidate block of a node is where transaction from memory pool are kept before there been mined into the blockchain

Reading through transactions in a memory pool and candidates block I got little confuse with this questions

1. Can a transaction ID in a block be the Same  before been spent, Or if the outputs of that transaction becomes fully can its ID be reused for a new transaction.

2. Does a memory pool gets full? Then what happens to the unconfirmed transaction, where do they go to?

3. In the candidate's block what happens to the transactions that where not successfully mined do they still remained there

Sorry if this questions have been answered before
1664638115
Hero Member
*
Offline Offline

Posts: 1664638115

View Profile Personal Message (Offline)

Ignore
1664638115
Reply with quote  #2

1664638115
Report to moderator
1664638115
Hero Member
*
Offline Offline

Posts: 1664638115

View Profile Personal Message (Offline)

Ignore
1664638115
Reply with quote  #2

1664638115
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
hosseinimr93
Legendary
*
Offline Offline

Activity: 1806
Merit: 2835



View Profile
June 25, 2022, 09:08:32 AM
Merited by Welsh (4), pooya87 (2), ETFbitcoin (2), Charles-Tim (1)
 #2

1. Can a transaction ID in a block be the Same  before been spent, Or if the outputs of that transaction becomes fully can its ID be reused for a new transaction.
If all outputs of a transaction have been spent, (in theory) it's possible that a new transaction with the same ID is included in the blockchain. In practice, that's very very unlikely.
If there's a non-spent output in a transaction, even in theory it's impossible that a new transaction with the same ID is included in the blockchain. According to BIP30, a block can't include a transaction with the same ID as a not-fully-spent transaction.


2. Does a memory pool gets full? Then what happens to the unconfirmed transaction, where do they go to?
Yes. By default the mempool size is 300 MB. (A node can have a different setting.)
If the mempool reaches that capacity, the node has to remove the transactions paying low fee, so transactions paying higher fee can enter the mempool.


3. In the candidate's block what happens to the transactions that where not successfully mined do they still remained there
In every new block, some transactions are included in the blockchain. Other transactions stay in the mempool and wait for next blocks.

o_e_l_e_o
Legendary
*
Offline Offline

Activity: 1792
Merit: 12335


Slava Ukraini


View Profile
June 25, 2022, 11:02:30 AM
Merited by hosseinimr93 (1)
 #3

3. In the candidate's block what happens to the transactions that where not successfully mined do they still remained there
Your other questions have been well answered above, but it sounds from this like you have a misunderstanding about candidate blocks.

Firstly, a candidate block is either mined, or it isn't. It is never the case that part of a candidate block is mined and part of it isn't.
Secondly, every miner or mining pool constructs their own candidate block which they attempt to mine. Think of it as a template. Once a miner is successful, then their candidate block is added to the blockchain. Every other miner then has to abandon the candidate block they were working on a create a new one. This is because each candidate block must contain a specific piece of data from the last block that was mined, which is how we keep blocks in the correct order.
Thirdly, when a miner creates a candidate block, they do not remove any transactions from their mempool. They simply pick the ones they want to try to include and copy them over in to their candidate block. If they have to abandon their candidate block because another miner was successful, then all the transactions which were in their candidate block will still exist in their mempool until they update their mempool with the information from the other miner's block.

ETFbitcoin
Legendary
*
Offline Offline

Activity: 2282
Merit: 4989


PNNV.COM Live bitcoin price monitor


View Profile
June 25, 2022, 12:17:39 PM
Merited by hosseinimr93 (2)
 #4

2. Does a memory pool gets full? Then what happens to the unconfirmed transaction, where do they go to?
Yes. By default the mempool size is 300 MB. (A node can have a different setting.)

Take note 300MB refer to RAM usage. Transaction size on RAM is bigger than on disk since the transaction is de-serialized and contain additional information (e.g. RBF flag). At the moment i open https://mempool.space/, it reports 23MB memory usage although total size of the unconfirmation transaction is only 7.8 vMB.

NotATether
Legendary
*
Online Online

Activity: 1008
Merit: 4036


Defend Bitcoin and its PoW: bitcoincleanup.com


View Profile WWW
June 25, 2022, 01:47:22 PM
 #5

1. Can a transaction ID in a block be the Same  before been spent, Or if the outputs of that transaction becomes fully can its ID be reused for a new transaction.

No, two transactions must never share the same ID. It is the only identififier that can be used to differentiate between two transactions. Fortunately, the ID is generated with a cryptographic hash from the raw transaction, so this case will never happen in practice.

o_e_l_e_o
Legendary
*
Offline Offline

Activity: 1792
Merit: 12335


Slava Ukraini


View Profile
June 25, 2022, 02:01:08 PM
Merited by ETFbitcoin (1)
 #6

No, two transactions must never share the same ID. It is the only identififier that can be used to differentiate between two transactions. Fortunately, the ID is generated with a cryptographic hash from the raw transaction, so this case will never happen in practice.
No, hosseinimr93 is right with his reply above.

Two transactions cannot share the same ID if the original transaction is not yet fully spent. In other words, if a transaction currently exists which has at least one unspent output, then no new transaction can share its transaction ID. However, once all the outputs of a transaction are spent, and so no outputs from that transaction remain in the UTXO set, then a second transaction can indeed reuse that same transaction ID.

This distinction is important, because without it, pruned nodes could not exist. If the stipulation was that any new transaction cannot share the ID of any previous transaction, then every node must keep a record of every previous transaction, and so could not be pruned. However, with the wording of BIP30, which allows transaction IDs to be reused once fully spent, then pruned nodes do not need to keep a record of all previous transactions, and indeed only need to keep a record of the UTXO set, which they do anyway.

Pages: [1]
  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!