Turn-based mining concept

So, competitive mining has its perks but comes with serious downsides. There’s no time limit, just a floor for difficulty. Block production can be all over the place, but over time and a lot of blocks, it averages out. When someone finds a block, all the effort on the other blocks is basically wasted, and only the lucky miner who found it gets the full reward. That's part of why competitive mining is so inefficient, and why many opt for pool mining. But pooling all that hash power can let the pool operator mess with the system and pull off a double spend attack. Now, turn-based mining isn't up and running yet, but once it is, it could blow competitive mining out of the water. Instead of a minimum difficulty, it just has a time limit. You’re only working on one block at a time, so way less is wasted. Miners get to dig into their own blocks and earn rewards based on their contribution. No one’s fighting to create the same block, so no issues with orphaned blocks or the risk of a 51% attack. The catch is that proof of work only settles disputes between blocks created in the same turn, while timing deals with conflicts across turns and can override proof of work. Timing is super important, but latency can mess with the time order and cause desync. The best idea I've seen to fix this is syncing node clocks using quantum entanglement, but we’re not there yet with quantum networking. 1. The List 2. The Ticket Pool 3. The Lottery 4. The RSA 5. The RSA Nonce 6. Lender Tickets 7. Definitions 8. Proof of Work 9. Block Signatures a. Block Reward b. Turn Timing c. Dead Blocks d. Finality 1. The List: Ev

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.

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.

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.

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? 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

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.

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

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 A random example > 0.248% of blocks are separated by more than 60 mins. 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.

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!

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.