Bit of FUN!!! Automated lotto system on XRPL?!

[thinlyspread]

OK guys this is just for fun, maybe it takes off or maybe it's a load of crap. But I get these XRPL ideas once in a while as you know. 

So I had a dream last night that I won the lottery ("lotto") but it was via XRP ledger, somehow... weird... so I woke up a few hours ago, had a coffee, and thought... actually, I wonder if that could be done on a blockchain?! (Maybe it already has been done – e.g. bitcoin mining is itself a kind of, sort of, lottery mechanism...)

I have about 10 different variations in my mind of how it might work, and I'm sure you can all come up with tons too... remember this is just for fun, a quirky idea to encourage thinking about XRP ledger technology and features. Here's my basic concept thus far (only one cup of coffee in) but it's not written in stone:

• Payment (and reward) should all be in XRP – no gateways, trustlines, tokens, no counterparty etc. (Unless you think of a better way.)
• XRP pot should be in some kind of transparent, auditable account – maybe an escrow? 
• Payment for "tickets" should ideally burn XRP (black hole address?) or somehow reduce XRP supply overall, as a net positive for the community.
• But ideally the project should be self-funding – I'd be happy to contribute a few XRP to start but it needs to scale with users.
• Needs a mechanism to adjust/calculate odds of winning so it's trustable but can be scaled as people play, and not gamed.
• Proceeds? When buying a "ticket" maybe some/all (?) of the funds goes into the pot? This goes slightly against the "burning" XRP idea; but a trade-off is that (a) some/all the XRP in the "pot" comes back out into supply again when someone wins, but (b) the pot expands and retracts in an automated fashion funded by ticket purchase, based on pot size.

Suggestions, comments all welcome... but in the name of fun and experimentation. I literally typed this off the top of my head and have no coding skills.

Could NFTs be involved somehow? 

How much would tickets cost? Is it set or variable? 

What about time period? Lottos work well as they build hype and interest over time as people see the pot grow and grow before the Big Day! 

Should there be some limit to stop whales trying to game it, or would the risk of not getting the rewards be enough to stop that?

What about micro-payments/tickets? E.g. a fraction of an XRP is a "fraction of a chance". 

Could orderbooks somehow play a role, where a ticket is a token/issuance or even an NFT of some kind?

What about charitable donations? I.e. some of the pot, or fees/tickets, going towards a cause.

XRP ledger hooks? Useful? Memo fields? 

__________________________________________________________________________________________

@brianwalden @KarmaCoverage @RobertHarpool @tulo 

Edited March 17, 2021 by thinlyspread

[Prometheus_Rising]

You could have it that someone creates a "game" with their specified parameters e.g. 1 XRP buy in, 5 "players", game type(you could also automate random games. Type, value etc). The interface then makes public a set of QR codes that have the players initial transaction settings and includes a memo referencing a "player" of the particular game(first in best dressed). Maybe the 1 XRP could be put into escrow with different release address or addresses depending on the "game" outcome e.g. winner takes all (all escrows go to the "winner". **Insert distribution model here).

As each "player" enters the game a slot is disabled. When there are enough "players"(5), the "game" is started. Game completes and final transactions take place. 

I have not done too much with the ledger so I am not sure if the release parameters can be changed while in escrow.

Interesting idea.

[thinlyspread]

5 minutes ago, Prometheus_Rising said:

As each "player" enters the game a slot is disabled. When there are enough "players"(5), the "game" is started. Game completes and final transactions take place. 

That's interesting, so (correct me if I'm wrong but) what you're saying is rather than one lotto, make it more distributed and have a lotto be just one "lottery game" that can be set up with whatever parameters are acceptable to participants? Then it's almost like competition for the best lotto system. Let the market decide. I guess the trade-off is that it splits the pots into lots of games, whereas one "centralised" lotto draws in more funds/attention, but the trade-off is the inverse... if it's not a good system no one wants to be involved. 

