Turn based mining (Concept)

[SapphireSpire]

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.

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.

Difficulty: In most, if not all, proof of work protocols, the block interval is governed by the minimum difficulty requirement, where difficulty is measured by the number of leading '0' in the block hash. But this is not an accurate measure of work or time because the distribution of hash values between blocks is highly inconsistent. A more accurate measure of work and time is the nonce itself. It counts precisely the number of times the miner executed the hash algorithm. The hash value is irrelevant.

Proof of Work: A minimum nonce count alone would be easy for miners to circumvent. They would just run the hash once at that value instead of starting at '1' and working through the required range. To prove that the required work was done, miners must generate a Merkle tree from the block hashes they generate. Normally, the leaves of a Merkle tree are paired to produce sibling hashes, but mining algorithms grind through far too many hashes for them to be paired. Instead, hashes are grouped into sets of millions, billions, or trillions for each sibling hash. Work can then be verified quickly by recalculating a small random number of sets and matching them to the corresponding branches of the Merkle tree.

Decentralization: Every position on the list represent a specific block height. Miners cannot produce blocks for any height other than the one they're scheduled for. For example, if a miner produces a block to orphan the last block, or if they produce a chain of blocks to orphan the tip of the blockchain, even if they have a higher difficulty, it won't count because their address was not on the lists for 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 hit the minimum nonce count and leave it at that, or they can keep mining for the rest of their turn for a better block reward. They can mine through other turns too, but at the risk of losing the window of opportunity.

Pools: Miners have the option of 'lending' their output balances to another mining output, forming a pool. They don't lose control of their coins, it just increases the total for the other output and excludes their address from selection, thereby increasing the 'borrowers' chance of being selected. The borrowing miner must indicate in their output whether or not their block reward should be divided among all the address in the pool in proportion to the amounts lent. If it's just a lottery pool, it should. If it's a mining pool in which miners are contributing work, compensation is more complex and should be handled independently, therefore no.

Placeholder Blocks: If the first miner at the top of the list in the last block fails to mine a block within their turn, the second miner on the list can still take his turn. This prevents DOS attacks and ensures that miners aren't delayed by slow or unresponsive nodes. Before the second miner can mine a block, he 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. Placeholder blocks 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 creates a placeholder block on top of the last and starts mining on top of it. 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.

[gmaxwell]

I mine. I ignore announcements of anyone elses address. I just generate more of my own addresses to keep adding.  After a little time only I can mine.  All your blocks are belong to me.

If "announce stuff" was sufficient for this there wouldn't need to be a blockchain at all.

[SapphireSpire]

I ignore announcements of anyone elses address.

Addresses are staked to the pool, and you have to add all the addresses that are in the pool when you create your block or it's invalid.

I just generate more of my own addresses to keep adding.

There's nothing wrong with adding your own addresses, as long as they're in the pool. POS replaces the incentive to spam with the incentive to concentrate your stake behind a single address. The more addresses you stake at once, the smaller each stake will be and the less likely any of them will ever go to the pool.

[gmaxwell]

You can't become a miner unless your address is first added to the list by another miner.

Exactly. I am existing miner only add my own addresses and lock out all others.  No one else can tell these other addresses are also me.

[God Of Thunder]

Because of the recent development, I think more people are thinking about a possible 51% attack. People might think that if it is possible to do a 51% attack on the XMR blockchain network, it would be possible on the Bitcoin blockchain network as well. But as we know, this is not going to be so easy. Whoever plans for it knows better than some people like me who don't have much knowledge about it.

It will be too expensive to operate a 51% attack on the Bitcoin blockchain. But is it doable? What if some companies together want to spend a huge money to test it? I assume the entire crypto market will collapse if something like this happens.

[HeRetiK]

Because of the recent development, I think more people are thinking about a possible 51% attack. People might think that if it is possible to do a 51% attack on the XMR blockchain network, it would be possible on the Bitcoin blockchain network as well. But as we know, this is not going to be so easy. Whoever plans for it knows better than some people like me who don't have much knowledge about it.

It will be too expensive to operate a 51% attack on the Bitcoin blockchain. But is it doable? What if some companies together want to spend a huge money to test it? I assume the entire crypto market will collapse if something like this happens.

I wasn't aware of Monero's current situation and I'm fascinated that explicitely going for CPU mining over ASIC mining wasn't enough to protect their network from centralization. Funnily enough requiring ASICs makes a 51% attack more costly, given that in a situation of complete market obliteration a CPU mining attacker could reuse/resell their hardware for other purposes whereas an ASIC mining attacker would be left with a pile of worthless bricks.

