Quote from: o_e_l_e_o on Today at 10:08:13 AM

Quote from: PrimeNumber7 on Today at 09:10:24 AM

The specific transactions that are included in a candidate block are updated far more frequently than once per second. Miners (specifically mining pools) try to maximize their transaction fee revenue, and will adjust their block candidate accordingly.

Please correct me if I'm wrong, but I can't believe that this is accurate. Are mining pools really sending out a fresh candidate block to all connected miners several times per second? Perhaps the pool coordinator is constantly updating their candidate block with higher paying transactions, but surely they are only broadcasting a new candidate block to miners once every few seconds, or maybe several times per minute? Ideally, they should probably only be broadcasting a new candidate block once their updated candidate block has reached some threshold of a larger fee than the old candidate block currently being worked on.

I would doubt that pools are sending the candidate block header this frequently, however, I don't doubt that pools are updating their candidate block very frequently that they will send out to miners as they are sent new work.

Based on my reading about the stratum protocol, it does appear that miners are sent new work once per minute, or when a new block is found, whichever comes first. This does not mean that all miners mining on the same pool receives new work at the same time. Assuming a one-minute interval of receiving work, one miner may receive work at 12.1 seconds past each minute, another miner may receive work at 33.2 seconds past the minute, etc. When new work is sent, the miner will send the most recent block candidate header.

Quote from: o_e_l_e_o on Today at 11:47:18 AM

I suppose such a question becomes less relevant with Stratum v2, as individual miners will have the ability to select which transactions to include and create their own candidate blocks.

I can see this particular feature preventing pools from adopting v2. Transaction fees make up an increasingly large share of the total mining reward, and the amount that pools payout ultimately depends on how much pools receive in transaction fees. This is even true for pools that payout via PPS, as the PPS rate will depend on the expected amount of transaction fees each block will include. If individual miners can select transactions in blocks they mine, a miner may not select the transactions with the highest fees, or an individual miner may have users pay transaction fees via some method that is not sum(inputs) - sum(outputs).

For example, a large miner might expect to mine 4 blocks per day (1 every 6 hours), and the fee market might require transactions to include a fee rate of 20 sat/vByte. This large miner might have an agreement with a business that needs to send hundreds of not-time-sensitive transactions per day, and the miner might agree to confirm this business' transactions for 15 sat/vByte if paid in advance directly to the miner. The business would provide what appears to be zero-fee transactions to the miner directly, and the miner would include these transactions in blocks they find. This results in the miner receiving a higher payment than he is entitled to, and either the pool or other pool users end up losing out on these transaction fees.

There is also the issue that each individual miner's software will need to be properly configured. If one miner submits an invalid block due to a misconfiguration (intentional or otherwise), the pool will lose out on that mining revenue, but the miner will have received payment for the work that contributed to finding that block. Under the status quo, there is very little that a miner can mess up when submitting work to the pool.