I think the big challenge is finding a way to automate payments from the escrow. With escrow you can do a secure time-lock of whatever you want but the payment destination, as far as I know, is preset and immutable. So maybe we'd need programmatic (smart contract) stuff. Which is above me! Or maybe it's within the realm of hooks and basic XRPL features. Also how to set the "randomness" of ticket/participant selection. 

[Prometheus_Rising]

More participants = lower odds = higher reward

Less participants = Higher odds = Lower reward

Higher stakes = higher risk = higher reward

Lower stakes = Lower risk = lower reward

 

I guess I am thinking of potential users. The ability to choose the risk/reward of a game will help with adoption. If you like the idea of a giant lotto, there would be nothing stopping you from starting one.

When I am trying a new system I like to start with a small value/risk and then progress with more value when I am confident  that it works.

Lotto is an easy way to start but it could be expanded into different games.

If you are a programmer, you could create a basic version to simulate players/stake/distributions etc without the XRPL. It would help to work out the steps needed to be implemented on the XRPL.

**edit: on the issue of randomness. could something be done with transaction hashes e.g. first numbers in the first 6 transaction hashes of the following  ledger close (to get 6 numbers)? or some variation.............

 

Edited March 17, 2021 by Prometheus_Rising
randomness

[Guest]

I cannot contribute here, the only skill I have is throwing money into random projects and hope number will go up.

You can count me in as a beta tester with my gambling addiction I am the right person for this job.

I don't know if you remember the website rippleflip from the early days. They had a "provably fair betting game". Unfortunaly the code was never opensource, but maybe the founder is still lurking here ? I lost probably tens of thousands $ with this game, so I am not shure how fair this algorithm was.

Edited March 17, 2021 by Guest

[brianwalden]

If your goal is simple, I think I have an idea. It's all based on transaction ids being random. I think they are because they're a hash, but I couldn't immediately find the hashing algorithm being used. So check with one of the technical guys before you do this.

Create a new wallet and fund it with the wallet reserve. The last character from the transaction id determines the winning character. That's 1 in 36 odds (A-Z and 0-9 is 36 characters) - I'm guessing you won't have a lot of people to start so that may be sufficient. Anyone who wants to play sends 1 XRP to the wallet, if the last character of their transaction id matches the winning character, they win the prize. The transaction id that sends them their winnings is then used to determine the winner for the next round. If your lottery grows you can choose the winner based on the last 2 characters for 1 in 1296 odds.

I'm guessing that in many jurisdictions you would need to run the lottery without taking a cut for yourself to avoid legal trouble.

[KarmaCoverage]

1 hour ago, thinlyspread said:

Could NFTs be involved somehow? 

The IOU.NFT could be used to Claim the pot. Then it could be traded pre-claiming XRP, thus it's value should be tied to XRP.

I'm pretty sure someone did a thing like this back in 2013-14 or something. I never participated, because I dont gamble.