[ABCbits]

If a miner takes too long, more than a single block interval, the second address is free to compete with the first address in the next block interval. Each block interval is a turn. If they both fail to produce a block in the second turn, the third address on the list is free to compete in the third turn. The pattern continues until a block is found. When a block is found, the next turn goes to the address after the one who produced the last block. For example, if the second address finds a block in the third turn, the next turn goes to the third address.

Are you aware of (estimated) average time between block[1]? How do you handle the fact that each node may have slightly different date/time?

Because of the recent development, I think more people are thinking about a possible 51% attack. People might think that if it is possible to do a 51% attack on the XMR blockchain network, it would be possible on the Bitcoin blockchain network as well. But as we know, this is not going to be so easy. Whoever plans for it knows better than some people like me who don't have much knowledge about it.

It will be too expensive to operate a 51% attack on the Bitcoin blockchain. But is it doable? What if some companies together want to spend a huge money to test it? I assume the entire crypto market will collapse if something like this happens.

It's known FUD, qubic (the malicious group) never had 51% hashrate. According to BitMEX[2], they actually perform 6 block re-org with lower hashrate percentage.

[1] https://blockchair.com/bitcoin/charts/average-block-interval
[2] https://x.com/BitMEXResearch/status/1955254320305217726

[God Of Thunder]

I wasn't aware of Monero's current situation and I'm fascinated that explicitely going for CPU mining over ASIC mining wasn't enough to protect their network from centralization. Funnily enough requiring ASICs makes a 51% attack more costly, given that in a situation of complete market obliteration a CPU mining attacker could reuse/resell their hardware for other purposes whereas an ASIC mining attacker would be left with a pile of worthless bricks.

This is probably why I think no one would dare to do the attack. But recent developments actually give us a hint that it's not impossible if someone wants to spend billions of dollars on it. As Qubik said, they have no intention of taking over the Monero network and manipulating it, but they did it for testing purposes and wanted to prove that it's actually possible.

Do I think the IOTA co-founder would dare to do it? Nope. I don't think he would plan something like this, as it would be very expensive for him. But we never know, there are a lot of stupid people who could be interested in wasting their money.

[SapphireSpire]

Are you aware of (estimated) average time between block[1]? How do you handle the fact that each node may have slightly different date/time?
https://blockchair.com/bitcoin/charts/average-block-interval

Average time between blocks is just that, it approximates the target block interval.

Dedicated full-time miners tend to have the best internet connections and, with a good communications protocol, like QUIC, used by Solona, they can keep themselves synced in milliseconds. They will give each other a few seconds of tolerance, but they will know when blocks are too soon or too late and make every effort to avoid ambiguity.

[God Of Thunder]

It's known FUD, qubic (the malicious group) never had 51% hashrate. According to BitMEX[2], they actually perform 6 block re-org with lower hashrate percentage.

[1] https://blockchair.com/bitcoin/charts/average-block-interval
[2] https://x.com/BitMEXResearch/status/1955254320305217726

Have you read the recent articles from other media? I checked an article from Coindesk, which is this: https://www.coindesk.com/business/2025/08/12/monero-s-51-attack-problem-inside-qubic-s-controversial-network-takeover. They also quoted Qubit's claims. So, I don't really understand who to trust at this point. Also, the XMR price has fluctuated due to this.

I think you should take a look at this news and share your opinion about it. You cannot just deny saying it's a FUD. Something similar happened with the ETC and Bitcoin Gold in the past. So, I don't want to deny it just saying it's a FUD.

[ABCbits]

Are you aware of (estimated) average time between block[1]? How do you handle the fact that each node may have slightly different date/time?
https://blockchair.com/bitcoin/charts/average-block-interval

Average time between blocks is just that, it approximates the target block interval.

I think you missed my point. Using Bitcoin as example, there are few occurrence when time between 2 blocks is far higher than 10 minute interval. The worst one i know is between block 679785[1] and 679786[2].

Dedicated full-time miners tend to have the best internet connections and, with a good communications protocol, like QUIC, used by Solona, they can keep themselves synced in milliseconds. They will give each other a few seconds of tolerance, but they will know when blocks are too soon or too late and make every effort to avoid ambiguity.

Fair point. Although with how most miners simply connect to pool, they only ensure their internet is reliable enough to communicate to pool with low latency to send/receive work that have rather small size.

