These are likely doable using a step or at most two steps of convenant script, and will be made easier by upcoming math and introspection opcodes.
Note, though, that there is no good way to get random data for any onchain script, so you’ll need to get a randomness source externally. Reading the block header incentivizes collusion with miners for inclusion and is likely a bad idea.
Hmmm, a miner has no way to create a “perfect” block that will give the exact SHA256 hash he wants. Every SHA256 hash is random, miners work via “throwing dice to find the dice throw that is closest to the supplied pattern”. We just need to utilize this randomness.
Am I wrong here? Aren’t block winning hashes completely random at least in part?
Unfortunately somehow I have a feeling it will require something more than a smart contract.
Any opcode that “reads” the block header will also change in validity and outcome based on which block it’s included in, and so will be a nightmare (if not outright impossible) to manage in mempool - it cannot be chained, and will need to be re-evaluated every block.
Any opcode that “reads” the block header will also change in validity and outcome based on which block it’s included in, and so will be a nightmare (if not outright impossible) to manage in mempool - it cannot be chained, and will need to be re-evaluated every block.
Thanks for valuable input.
I will now think about how to solve this issue.
I generally like the idea, but I’ll try to explain why I’m unsure such functionality should make it into consensus. I’ll start with general considerations, diving down into more specific later.
OP codes are generally understood to be basic building blocks from which complex functionality can be built. This proposal has a rather specific scope. General concepts are things like ADD, MUL, etc that can be harnessed into an infinite number of usecases. This seems to have one single usecase.
It also implicitly relies on a fair source of randomness, which is a whole different problem unto itself.
“The owner of the receiving address is the “lottery owner””, so if they are the owner then they should be able to spend (steal) the amount, instead of giving it to the lottery.
I am sympathetic with the use case, but I think that it can be solved, with a varying degree of trust, by using SLPs and a centralised server - since you still care about your own reputation, you’ll be honest about the lottery. This could be essentially made fair using some variant of the “provably fair” procedures of gambling sites. Senario: an online shop is giving one SLP token for each 10$ spent, and every week they send a jackpot to a random utxo containing the token.
Or maybe some smartBCH bridge nowadays.
I do think that, if a fair source of randomness is available, a suitable smart contract could be created (or maybe not, idk). But I still feel that this functionality is too specific in a general purpose setting.
Thanks for your input, @mtrycz
Regarding some of your points I can address right now:
Yeah, “OP_LOTTERY” is not an opcode, just a generic temporary name for this functionality. It does not have to actually be an opcode.
I agree, perhaps it would require some other significant changes, opcodes may not be enough.
This is why I posted it here as a pre-chip so I can get your input and criticism to find out whether this can be refined into a valid idea for the future.
I am sorry, but this is unacceptable. It has to be completely provably fair and require no centralization/trust/service.
To make any sense and bring the benefits I think it could potentially bring, this proposal would have to run on Bitcoin(Cash) blockchain itself.
Above point also applies.
I aim for a “general purpose” setting, because my goal is to make every shopping BCH transaction a lottery, possibly.
It could enable automated blockchain-based payback scheme for every merchant everywhere, worldwide with just a click.
So I think the possible ramifications of this proposal (if it works in a decentralized fashion and doesn’t strain the network) are basically insane. It could be a total game changer for BCH.
Votes by transaction count and votes by satoshi sent are essentially the same vote system. Because you cannot prevent someone from sending multiple transactions (either be it using the same address or multiple addresses controlled by the same person), transaction counting comes down to how much satoshi they are willing to send. The only difference being that rather than in a single transaction, it is in multiple. This method would bloat the blockchain a lot with small transactions for the sole purpose of gaining a lottery advantage. Attempting to track people potentially splitting their coins into multiple addresses prior to entering the lottery would require chain analysis which cannot be done from within the blockchain, you will need some other central server. I do not recommend doing it by transactions sent.
Using the total satoshi amount sent from someone would prevent the bloat and would be the same system as a normal lottery or raffle. The more money put in the higher the chance of winning.
It seems like it might be possible to do this lottery system using some sort of convenant script as previously suggested by imu. Although i think the viability is tied to the number of lottery participants and going over some sort of threshold would break the lottery system due to script system constraints.
Sorry for not answering too long, I had some significant life issues to deal with.
Regarding your points, @Griffith
Votes by transaction count and votes by satoshi sent are essentially the same vote system.
I am not entirely sure we are talking about the same thing. Perhaps this is my fault, I should have been more clear?
When I meant “vote by transaction count” I mean by the total number of transactions, completely disregarding sent value. So 100 votes of 1 satoshi each would be worth the same as 100 votes with 1 BCH each.
When I meant “vote by value” I meant that 1 vote of 1 BCH is worth the same as 100 000 000 1-satoshi votes or so.
Using the total satoshi amount sent from someone would prevent the bloat and would be the same system as a normal lottery or raffle. The more money put in the higher the chance of winning.
This is exactly my point. So far I don’t see how such a system could be easily abused, but I have probably not analysed all possible scenarios yet.
It seems like it might be possible to do this lottery system using some sort of convenant script as previously suggested by imu.
I will get to implementation after I confirm such a system is possible to do at all and it doesn’t have any serious downsides.
Ah, and obviously after I write a proper CHIP.
Yes, I understand this. I was only trying to point out that because there is no way to accurately determine, without chain analysis, if two addresses are submitting votes for the same person, these two systems are the same. This is an illusion of choice.
Correct, however assuming cheating is not incentivized: meaning it is not more profitable to cheat than to do “honest” lottery, then it it does not change anything in the ultimate outcome.
Also, there is no point in even trying to find out whether a lottery is honest or not, because chain analysis is not 100%-proof and that is out of the scope of this idea anyway.
it is irrelevant whether the lottery is “rigged” by the lottery owner or not. Instead of trying to police every lottery being honest, incentives should be set up in a way that it is not profitable to cheat.
OK, so I gave this issue some thought.
If I understand this right, there are 2 sub-issues here:
Hmmm, this proposal would indeed be difficult to or impossible to do if we use data from the current block (the same block that would contain lottery result).
So, a possible solution would appear to be to solve lottery later, X blocks after the lottery votes were passed and confirmed. Perhaps the default for X could be the same value miners get their payout after (was it 100 blocks?).
The exact scenario I mean is:
Lottery Host announces in block 999 the lottery will happen at Bitcoin Cash address qpAAABBBCCD, starting at block 1000, ending at block 2000.
Lottery participants pay for goods and services by sending their BCH to the lottery address, and their transactions end up included and confirmed by the network in blocks 1000 to 2000.
The network (nodes) consider lottery status as “ENDED” in block 2001.
The network (nodes) wait for 99 more blocks in order to execute the lottery.
The lottery is executed in block 2100 and the winner is selected, the random seed to make the lottery “deterministically random” and fair is taken from last lottery participation block, meaning block 2000.
5a) Alternatively, the random seed can also be taken as a sum from SHA256(BLOCK2000…BLOCK 2099) for more randomness. But would that really be any better or more random? Not sure, but I sense that probably it won’t. I am not that good at crypto math to be sure.
I think this should do it.
I await your input @im_uname. Did that solve the issue?
I’m not @im_uname , but I think if it is known in advance that block 2000 is “the decider”, then some miner can try grind it to tilt the lottery outcome in their favor.
Maybe this will not be a big problem in practice, but I think there would be ways to harden a blockhash-based randomness scheme against such gaming.
My suggestion would be to use hash data from more blocks. That would make it increasingly expensive for miners to game the scheme.
For example, do a kind of random walk back through block hashes based on some block hash, in your example the one from block 2000.
Use the hash to decide how far to jump back to get the next block to inspect. Do this a few times (maybe 10 or 20 times) and it should be very hard for a miner to construct such a sequence of blocks in the past history that would would allow them to game the outcome. Why? because you can make it potentially go back quite far to beyond when the lottery was announced. And you can’t game the future unless you know what lotteries are going to be announced. The only alternative is to allocate lots of hashpower generally to BCH, which is also expensive.
This is just a showerthought on how to address the gameability of blockhash-based randomness.
Generally I like the idea of using lotteries to incentivize use of Bitcoin Cash, even though I seldom play the lottery. Or maybe I do every time I go outside 
I’m not @im_uname , but I think if it is known in advance that block 2000 is “the decider”, then some miner can try grind it to tilt the lottery outcome in their favor.
Maybe this will not be a big problem in practice, but I think there would be ways to harden a blockhash-based randomness scheme against such gaming.
My suggestion would be to use hash data from more blocks. That would make it increasingly expensive for miners to game the scheme.
For example, do a kind of random walk back through block hashes based on some block hash, in your example the one from block 2000.
These are very valuable suggestions, thanks @freetrader
It will take me a lot of time to finsh designing/coding this idea anyway, so I might as well do it “right”, in a way that cannot be gamed at all.
By incorporating your input I believe it will be possible.
Generally I like the idea of using lotteries to incentivize use of Bitcoin Cash, even though I seldom play the lottery. Or maybe I do every time I go outside
Good to know 
Now that I have the opinions of most major active developers I conclude that the idea is probably not dumb, retarded, controversial or technically infeasible, therefore I will first conduct an incentive analysis in a form of excel spreadsheet and a chart and then I will start writing the actual proper CHIP.
Again, thanks everybody for your valuable input.
If you want to make every transaction a lottery, then you can use transaction fees for that. All that is needed is some miner running the lottery, that miner can just collect all fees and send them to the winner. Mining is in practice some kind of lottery: all miners are trying to collect fees and only one miner can get the whole pot sitting in mempool. For now, there are no restrictions, any miner with block hash below the target can get the whole pot. Just change that rule and restrict who should get the coinbase transaction and you will get your lottery. Then, everyone could download that block and make sure that the coinbase transaction is sent to the lottery winner.
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.
No, because if you have a function f(a,b,c,d) that takes a, b, c and d and produces some result, for example from 0 to N-1 and based on that there is one of N winners selected, then it is possible to game the whole system just by constantly changing d-value. Each block header contains the hash of the previous block, there is no point in hashing last N block headers, because they are hashed during chain creation. If block hashes will be the source of randomness, then miners will always win, because they can create as many non-standard transactions for free as they want, so they can put some coins in the lottery without sending their transactions to other mempools in P2P network, and they can mine only the blocks when they win.
@ShadowOfHarbringer I made a little competition for the Introspection upgrade, that demonstrates some simple uses of the opcodes and reactivated OP_MUL.
It got me thinking whether a lottery is possible, and a simple/limited variant may be, however I think some awesome “native” rolling and “always on” lottery could be created using CashTokens/Group, and your thread will hopefully inspire a contract to celebrate May 2023 upgrade
Oh, my browser crashed and I just noticed this now.
It’s like a bounty to use the new features of BCH first, it will inspire some participation and usage.
Great idea!
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.
yup, I say the same in the other topic 