Problem are dependent chains of TX-es which would also become reset and make a mess. Same holds for coinbase outputs which is why they have maturity… so that opcode should also be limited to accessing blocks that have matured, and it could be made more useful:
I have already solved this problem.
It is easily solved by deciding the result of the lottery later, not in the same block.
100 blocks delay, like the miner payout delay, would be probably best.
1 Like
yup, I say the same in the other topic 
I had an epiphany about using block headers as entropy source: not all blocks are “worth” the same. Consensus forces blocks to meet the minimum target (hash must be at least this low of a number), but it’s all subject to variance: some blocks will happen to meet it near the edge, some blocks will be 10x or even 100x away from the target. What if lottery requires a much harder block to be the one that sets the RNG?
100x.
This means lottery can be resolved only when such a block happens to land (once every 100 blocks, but it could take 200 or 300 blocks – variance!), but for e.g. a weekly lottery this is enough. Basically, the higher value the lottery manages, the less often you could safely pick winners.
So a first block lands, lottery contract settles, can some other miner replace the RNG? He’d need to mine at 100x difficulty!
Worked out some details with GLM-5.3:
- Superblocks: the 100x threshold (“superblocks” in NIPoPoWs terms) sets the settlement rate (mean ~100 blocks, geometric tail: 13% over 200, 4.9% over 300) and prices manufacturing an outcome at ~m \cdot N blocks of energy. It does not price peeks or reorgs — those are controlled by other dials.
- Peek-and-withhold is the real attack: every block is a free 1-in-100 peek; withholding an unfavorable qualifying block costs ~1 block reward regardless of m. Marginal bias \approx 1/(1-q) — m cancels. Bounty must satisfy B + R \geq s_{\max} \cdot P, so it scales linearly with the prize.
- Replacement is not 100x-hard: reorging the settlement is standard confirmation-depth economics; BCH’s 11-conf auto-finalization covers it for any q < 0.5 ((q/p)^{10} race odds). No need to wait ~m confirmations — confirmations never had to scale with m.
- No fallback rule: lottery slows until a qualifying block lands. If a hard deadline exists, it triggers refunds (manipulation-neutral), never a weaker RNG.
- VDF over the seed kills the peek: outcome = h^{2^T} \bmod N; by the time the withholding miner can evaluate it, withholding costs him stale blocks. Constant-factor hardware edge (ASIC vs commodity, ~2–10x) is absorbed by setting T with slack — unlike PoW, capital can’t buy wall-clock time. With BigInt + bounded loops + functions, Wesolowski verification (one modexp) is native Script; add a Pocklington certificate for the challenge prime e = H(x,y) — the primality check is where the soundness lives, fixed-e is trivially forgeable. RSA modulus via MPC ceremony over class groups (simpler script, acceptable threat for a lottery).
- With a real VDF, the bounty collapses: withholding becomes pure griefing/delay, not steering — nominal bounty, prize-independent.
- Residual threat: a majority attacker always owns the chain; m just makes each reroll cost ~m blocks of exposed fork time. That’s as good as single-chain PoW gets.
- Result: m prices manufacturing, finalization prices replacement, the VDF prices peeks — three orthogonal dials, and the jackpot sizes you can safely run scale with the last two, not the first.
2 Likes
Thanks for reviving this long-dead research topic, oh mighty 
Necromancer !
No, but seriously - thank you 
, because I almost forgot I invented this.
Regarding your argument:
This is generally a very good idea in general, however the 100x ratio might be dangerous (too high) because it could cause some unpredictable consequences (like miners actually fighting to mine that block for some reason I cannot perceive yet and stopping mining normal blocks with 1x difficulty).
I am sure we could come up with some “safer number”.
So I understand the idea here is to allieviate the possible cheating issues with increased difficulty, so it is harder for the miners to cheat?
I understand the concern, however I am not sure if this is necessary. You can construct the lottery in a way where the winning block hash decides which other blocks and transactions included in these blocks get picked to decide the winner (get inserted into the final hash that decides the winner). This way, cheating is made so incredibly hard, it is completely impractical to cheat because you would have to clverly craft 1000 consecutive blocks, including transactions in them.
Or did I understand your intention wrongly?
I was thinking about something else where I had to ponder PoW targets and got reminded of this, can’t believe it’s already been 4 years since this thread. Anyway, then I remembered these talks, and wanted to note this down and went searching for the thread. I think someone else was more recently bouncing this lottery idea, but maybe it was on Telegram.
Right. And Freetrader was still here 
1 Like