It's known FUD, qubic (the malicious group) never had 51% hashrate. According to BitMEX[2], they actually perform 6 block re-org with lower hashrate percentage.

[1] https://blockchair.com/bitcoin/charts/average-block-interval
[2] https://x.com/BitMEXResearch/status/1955254320305217726

Have you read the recent articles from other media? I checked an article from Coindesk, which is this: https://www.coindesk.com/business/2025/08/12/monero-s-51-attack-problem-inside-qubic-s-controversial-network-takeover. They also quoted Qubit's claims. So, I don't really understand who to trust at this point. Also, the XMR price has fluctuated due to this.

I think you should take a look at this news and share your opinion about it. You cannot just deny saying it's a FUD. Something similar happened with the ETC and Bitcoin Gold in the past. So, I don't want to deny it just saying it's a FUD.

I actually have read news and some analysis that before i write my previous reply. Aside from brief analysis from BitMEX research that i already mentioned[3], one of blockchain developer shared both analysis and some data that Qubic is unlikely to had more than 35% hashrate[4].

[1] https://mempool.space/block/0000000000000000000b975fedb1fe62e271bd20d1fa74d2fe28dcfac6f761f3
[2] https://mempool.space/block/0000000000000000000b5d9bcbd38c64e5a39bf4073f7a94348c1336618957ae
[3] https://x.com/BitMEXResearch/status/1955254320305217726
[4] https://shai-deshe.gitbook.io/parallel-thoughts/proof-of-work/the-qubic-minority-report

[mikeywith]

I think you missed my point. Using Bitcoin as example, there are few occurrence when time between 2 blocks is far higher than 10 minute interval. The worst one i know is between block 679785[1] and 679786[2].

That's ~2 hours difference. You may want to check block 74638, nearly 7 hours.

You can use (CDF) - exponential distribution to determine the time between blocks (don't use Poisson distribution for this purpose). below is a simple pyton code that does that for you

Code:

import math

def percent_blocks_separated_by_more_than(minutes):
   
    mean = 10
    rate = 1 / mean
    percentage = math.exp(-rate * minutes) * 100
    return percentage


minutes = 60 # Example: 60 mins
result = percent_blocks_separated_by_more_than(minutes)
print(f"{result:.3f}% of blocks are separated by more than {minutes} minutes.")

A random example > 0.248% of blocks are separated by more than 60 mins.

Forking and orphaning are natural  consequences of competitive mining.

Nah, they are not; maximizing profitability is the only "natural consequences of competitive mining" and you can't make more profit by forking the network and rendering it worthless, as opposed to just play fair,  a 51% attack on btc for profit is never going to happen, owning 50% or even half of that means you have tens of billions of dollars at stake, nobody with that amount of money is going to attempt to damage the network, the only thread would be goverments doing it just to damage BTC, but those don't have to go that far, just ban BTC and threaten to send everyone who uses it to jail. My take on this is that BTC has grown too large that everyone, including governments, has only two ways to deal with it.

1- Be part of the game and attempt to profit.
2- Regulate the market to keep it under control.

[gmaxwell]

And the inconsistent gaps between blocks aren't a flaw or negative, they're absolutely fundamental to the consensus process converging at all.

To illustrate, here is a toy example: lets imagine that instead bitcoin worked such that a miner always finds a block exactly 20 minutes after the last one they found.   Imagine there are two miners and their finds are well spaced so the network is finding blocks every 10 minutes and it all seems fine.   But then there is a disruption and one miner goes offline for a bit,  and after that they're both finding blocks just 10 milliseconds apart. But the network delay between the two parties is 80ms, so they always see their own block first.  This system will never converge again! both miners split into their own chains.

The fact that mining is a possion process is what makes mining eventually converge.  Miners might happen to find blocks very close togeather in time, faster than their propagation and processing time, such that they're tied.  It might even happen that they're 'tied' for multiple blocks.  But eventually someone gets very lucky relative to someone else, the tie is broken, and one chain wins out.

Another issue with the kind of issue with the idea in this thread, -- far less substantial than the fact that the whole thing doesn't work and would just allow a total network takeover-- is that the miner's who _can't_ mine next can't honestly participate and so their economically best move may be to just go try to mine another fork of the chain back from a prior point where they could participate. Imagine that their power is very cheap or free and their costs are mostly centered in their now-idle mining hardware.  They're going to want to put it to use somehow, and if they can't use it honestly some may attack.  Not a good incentive!

[BattleDog]

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.