Cooperation: Competition is a good thing. It compels entities to work harder and do a better job. However, cooperation is also a good thing. Competition is adversarial behavior, which can be destructive, which is undesirable at any time and place where entities are better off cooperating. And that's the problem with competitive mining. The benefits gained from competition fall far short of the benefits that can be gained from cooperation, and that's why everybody's mining for pools. If enough hash power is concentrated in a pool, the pool operator gets the opportunity to conduct a successful double spend attack by orphaning blocks. POW should be cooperative by default.
The List: Competitive mining is essentially parallel computing. The opposite of parallel computing is sequential computing, which means taking turns. For turn-based mining to work, miners need to know when to mine. They need to follow a schedule. The schedule can take the form of a simple list, and the miner's identities are their payment addresses. Every block contains a copy of the list. A hundred 32 byte addresses is 3.2kibs, or 0.3% of a 1 MIB block, and spans a few hours. Addresses are added at the bottom and are removed from the top. When an address reaches the top of the list in the last block, it's that miner's turn to mine the next block.
Decentralization: Miners cannot produce blocks out of turn. For example, if a miner produces a block that competes with the last block, or if they produce a chain of blocks that compete with a bunch of previous blocks, even if it has a higher difficulty, it won't count because their address is not at the top of the lists in the blocks before those blocks. That eliminates the 51% attack. The opportunity to mine is no longer based on hash power, but we still want to encourage miners to mine as fast as possible because that's how POW secures the blockchain.
A Scaling Block Reward: To encourage miners to mine as fast as possible, the base block reward scales up with the difficulty of their block beyond the minimum. Miners can mine until they find a block with minimum difficulty and leave it at that, or they can keep mining for the rest of their turn with the hope of finding a better block. They also have the option of mining into other turns, however, the block reward scales down with each turn and the risk of losing to competition increases (see below).
The Mining Pool: When a node wants to mine, they create a transaction with a UTXO flagged for mining. It gets processed like any other transaction and becomes part of the mining pool when it's confirmed in a block. All mining outputs in the blockchain constitute the "mining pool". Miner outputs can be spent at any time. When these transactions are confirmed, the miner addresses are removed from the list and excluded from future drawings. A minimum output size requirement limits transaction spam.
The Lottery: When a miner creates a block, they modify a copy of the list from the previous block by removing their address from the top, plus addresses from spent outputs, and apply a random selection algorithm (RSA) to the mining pool to choose an address for each one removed. The algorithm combines the mining pool data with a nonce as inputs and outputs an address. The nonce is included in the block header and functions as a counter. It's carried from block to block and is incremented by 1 every time an address is selected.
Properties of the RSA: The first important property of the random selection algorithm is that it always makes the same choice for any specific set of inputs. This makes it possible to verify that every address added to the list was chosen by the algorithm, not the miner. The second important property is that address selection changes unpredictably as the inputs change. The third important property is that the outcome is weighted by the size and age of the miner outputs, thereby creating demand for coins and driving the price up. This also helps limit transaction spam.
Limited Competition: Every position on the list represent a future block height. If the first miner at the top of the list in the last block fails to mine a block within the block interval, the second miner on the list is free to take his turn, in competition with the first. This prevents DOS attacks and ensures that miners aren't delayed by slow or unresponsive nodes.
Placeholder Blocks: Before the second miner can mine a block, they must first generate a placeholder block to mine on top of. This block substitutes for the missing block and advances the list and the blockchain and marks the transition between turns. But they are temporary and subject to change until a real block is found. They contain no transaction data other than a coinbase transaction, which contains one output with the absent miner's address and no coins. No POW is applied, so placeholder blocks take little time to produce and aren't counted by the difficulty adjustment algorithm.
If the second miner then fails to mine a block in the second turn, the third miner on the list is free to take his turn, competing with the first two, and he creates a placeholder block on top of the last one. Competition escalates this way with each turn until someone finds a block. When a block is found, it replaces the placeholder block at the same height, makes the ones before it permanent, and removes the ones after.
Cool idea and good write-up. What you are really describing is scheduled leader election. Once miners join a list with UTXOs and you weight by size/age, you are in Proof-of-Stake territory. That is fine, but the security model changes a lot.
The roster must be derived only from finalized chain state. If registrations in the latest blocks change the list, different nodes will pick different leaders after a reorg and you get permanent forks. Freeze the participant set per epoch and only let it update next epoch. If the next leader can influence the nonce that seeds your lottery, they can grind it. Use an unbiased beacon (VRF outputs committed in the prior epoch, maybe mixed with a VDF) so no single leader can skew selection.
Scheduled leaders can be knocked offline or censored. Your placeholder trick helps, but an async network will still see competing blocks. You need a fork-choice rule (e.g., chain density/longest-chain variant) and a fallback like k leaders per slot. Weighting by coin size/age encourages large holders and list-spamming. Require bonded stake with lockup, minimum duration, and define penalties for equivocation. Without slashing, scheduled leaders can publish conflicting blocks at no cost.
Excluding placeholders from difficulty adjustment invites timing games. Define how timestamps, difficulty, and placeholders interact so nobody can stretch or compress epochs. A central list operator cannot exist. Make the list, weighting, and randomness fully verifiable from chain data, or miners will just delegate to a coordinator again.
If your goal is turn-based cooperation, look at slot/epoch designs from Ouroboros/Algorand/SnowWhite and borrow: stake registration epochs, VRF leader election, fork-choice, and slashing for double blocks. If you want to reduce PoW pool centralization without changing security assumptions, p2pool and Stratum v2 job negotiation are the boring, proven levers.