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

CHIPs Process
#1

SUMMARY:

I am seeking to find out the viability of following idea that creates new incentives for average humans to use P2P Cash, I require input, comments and criticism from other ecosystem participants, especially Node developers.

This is a PRE-CHIP, an idea that might become viable. Hopefully your input will help me to determine whether it is viable or not and whether it can be made into a real CHIP.

MOTIVATION:

During my observation of human society, I noticed that the desire for freedom from interference and other people is not the dominant driving force of everyday life for an average human. Instead; taking risks, belief in random chance of success and similar greed-fueled activities are the norm.

So, this is where, after 2 years of thinking, the idea came from; to create a “greed engine” to power brick&mortar adoption, donations, flipstarter pledges and other things that Bitcoin Cash community considers important for the success of P2P Cash around the world.

TL;DR:

The idea that came to me [working name: OP_LOTTERY]:

  • What if there was a way to create a Bitcoin Cash public key (address) that automatically sends some percentage of all received funds back to sending address at random after some expiration time or at a pre-defined date?
  • This would probably work using some clever kind of smart contract
  • Every lottery is provably fair because it is all done by the blockchain.
  • After the lottery expiration date triggers, all funds from the address are multiplied times “payback percentage” (I propose 10% as default) and sent to one winner, selected at random

USAGE IN REAL LIFE:

  • Incentivizing donations/flipstarters: Every donation round or flipstarter becomes also a lottery where a human can “win big”.
  • Incentivizing retail adoption and payback schemes in shops. Customers have increased motivation to shop, because there is a chance they “win” every time they spend.
  • Creating casinos on blockchain with almost no extra software needed, as the winning percentage can be freely adjusted.

IMPORTANT DETAILS:

More technical:

  • After the coins are sent to address, they sit on it for a predefined amount of time (or until a specific date)
  • The owner of the receiving address is the “lottery owner”
  • After the predefined time or at a predefined date, a “winner” is selected at random
  • A percentage value from all funds sitting on the address is calculated and then sent to the winner.
  • Since the Bitcoin Cash blockchain is a very good source of random numbers, we can use it in the calculation that determines the winner.
  • The mining/node software uses the random data available in block, for example:
  1. Get SHA256 (PREV_BLOCK_HEADER + ALL INCOMING TRANSACTIONS PUBKEYs + NONCE)
  2. Create a random seed from this hash
  3. Using the random seed, select the winner that is the “closest” the the seed value using some clever fully deterministic algorithm

PROBLEMS TO SOLVE:

  • Is this even doable? Can it be coded at all?

  • The miners would have a great incentive to steal the lottery funds by sending their own transaction to the lottery address and adding it at the end of each block. Is this a viable attack scenario for a miner? (Also see votes scheme ideas below)

  • How many “votes” does a lottery participant get? My ideas:
    A) One sent transaction = One vote. The problem with this approach is people will spam as many low-value transactions as possible. Probably not viable.
    B) One sent satoshi = One vote. The problem with this approach is that the biggest fish gets the biggest chance of winning. This is why I suggest that the default percentage of the lottery is 10%. In this idea, how to disincentivize the lottery owner (owner of the receiving address) from adding a lot of his funds in order to win the lottery? (I logically assume there is no way to stop this completely from happening).
    C) Other?

  • If this works, who will be coding it? Well, the answer is easy: most probably me, when I get the time hopefully.

Brainstorming OP_BLOCKHASHMATURED
Brainstorming OP_BLOCKHASHMATURED
#2

Hnmm. Can’t this be done with a smart contract? I think after the May 2022 upgrade it should be possible at least. I’m got a contract guru but I sort of think it might not require any new opcodes, just clever contract design after May 2022 upgrade (after introspection and int64 upgrade).

@bitjson may know more.

#3

About incenives and attacks, I have devised following real-life scenarios. This scenario assumes that the winning chance is dependent on amount of money paid to the lottery address.

Scenario A - company inserts their own money to flipstarter:

  1. A company seeks to collect 100 BCH in a Flipstarter round
  2. To incentivize people donating, they set winning funds percentage to 20%.
  3. The company supplies 60% of the Flipstarter funds themselves, to increase their potentially collected money
  4. WIN (60% probability): Company gets full 40BCH
  5. LOSE (40% probability): Company gets -(20% x 60 BCH) + (80% x 40 BCH) = -12 + 32 = 20 BCH

vs

Scenario B - company plays fair:

  1. A company seeks to collect 100 BCH in a Flipstarter round
  2. To incentivize people donating, they set winning funds percentage to 20%.
  3. Company gets 100-(20% x 100) = 80 BCH

It would seem that there is no mathematical/economical incentive to cheat this way. Hopefully I did not make any mistakes in this calculation.

EDIT:
Nope, wait I made a mistake.

Fixing.

EDIT2:

I think an excel spreadsheet and chart is needed to compare different winning percentages and cheat amounts.

#4

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.

1 Like
#5

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?

#6

Unfortunately somehow I have a feeling it will require something more than a smart contract.

#7

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.

1 Like
#8

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.

1 Like
#9

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.

#10

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.

#11

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.

1 Like
#12

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.

#13

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.

#14

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.

#15

OK, so I gave this issue some thought.

If I understand this right, there are 2 sub-issues here:

  • Because there are multiple possible outcomes of a block due to there being micro-splits in the blockchain structure, everything from a block would need to be re-calculated for every possible block variant
  • Due to there being multiple variants of each block possible, it will become extremely hard or impossible to chain such variants with each other, due to there being exponentially rising number of possible scenarios due to random block headers changing on each subsequent block

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:

  1. Lottery Host announces in block 999 the lottery will happen at Bitcoin Cash address qpAAABBBCCD, starting at block 1000, ending at block 2000.

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

  3. The network (nodes) consider lottery status as “ENDED” in block 2001.

  4. The network (nodes) wait for 99 more blocks in order to execute the lottery.

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

#16

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 :smiley:

1 Like
#17

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 :smiley:

Good to know :slight_smile:

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.

1 Like
#19

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.

1 Like
#20

@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 :smiley:

2 Likes
#21

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!

1 Like