in any case, anything around 6 usd cents or lower is still profitable. until halving, then no one knows :O
you will never know that, that is quite literally THE most coveted information from any miner out there.
why? because then other miners will come and mess around with the supply (assuming it's on-grid) thus raising the cost of the og miner. miners are always competing against each other, we gotta have an edge ya feel me
21 sats \ 0 replies \ @bitentrepreneur 16 Feb \ parent \ on: What are you working on this week? builders
gracias amigo
working on launching the ability for miners across the globe to make their own block templates and add whatever transaction they want in order to bring more decentralization to mining, ya'know
i see what you mean. i am always trying to question my own beliefs and am vigilant in any complacency of my ideas or knowledge.
so to answer your question, yes it is possible to always have another block template available, one that does not depend on the transactions confirmed (or not!) in the previous block.
available in stratumv2 pools that allow for block template creation + tx sets
Future Jobs
An empty future block job or speculated non-empty job can be sent in advance to speedup new mining job distribution. The point is that the mining server MAY have precomputed such a job and is able to pre-distribute it for all active channels. The only missing information to start to mine on the new block is the new prevhash. This information can be provided independently.
Such an approach improves the efficiency of the protocol where the upstream node does not waste precious time immediately after a new block is found in the network.
Sv2 separates mining prevhash and future job, vs the combined message in Sv1 which forces pools to send empty blocks to communicate a prevhash. Sv2 pools can send jobs to workers ahead of time for future blocks, even before the prior block has been found. Pools send the latest prevhash in a space opitimized message, starting the end-device mining on the next block in a single 32-byte message.
this is because stratum v1 pools send empty blocks containing the new prevhash, as this arrives faster than a message containing a full block.
oh and the fix is already here, with stratumv2. sv2 pools eliminate the empty block incentive by making full-block propagation equally efficient to empty block propagation