so in the first few rounds. they start with empty block.. and start adding more transactions per round.
(much more efficient this way to start with 0tx and add a few every extranonce round)
I'm not sure that's correct.
If they added a few transactions every time they incremented the extraNonce, then we would expect not just to see the occasional empty block, but to also see a not insignificant number of blocks which could have been 100% full but were only 5%, 10%, 15%, 20%, etc., full.
firstly. i was dismissing the fud that pools like viabtc do not own a full node and only have a litewallet to their name'(SPV).. as that FUD is completely factually incorrect.. the myth that pools only own litewallets(SPV) was done so to create some propagandist FUD that pools are dirty, nasty, dangerous to the network (a rhetoric being passed around for the last 7years)
viabtc do have a full node.
what you need to realise is about the timing.
it was much more observable in the past due to slower asics and slower propagation and lack of things like compact blocks and such.. meaning the timing between rounds was more noticeable
its only no longer now the case seeing how pools function behind the scenes because asics have got faster and propagating blocks and transactions has got faster.
(but still happens. as noted this month in example at bottom of this post)
once a pool purges confirmed transactions from its mempool. adding new transactions is a millisecond event. it was never a case of after 2.5mins =35% after 5mins=50%
which you are presuming...
years ago. it was more noticeable that pools start empty. then would add their own few transactions they knew were not in the previous block because because they knew when they received the transactions and validated them to add them to mempool after a certain time
so would add a few transactions before the confirm purge.
(this was especially the case in the days of 'pushtx' services where certain miners collaborated with certain exchanges to get data direct, rather then through the relay network. EG i remember btc china had an exchange and a pool and would give privilege to transactions coming from their exchange)
then in later rounds added more transactions(from the mempool of of transactions stemming from the relay network) after the purge of confirmed transactions found in the recently solved block, which is when they would finally have got to the point of 'full block'
as i already said. it was never a scientific thing of oh 25% full that must mean 2.5minutes. 50%full must mean 5minutes.. (your presumption)
it was more of a 0 full = x seconds. under 100% = x seconds to x minute.. full= x minute+
lets take an example
viabtc
https://www.blockchain.com/btc/block/734379- not full
precedeing this was
https://www.blockchain.com/btc/block/734378 - not full
https://www.blockchain.com/btc/block/734377 - 'full'
as you can see XX78 and xx79 are both solved quickly after previous, but not empty nor full(yep. it happens)
as for the timing. ..from memory of what i was reading ages ago. it was more about the transactions that were included that alluded to when the pool must have added the transactions, due to when they received them would have been similar time to when everyone else received them(at relay before block was collated)
thus guessing that the pool could not have seen certain transactions before X time meaning they could not have started that round before X time.
it was not as you presume X tx count=time
it was more of
time of tx relayed= earliest time the transaction could have been added to a round
..
main emphasis is
1. pools do have full nodes. they dont stupidly have litewallets(spv)
2. empty blocks are due to very very quick solves = VERY GOOD LUCK
3. pools dont just empty block they also partial fill due to efficiency tactics
4. partial and empty blocks are due to efficiency tactics of:
a. trying to hash a new block whilst validating previous
b. adding fresh tx unavailable when previous block was hashing (done before purge)
c.validating, purging and then adding the other transactions.
take the xx79 block
it is presumed to have started at 12 minutes passed the hour and solved at 16 minutes passed the hour
then when you look at the transactions. and where other 'explorers' have tagged the times when they received those transactions. the times of those transactions are not before the 12th minute. and some are also at the 15th and 16th minute. meaning its not like the pool collated all the transactions at the 12 minute and decided it only wanted to put in 715tx at the 12th minute and just churned through many rounds with just that one merkle tree of transactions of 715 from the 12th minute.. but instead in later rounds added more transactions it knew were fresh and not going to be in previous block. because yea, the had transactions of the 15th and 16th minute right up to the point the other explorers got a block solve from that pool at the 16th minute including the transactions of the 15th and 16th minute.
..
and again this is not scientific, because there is another efficiency gain/competition game at play.
using the xxxx79 block for instance. some of the tx's are tagged by many explorers(other nodes on the network) as being relayed at 16th minute. and the block with those transactions included also relayed at the 16th minute. this does not mean the block was solved on a round with a new hash of the header data(merkle tree containing the 16th minute transaction) within seconds of adding it.
instead its probably more likely that the pool got some transactions from itself or other sources at the 12/14th minute. added them to a round in the 12th/15th. but these transactions were not relayed to the rest of the network. and then when the block was solved.. only then released the transactions to the network.
this game is done so that competitors wanting to validate everything. dont have the transactions already validated in their mempool pre block receipt, so the competitors have to request certain transactions they are missing from their mempool from their peers. which then delays the competitor from fully validating and purging to then add a 'full block' because the block solver pool has held them up by not pre-supplying the transactions
