Bitcoin Forum

Hello all, sorry if this has been answered before but I can't quite find the answer I am looking for. So I am new to running a full node and lately I have been spending time looking at mempool explorer. Watching blocks fill up in real time as they are being mined made me realize that miners are hashing a block that is (potentially) changing every second. Especially when there aren't enough transactions to fill up a block. So does this mean that, say in the case when transactions in the mempool are low, each time a new transaction enters the mempool the miners will stop attempting to hash the old block and start attempting to hash the new block that includes the new transaction? It seems like trying to shoot a moving target would really slow down the process... but I am not a programmer or a developer of any sort  ;)

Also I have noticed a handful of really small blocks that get mined especially fast. Is this just a coincidence that my lizard brain makes a connection, or is there some causality there?

Yes, they could do that. They probably do it, but I'm not sure if that answers to “miners hash a block that is changing every second”. While they mine, they may change various values (despite the nonce) like timestamp, transactions from mempool (which changes the merkle root) etc.

Small like... empty? Probably empty blocks could be solved more easily, due to the fact that there's less information to be hashed each time.

It depends. There is almost practically no penalty to change the merkle hash of the block since miners should be fast enough to include an alternative merkle root as required. The server may request for the workers to change out the merkle root periodically through mining.notify on stratum for example.

Miners can include any transactions as they wish and it is not a necessity for them to discard the current block and include new transactions whenever they see anything.
No. The chances of you getting a valid block is not affected by the number of transactions or the size of the block. It's common for blocks to be mined within a few seconds of each other as some miners either don't include transactions at all after seeing a valid block on the network (to avoid the risk of including conflicting transactions, while they are validating the blocks) or if the miners are just slow at including transactions in the block.

It's the same.

If you put the number of hashes a miner does in a second into perspective it becomes easier to figure things out. A single S19 antminer can compute 95 TH per second. That is 95,000,000,000,000 hashes per second. A block header has a nonce that can go from 0 to 4,294,967,295 that means each time the miner goes through all those nonces it has to change something else (extra nonce in coinbase transaction to run from 0 again). S19 would change extra nonce 22,118 times per second.
So basically at least a transaction in the block is changing which requires changing the merkle root hash and witness merkle root hash. Adding or changing more transactions in that block doesn't add any extra times.

Technically not correct since the miner hashes the fixed length block header (80 bytes) and it won't change whether the block has 1 transaction or thousands.

The miner, indeed, hashes a 80 bytes block header, but to reach the certain merkle root, he has to hash transactions. Hashing transactions may take some time; it may not seem slow in practice, but in theory, doesn't it take more time to hash multiple transactions over and over again, instead of just one?

Oh wow, this sums it up pretty well. I didn't realize the nonce had such a (relatively) small cap. This really helps me understand the difficulty target much better, as there are immense amounts of blocks that cannot be hashed under the difficulty target by only changing the nonce. Thank you for the intuitive reply! Thanks to everyone else who chimed in as well :)

There isn't a lot to hash. Anyways, I don't think ASICs hash merkle root. They only hash the block headers, any CPU can hash the merkle tree in milliseconds so it can be done in parallel.

A lot less than that (micro seconds). For example I was trying to benchmark the time it takes to compute merkle root hash of block 692,400 containing 1,121 Transactions using my own code that doesn't have SIMD and it takes 902.3 μs to do that. With SIMD or a stronger CPU than mine it would take a lot less.
This amount of time is negligible in comparison.

I think this may be a coincidence, as the blocktime isn't necessarily after an empty block

