|
Title: Timing of new transaction placement in Merkle tree Post by: Oschoir on July 05, 2018, 10:37:25 AM At what point in the mining cycle do new mempool transactions typically get added to the Merkle tree of a candidate block and what variables govern this?
Is a mempool snapshot taken once and then mined until a winner arrives or is found? Or do miners continually add new transactions to the existing block opportunistically? If so is there any impact on the hashing speed due to the re-computation of the header? Maybe there isn't since the CPU can do that, while the ASIC does the mining? I suppose that would be an opportunity to reset the nonce too. I'm sure algo's vary from miner to miner, I'm most interested in BitcoinCore's implementation and other popular systems including es cgminer and bfgminer. Thanks for any insights, I am not a miner, but interested in the effect on the mempool and chances of a new TX getting into the next block. Title: Re: Timing of new transaction placement in Merkle tree Post by: Anycoin Direct Support on July 05, 2018, 07:14:43 PM Hello Oschoir,
There are a lot of different questions you are asking here so we will try to answer most of them. When a miner forms a block he choses transactions based on several factors such as the transaction fee, age of the coin and size of the transaction. All transactions and other related information stored in a block creates a unique blockheader related to these factors. However, every second there are new transactions being added to the mempool. This means the transactions included in the block are also constantly changing leading to a different blockheader as well. On top of this each miner makes their own unique block and miners can choose to add their own transactions. It is important to understand that this does not impact the chance of mining a block since you are trying to calculate the hash of the blockheader. Whether the nonce changes or the included transactions change they have an equal chance of finding the hash below a certain value. With kind regards, The Anycoin Direct team Title: Re: Timing of new transaction placement in Merkle tree Post by: Dr.Z on July 06, 2018, 01:59:43 AM Hello Oschoir, There are a lot of different questions you are asking here so we will try to answer most of them. When a miner forms a block he choses transactions based on several factors such as the transaction fee, age of the coin and size of the transaction. All transactions and other related information stored in a block creates a unique blockheader related to these factors. However, every second there are new transactions being added to the mempool. This means the transactions included in the block are also constantly changing leading to a different blockheader as well. On top of this each miner makes their own unique block and miners can choose to add their own transactions. It is important to understand that this does not impact the chance of mining a block since you are trying to calculate the hash of the blockheader. Whether the nonce changes or the included transactions change they have an equal chance of finding the hash below a certain value. With kind regards, The Anycoin Direct team If the transactions included in the block change during the mining process, when new transaction added in, will the nonce start over from 0, or just keep plus 1. Title: Re: Timing of new transaction placement in Merkle tree Post by: achow101 on July 06, 2018, 04:13:09 AM If the transactions included in the block change during the mining process, when new transaction added in, will the nonce start over from 0, or just keep plus 1. Miners generally only select new transactions after a set of nonces and extranonces has been exhausted. However it depends on the software being used. There is no set order nor is there a set algorithm for the order of things to try.Title: Re: Timing of new transaction placement in Merkle tree Post by: Oschoir on July 12, 2018, 10:20:58 PM Thanks for your replies, much appreciated. I'd imagine that recomputing a Merkle root would be quite fast so wouldn't interrupt the main business of grinding too much. Even though, I'd expect most software implementations to run this in a separate thread on the CPU, leaving the ASICs to get on with the grinding uninterrupted. If the algo decides its time to include a new TX it can prepare the root on the CPU, then pass it over to the ASICs seamlessly. Sound about right?
If so then sounds like it's fair to assume that a new TX with reasonable fee can expect to get into the current block in normal circumstances. |