There are some schemes in UK history that lottery give away an entire Credit Union's interest revenue to a single user each month. Instead of the interest staying Union's own balance sheet. Pretty sure for some reason this is illegal in the US (I'd disagree with that rule, but oh well).

This arrangement should be doable via Trustlines using Quality In/Out. I think it's cool. You could do something like this with payment flows within a community.

You could also worn in some elements of Time Banking. Idk

[brianwalden]

35 minutes ago, Prometheus_Rising said:

More participants = lower odds = higher reward

Less participants = Higher odds = Lower reward

Higher stakes = higher risk = higher reward

Lower stakes = Lower risk = lower reward

 

I guess I am thinking of potential users. The ability to choose the risk/reward of a game will help with adoption. If you like the idea of a giant lotto, there would be nothing stopping you from starting one.

When I am trying a new system I like to start with a small value/risk and then progress with more value when I am confident  that it works.

Lotto is an easy way to start but it could be expanded into different games.

If you are a programmer, you could create a basic version to simulate players/stake/distributions etc without the XRPL. It would help to work out the steps needed to be implemented on the XRPL.

**edit: on the issue of randomness. could something be done with transaction hashes e.g. first numbers in the first 6 transaction hashes of the following  ledger close (to get 6 numbers)? or some variation.............

 

I was thinking like you, you just typed faster.

[thinlyspread]

33 minutes ago, baggy23 said:

I don't know if you remember the website rippleflip from the early days. They had a "provably fair betting game". Unfortunaly the code was never opensource, but maybe the founder is still lurking here ? I lost probably tens of thousands $ with this game, so I am not shure how fair this algorithm was.

OK that's interesting, thanks. Sorry about the losses though! Maybe I can contact the author. It does reinforce my point too, that it must be transparent or verifiably/provably "fair" to participants. 

34 minutes ago, baggy23 said:

You can count me in as a beta tester with my gambling addiction I am the right person for this job.

Classic baggy! 

[thinlyspread]

3 minutes ago, brianwalden said:

I'm guessing that in many jurisdictions you would need to run the lottery without taking a cut for yourself to avoid legal trouble.

Yeah but it's also why I'd prefer an automated system that's self-funded by the community and without such counterparty risk. That's the technical challenge. 

[thinlyspread]

5 minutes ago, brianwalden said:

If your goal is simple, I think I have an idea. It's all based on transaction ids being random. I think they are because they're a hash, but I couldn't immediately find the hashing algorithm being used. So check with one of the technical guys before you do this.

Create a new wallet and fund it with the wallet reserve. The last character from the transaction id determines the winning character. That's 1 in 36 odds (A-Z and 0-9 is 36 characters) - I'm guessing you won't have a lot of people to start so that may be sufficient. Anyone who wants to play sends 1 XRP to the wallet, if the last character of their transaction id matches the winning character, they win the prize. The transaction id that sends them their winnings is then used to determine the winner for the next round. If your lottery grows you can choose the winner based on the last 2 characters for 1 in 1296 odds.

This is definitely an intruiging and creative idea! Is it scalable in an automated sense though? I.e. I wonder if there's a way to use the tx hashes as you say but programmatically. Then again, if it can be programmed somehow, would it be more efficient to program something even simpler i.e. just selecting addresses at random?

I suppose what I'm getting at is, what is the simplest method/hack that removes the risk of fraud/counterparty and doesn't require one person/group to maintain it, and ideally even fund it, since it can just work ad-hoc as funds go into it from anyone in the community. 

[thinlyspread]

12 minutes ago, KarmaCoverage said:

The IOU.NFT could be used to Claim the pot. Then it could be traded pre-claiming XRP, thus it's value should be tied to XRP.

How would this function? Is a private key embedded? Is it fractional, so everyone owns a part ("ticket") that's a portion of the NFT which represents the entire pot? 

[thinlyspread]

Can one request an empty account or escrow be set up on the XRP ledger, with certain programmatic conditions embedded, but without a private key being revealed (provably)?!

Edited March 17, 2021 by thinlyspread

[brianwalden]

8 minutes ago, thinlyspread said:

Yeah but it's also why I'd prefer an automated system that's self-funded by the community and without such counterparty risk. That's the technical challenge. 

Scanning the lottery wallet's transaction ids on the ledger is very easy programmatically. A transaction id based lottery should be simple to automate. The only difficulty I can see is how to handle people who send the wrong amount (either too much or too little) for the price of a "ticket".

If you want to totally remove trust, this is begging to be a smart contract on Flare. Come to think of it, there must be lottery smart contacts on Ethereum you could look into. Gambling is just math, it easily lends itself to this type of thing.

[thinlyspread]

9 minutes ago, brianwalden said:

Scanning the lottery wallet's transaction ids on the ledger is very easy programmatically. A transaction id based lottery should be simple to automate. The only difficulty I can see is how to handle people who send the wrong amount (either too much or too little) for the price of a "ticket".

This is why I think it has to be totally decentralized/automated/verifiable out the gate, because can you imagine if you set this up and people had even the faintest clue that you might have some control over the account(s) involved, and someone accidentally sends too much XRP to it?! They'd never leave you alone! 

Horrible as it may be, that might just be the way it goes... unlss as you say there's a mechanism/hook to set a max-value or something on receivable transactions.

Edited March 17, 2021 by thinlyspread