A few months I made a dashboard  (https://bitcoindata.science/blockdata-dashboard.html)with block data . If you click the button "Last Week", you will see that there were 3 empty blocks mined last week:


Except for the first one, the other two had a normal blocktime. And 1 minute is more than enough to add transactions from the mempool into a block.

I think some pools might want to mine empty blocks to try to make fees goes higher, so they will make more money in medium term (this is my guess only, but I think it makes sense)

If those timestamps are based on block headers, then you should notice that timestamps are also used as nonces: they can be incremented or decremented after exhausting nonce inside block header, because in this way there is no need to recalculate merkle root.

UpdateTip at my node shows something different:
So, we see only few seconds difference.

They aren't. You're looking at the timestamp only. The timestamp of a block is almost always inaccurate because the network allows it to deviate significantly. The blocks that you've highlighted are relayed only a few seconds apart.

Miners won't try to artificially inflate fees. Trying to inflate the fees at the current stage won't work, none of the pools hold a significant portion of the network. Intentionally mining empty blocks would result them in losing out more fees in the long run. Fees are fairly demand inelastic right now, so people are more likely to put off making transactions when fees are high.

Keep in mind that because of the way merkle trees work the miner doesn't have to re-compute the whole thing when they are just increment their extra nonce (in coinbase transaction, shown as t1 in the tree below), instead they only compute a smaller part of the tree.
Red parts are changing and recomputed, the green parts are fixed and stored in memory for reuse, the black parts can be discarded or stored similarly in case the miner changed another tx (eg. one with higher fee).

t1    t2    t3    t4    t5    t6    t7    t8
└─────┘     └─────┘     └─────┘     └─────┘
   t1'         t2'         t3'         t4'
   └───────────┘            └───────────┘
         t1''                    t2''
         └────────────────────────┘
                   root

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.

The reason why blocks are sometimes empty immediately after a block is found, is because miners are blindly accepting that a previously found block is valid, and is mining on top of said block prior to confirming which transactions have been confirmed. Once miners validate a recently found block, they will update their database so that their new block candidates will reflect only valid transactions.

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.

They are not sending the whole candidate block, only block header is needed to mine nonce, to use timestamp as a nonce, to use block version as a nonce. Later, updating at least the coinbase transaction is needed (or changing the order of transactions, replacing them with those with higher fees, things like that). From nonce you can get 32 bits. From block version you can get many bits, something around 20 I guess. From timestamp you can get around 10 bits. All of these three fields combined will give you around 64 bits that you can change. Blocks are produced every 10 minutes and they have around 80 bits. That means 64 bits is something around bare minimum you can submit on Stratum, values below that will be useless from pool's perspective.

I'm currently solomining for fun, with my USB ASICs, connected to ckpool. Just hooked up a packet sniffer and I observed roughly a single mining.notify packet from the server once a minute. The server has no requirement for the miner to discard their current work until the nonce is exhausted. List of merkle branches changes every time the packet is sent to my miner. Take it with a grain of salt though, it might be different for various pools. It is possible for pools to enforce a mandatory change in the merkle branch though it would entail a slightly larger bandwidth and having the miners to discard the work that they've done.

Sure, but still? Multiple times per second? Seems a long way off from the once a minute ranochigo is experiencing.

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

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.

That seems far more reasonable.

I'm not so sure. Taking the example you gave - there is a large miner who has reached a private agreement with a third party to include their transactions for a fee paid directly to the miner. This miner is mining for Pool X, and is still sharing their block reward and other fees with Pool X, but is depriving Pool X of the additional private fee they have negotiated with the third party. If Pool X decide this isn't good enough, and stop using Stratum v2, then the miner in question can simply switch to Pool Y which is still using Stratum v2. Pool X have now lost the entirety of that miner's hash power, and with it, all the block rewards and other fees for the blocks they were mining. They will end up in a worse position than if they had just continued to allow Pool X to continue to mine with their private arrangement in place.

Any miner who has such an arrangement and wants to be able to select which transactions they include will just move to a pool which is willing to let them do that, and there will always be some pools which are willing to do that. Any pools which don't upgrade will be left behind by these miners.

A miner who is mining on a pool 'honestly' is providing hashes, the value of each is worth one hash. A miner who is mining on a pool in a way I described in my previous post is providing hashes that are less valuable than the hashes from an 'honest' miner. In your argument, pool X would lose n hashes, but would also not have to payout for n hashes. The value of the hashes the pool looses would be less than the value the pool is no longer paying out.

The pool would have a higher market share by allowing a dishonest miner to continue mining on the pool, but doing so will result in the pool loosing money.

I might compare this scenario to a company with a team of salesmen. If one salesman is dishonest and pockets some payments from customers, the company is going to lose the money as a result of this. The salesman doesn't pocket all of the money from customers, so continuing to employ the employee would result in higher sales revenue compared to if the salesman was fired, but the employee is still causing the company to lose money.

I would also point out that a dishonest miner will result in Pool X being able to distribute less per hash to all other miners, so allowing a dishonest miner to continue this practice will result in honest miners mining elsewhere that don't allow this practice, and can afford to pay more per hash.

The problem with private fees is one of the reasons why I think that Stratum v2 alone will be not enough. Theoretically, skipping pools entirely is possible, if all nodes will create some kind of consensus when splitting block reward between all miners. I can imagine a system where for example 5,000 miners will share their block headers. That would mean 400 kB per block, but after distributing rewards on-chain that headers could be discarded. Probably, revealing more data will be needed, for example by including the whole coinbase transaction and SPV proof for that. Assuming more detailed proof will take 1 kB per share, it would be 5 MB per block. Assuming that all rewards will mature after 100 blocks, it means 500 MB per node. As far as I know, Stratum protocol allows shares up to 2^16 times easier than the network difficulty. If so, it means 64k shares instead of 5k, so around 6.4 GB per node.

Joining hashes can be done by simply calculating (firstHash*secondHash)/(firstHash+secondHash), the first multiplication of two 256-bit values would take 512 bits, then could be divided by some 256-bit value and the result will fill no more than 256 bits, assuming all hashes having at least 16 leading zero bits and no more than 2^16 shares, they will never overflow. During division, results will be always rounded down, so joining hashes in different order should always yield the same values.

In such decentralized system, even if someone will receive fees in some private way, that miner will simply receive lower reward, because each miner will receive a fraction of its own coinbase transaction, so the more fees that miner will include, the more coins that miner will get after dividing that coinbase reward. To calculate miner's income, the value of the coinbase transaction in satoshis could be multiplied by the target, resulting in the easiest possible target that will grant single satoshi. Then, that target could be divided by miner's hash to calculate number of satoshis (if done inside Lightning Network, smaller units like millisatoshis could be used).

Because interacting with all miners may take a lot of resources when proving that all miners are honest and their shares are valid, that system could be implemented on top of the Lightning Network. In this way, mining nodes will have to validate only two blocks per coinbase transaction, reducing space requirements to 8 MB per block (two blocks fully filled with Segwit transactions will take up to 4 MB each). That means around 800 MB per node. Previously mentioned 1 kB proof would work only when transactions could be joined, so that when calculating coinbase reward it won't be needed to reveal the whole block.

More or less correct. The biggest thing out there is the amount of bad info being discussed.

Many / most of the larger pools have many many many nodes. They all should be in agreement. However, due to many things there may be a period of time that some are updating / processing / working on the block that was just found / just having a bad day so they do not agree.

So they work on an empty block. Once whatever agreement conditions are met, usually within seconds, they work on blocks normally.

People like to scream that they are SPV mining or some other crap. Or have misconfigured nodes. And yes some are. And some are just being paranoid.

No matter how you slice it, even at the speed of light and ultra fast CPUs & drives & networks there will be a delay.

Because, more or less, mining 1 block a week with NO FEES is better then orphaning 1 block every 2 years because that 1 node was having a bit of a slowdown and missed something.

Now some people will chime in that they can have their node validate in under 2 seconds or some crap like that. Yeah, so can mine. But if I have 20 farms each with 2 nodes that all talk back to 2 or 3 servers that make sure that they all agree that then talk back to all the farms. It's going to take a bit. For a small miner that finds blocks once a month it's one thing. For one that is mining 10 blocks a day it's another.

-Dave

Given a scenario in which a miner has sufficient hashrate to expect to mine 4 blocks per day, average tx fees of 0.05 per block, and a 3% pool fee to cover things such as orphans, and other expenses:
If a miner receives all the transaction fees in the blocks it finds privately, they will receive:
0.2 BTC in transaction fees privately
25 BTC in block subsidies via the pool
0.2 BTC in transaction fees via the pool
-0.756 BTC in pools fees paid to the pool (to be deducted from the amounts received via the pool)

The pool will receive 25 BTC in block subsidies, but will payout 25.2 BTC to the miner. The extra .2 BTC will ultimately come from the other pool users when the pool lowers the amount it pays per hash.

I don't see any reason why a miner would work on an empty block (assuming the mempool is not empty), other than that the miner has recently received a new block and is not yet sure which transactions are valid. Even if a pool has fully validated a block they are now mining on top of, before constructing a block with transactions, they will need to update their list of unspent outputs and compare this to inputs in unconfirmed transactions. So even if a miner is not SPV mining, there will still be a period of time in which they are mining an empty block.

I believe that most pools probably have direct connections to other major pools in which the pools send newly found blocks directly to eachother so they can save seconds in the time it takes for a block to propagate so the pool can start working on a new block earlier. I don't doubt that pools also have multiple other nodes that are not publicly known so to prevent the pool from being the subject of a sybil attack, or not receiving a block because a miner did not send said block via this private network.

The only reason why two nodes would not be in agreement is if one node received a block but another did not. It would not make sense to mine an empty block if you are not mining on top of a newly found block because you have already validated that the previous block was valid.

Remember dozens of farms and mining nodes spread out all over. You really want them to be in sync. Mostly because they are paying PPS.
Keep in mind in a PPLNS pool an orphan sucks but it costs the pool their fee and not much more.

For the big Chinese pools that tend to put out the most 0 transaction blocks, their miners are PPS so if the pool looses a block it costs them money because the miners get paid no matter what.

So you submit the block with 0 transactions and get the BTC because not doing it costs you money.

-Dave 

Think about why two nodes belonging to a miner might be out of sync.

One possibility is that one node thinks the most recent block is 692827, and this block's hash is 0000000000000000000aa...5d17c6d2 while another node thinks the most recent block is 692827 and that block's hash is 0000...c5d17d6f3. Assuming both blocks are valid, the miner would need to make a decision as to which block they are going to mine on top of, and assuming each block has a different set of transactions, including zero transactions in a block on top of either block will not prevent any new block from being invalid.

Another possibility is that one node thinks the most recent block is 692827, and this block's hash is 0000000000000000000aa...5d17c6d2 while another node thinks the most recent block is 692826 and that block's hash is 000000000000000000011...0025b5c48. If this was the case, one of the nodes simply has not yet received block 692827, and assuming the miner can trust the block is valid, it can mine on top of it with transactions if it has updated its list of unspent outputs. If the miner were to start mining an empty block in this scenario, it would need to choose which block to mine on top of -- mining on top of 826 would likely result in an orphaned block, while mining on top of 827 would result in the block being accepted provided it is otherwise valid and is propagated prior to any other miner propagating their own block on top of 827.

In both scenarios, the miner does not actually reduce the risk of having their found block be invalid. If anything, a miner with two nodes can start mining on top of a newly found block more quickly, as it can start doing so once the node receives (and validates) a block.

The only scenario in which mining an empty block would be +EV would be if the miner has received a new block, and has not yet updated their list of unspent outputs, so it cannot know which transactions are valid that can be included in a new block. One might also argue that mining an empty block would be +EV if the transaction fees are very low, but that is not the case currently. I noted above that a miner might validate a block prior to updating the unspent output table to allow it to start mining on top of a new block more quickly, so mining an empty block does not necessarily mean it is SPV mining.