Turn based mining (Concept)

[SapphireSpire]

Turn Based Mining

The List: Every block contains a list of miner payment addresses. A hundred 32 byte addresses is 3.2kibs, or 0.3% of a 1 MIB block. Addresses are added at the bottom and are removed from the top. Every position on the list represent a future block height, so miners know when to mine. 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 for any height other than the one they're scheduled for. That means blocks can never be orphaned and that eliminates the 51% attack.

The Mining Pool: The lottery uses many of the same mechanisms as POS, but is nothing more than a firewall against address spam. When a node wants to mine, they create a transaction with a UTXO flagged for mining. It becomes part of the 'mining pool' as soon as it's confirmed. Miner outputs can be spent at any time. When that transaction is confirmed, the miner's address is removed from the list and excluded from future lottery drawings.

The Lottery: When a miner creates a block, they modify a copy of the list from the previous block. They remove their address from the top, and the addresses of spent miner outputs, and apply a random selection algorithm (RSA) to the mining pool to choose an address for each one removed.

The RSA: The first important property of the RSA is that it always makes the same choice for a given 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. A minimum output size requirement, based on a proportion of the average out size, helps reduce transaction spam.

The RSA nonce: During a miner's turn, the mining pool is static. Since the RSA can only chose one address from that fixed set of inputs, another input value, a nonce, is required to make it possible for the miner to chose more than one address. If the miner's block contains changes to the mining pool, the nonce begins at 1 for the first selection and is incremented by 1 for each additional selection. If the block contains no changes to the mining pool, the nonce must begin with the value from the last block plus one and increment from there.

Pool Support: Miners have the option of 'lending' their output balances to other mining outputs to form a pool. They don't lose control of their coins, it just increases the total for the 'borrowers' output and excludes their address from selection, thereby increasing the borrower's chance of being selected. The borrower must indicate in their output whether or not their block reward should be divided among all the addresses 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.

Difficulty: In competitive mining, the block interval is regulated by a minimum difficulty requirement based on the number of leading zeros in the block hash. In TBM, the list makes this unnecessary. Difficulty is measured by the block hash nonce count rather than the hash size.

Proof of Work: Miners start with a block hash nonce of '1' and work their way up. As they work, they generate a Merkle tree which is binary but, to save space, the leaf nodes are sets of millions, billions, or trillions of block hashes. Each set is hashed on the fly so miners don't need to retain the whole set. It works best with memory hard, ASIC/GPU resistant algorithms that run most efficiently on low speed general purpose hardware. Work can then be verified quickly by recalculating a small random set of Merkle proofs.

Block Reward: The block reward is linearly proportional to the average nonce count of the last hundred blocks and is recalculated for every block. Any amount of work in a block is preferable to none, so there is no minimum difficulty requirement. It's easy for miners to predict their nonce count by multiplying their hash rate in seconds by the standard block interval in seconds.

Turn Timing: By default, a miner's turn ends as soon as they publish a block. That's also when the next miner's turn begins. But if a miner doesn't publish a block, nodes must rely on their local clocks to stopwatch the target block interval. Miners can keep mining beyond the ends of their turns to get a better block reward, but at the risk of losing the window of opportunity. If the first miner at the top of the list in the last block fails to publish their block within their turn time, the second miner on the list can still take his turn.

Placeholder Blocks: The second miner first generates a placeholder block to mine on top of. This block substitutes for the missing block and advances his address to the top of the list and advances the blockchain to his block height. 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.

Finality: 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. The next miner then gets a full turn to mine their block. If more than one block is published in the same turn, the one with the highest nonce count is what counts.

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