[PRE-CHIP/Idea] Establishing the viability of OP_LOTTERY [Incentivizing donations and sales through utilizing human greed]

[bitcoincashautist]

@garlonicon

It can be easily solved by some script like “123456 OP_GETBLOCKHASH” that will just return the hash of the block 123456. If that block number is from the future, then that output could be automatically timelocked to that block number. In a block 123456 that hash will be known and in all coming blocks it would be the same, unless block 123456 would be stale, but then that hash could be changed only once per chain reorg.

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:

Viability of Native Introspection of Mature Block Headers and Coinbase Transactions

The other day I asked this question about Native Introspection did you guys consider making blockchain context available to script by allowing introspecting a prevout’s block hash and height? and @emergent_reasons made me quickly realize why that’s not viable: forces re-evaluation of every transaction in the mempool on each block After some more brainstorming, one thing became clear, there are already some special kinds of outputs that may force re-evaluation of all transactions dependen…

[ShadowOfHarbringer]

@bitcoincashautist

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.

[bitcoincashautist]

yup, I say the same in the other topic