Bitcoin Forum
May 05, 2024, 09:09:01 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [IDEA] +EV (Positive Expected Value) P2P Raffle Games (PeerBet Style).  (Read 5435 times)
Financisto (OP)
Hero Member
*****
Offline Offline

Activity: 632
Merit: 768

BTC⇆⚡⇄BTC


View Profile WWW
January 11, 2014, 05:19:34 AM
Last edit: March 23, 2014, 07:18:59 PM by Financisto
 #1

Greetings!

I'm a big fan of Raffle games available out there, and the most innovative by far (IMHO) is PeerBet at the time I'm writting this.

They are the 1st known 0EV (Neutral Expected Value) and zero house edge for gamblers to play against each other.

I've got an hypothetical idea that may seem interesting in the beginning. It might give that inovation one step beyond it is today.

House tickets, additional rounds, progressive jackpots, jackpot roll overs = +EV (Positive Expected Value) Peer-to-Peer Raffle Games.

I've been testing a new "generation" prototype of raffle games in order to achieve some interesting and innovative features:

a) Limited tickets: players get better winning odds and probabilities;

b) Progressive jackpots: "house tickets" "win" the game (some times) and roll over all the current jackpot to fill next round or game. The game becomes +EV for gamblers to play. So more gamblers will come for next round (bigger pots). P.s.: House's Tickets never add funds to jackpot, they are worthless, their only remaining purpose is to roll over the current pot to next round's jackpot. House does not profit from jackpot when its tickets are chosen;

c) Jackpot rolls over: raffle creators (gamblers) might set series ("championships"?) of raffles so when one game ends a % of that jackpot from last round rolls over to 1st round of next game;

d) Additional funds: an option to add manually some coins to 1st round jackpot would be interesting too (1st round starts +EV for all gamblers).

And more:

* Always a Winner at the end of last round;

* Transparent and Cheat Proof (Provably Fair);

* Cryptographically Verifiable;

* etc.


Here goes some calculations/simulations from that conceptual idea:



Notes from that simulation:

* One game consists of 4 rounds and entry ticket price of .1 BTC;

* Payout - 85% of jackpot: to prevent someone from attempting to buy all the tickets;

* 15% roll over: to ensure that the next game starts with some value on pot;

* 4 rounds: 4th round without house tickets.

P.s. Winning/Losing Probabilities; EV (expected value); Variance and Standard Deviation => Gambler's perspective.

Advantages (HOUSE): by implementing that idea, the house gets some profits from rake (when there's some relevant scalability), some explosion of new visitors (potential gamblers and advertisers) and the 1st P2P +EV raffle game ever!

Advantages (Gamblers): +EV Games to play/gamble, bigger pots to win, profitable on the long run.

What do you think about it?

Would that possibly work?

Are there any flaws, issues or problems I did not figure out yet?

Collaborations are appreciated...

LIST • ESCROW providers • Ranking & Scores available!LIST • FOSS BrainwalletsBTC ⇆⚡⇄ BTCBTC aka BTC: 16MBvhaJoRBxW3Vk6apnvz3UYT9HAgraVS ⚡ PGP: 2680207AA9A1B69FE7A033D80DE0F221074384C4 ⚡ If you think freedom matters, please support the development of these privacy projects→DONATE some sats: TailsQubes OSWhonixVeraCryptPicocryptKryptorSimpleX Chat
1714943341
Hero Member
*
Offline Offline

Posts: 1714943341

View Profile Personal Message (Offline)

Ignore
1714943341
Reply with quote  #2

1714943341
Report to moderator
1714943341
Hero Member
*
Offline Offline

Posts: 1714943341

View Profile Personal Message (Offline)

Ignore
1714943341
Reply with quote  #2

1714943341
Report to moderator
The Bitcoin software, network, and concept is called "Bitcoin" with a capitalized "B". Bitcoin currency units are called "bitcoins" with a lowercase "b" -- this is often abbreviated BTC.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714943341
Hero Member
*
Offline Offline

Posts: 1714943341

View Profile Personal Message (Offline)

Ignore
1714943341
Reply with quote  #2

1714943341
Report to moderator
1714943341
Hero Member
*
Offline Offline

Posts: 1714943341

View Profile Personal Message (Offline)

Ignore
1714943341
Reply with quote  #2

1714943341
Report to moderator
1714943341
Hero Member
*
Offline Offline

Posts: 1714943341

View Profile Personal Message (Offline)

Ignore
1714943341
Reply with quote  #2

1714943341
Report to moderator
bit777
Sr. Member
****
Offline Offline

Activity: 420
Merit: 250


View Profile
January 11, 2014, 07:12:30 AM
 #2

Something I see possibly as a flaw in your idea:

If the house was winning from time to time, to place the balance in the Progressive jackpot, then the raffles on which the house is winning would be Negative EV. The Jackpot Raffles would be +EV afterwards. However, after you combine both, it will still be 0 EV.

Unless the house pays for its winning tickets, but then the house would be losing money.


Also, we already have limited tickets on our raffles.

Thoughts?
Financisto (OP)
Hero Member
*****
Offline Offline

Activity: 632
Merit: 768

BTC⇆⚡⇄BTC


View Profile WWW
January 11, 2014, 08:32:50 PM
Last edit: February 01, 2014, 10:16:48 AM by Financisto
 #3

When a "house ticket" wins a round, all value contained at that round's jackpot is rolled over to next round.

The House does not win any prize when its tickets are chosen by the system. Its role is like a dealer on poker. Players put the money in, not the House.

The House only profits the fees from 2nd round and foward. 1st round winners (gamblers) are free from charge/fees (house edge).

Theoretically, if those rules are followed (and if I'm not seriously mistaken), the raffle becomes +EV for (new) gamblers right on 2nd round because of progressive jackpot's effect.

The raffle would be +EV right from 1st round if filled by funds (16.67% as the example shown above) from previous game (4th round from last raffle game).

Quote
[...] However, after you combine both, it will still be 0 EV. [...]

Theoretically, Peerbet wouldn't have those "House Edges" because it's (almost) pure P2P.

And there's still one additional possible feature in order to make stuff more interesting as mentioned above:

Quote
d) An option to add manually some coins to 1st round jackpot would be interesting too (1st round starts +EV for all gamblers).

That could be achieved by sending some funds earned from advertising revenue.

That's the idea's summary...

LIST • ESCROW providers • Ranking & Scores available!LIST • FOSS BrainwalletsBTC ⇆⚡⇄ BTCBTC aka BTC: 16MBvhaJoRBxW3Vk6apnvz3UYT9HAgraVS ⚡ PGP: 2680207AA9A1B69FE7A033D80DE0F221074384C4 ⚡ If you think freedom matters, please support the development of these privacy projects→DONATE some sats: TailsQubes OSWhonixVeraCryptPicocryptKryptorSimpleX Chat
Financisto (OP)
Hero Member
*****
Offline Offline

Activity: 632
Merit: 768

BTC⇆⚡⇄BTC


View Profile WWW
January 22, 2014, 02:33:37 AM
Last edit: February 02, 2014, 10:01:33 PM by Financisto
 #4

Ladies and Gentlemen,

I'll paste here a critique that I find important in order to evolve that idea:



Brief Critique of a Brief Proposal

The Preposal

BitcoinTalk user Financisto proposed the following "improvement" for Peerbet:

Quote
   Greetings!

    I'm a big fan of Raffle games available out there, and the most innovative by far (IMHO) is PeerBet at the time I'm writting this.

    They are the 1st known 0EV (Neutral Expected Value) and zero house edge for gamblers to play against each other.

    I've got an idea that might give that inovation one step beyond it is today.

    House tickets, additional rounds and progressive jackpots = +EV (Positive Expected Value) Peer-to-Peer Raffle Games.

    I've been testing a new "generation" prototype of raffle games in order to achieve some interesting and innovative features:

    a) Limited tickets: people get better winning odds and probabilities;

    b) Progressive jackpots: "house tickets" win the game (some times) and roll over all the current jackpot to fill next round or game. The game becomes +EV for gamblers to play. So more gamblers will come for next round (bigger pots);

    c) Raffle creators (gamblers) might set series ("championships"?) of raffles so when one game ends a % of that jackpot from last round rolls over to 1st round of next game;

    d) An option to add manually some coins to 1st round jackpot would be interesting too (1st round starts +EV for all gamblers).

    And more:

        Always a Winner at the end of last round;
        Transparent and Cheat Proof (Provably Fair);
        Cryptographically Verifiable;
        etc.

A Brief Note

First of all, let's consider what any monetary transaction can be modelled as.
Code:
Inputs = Outputs

For those familiar with business, this is exactly the basic rule of accounting.
Code:
Debits = Credits

This is simple enough. In fact, this is general enough that it can model any type of transaction in any currency over any medium.

Casino games

Casino games results are a subclass of transactions. There are generally restrictions to casino games. Indeed, casino games generally only have two inputs: Players and House, in addition to two outputs: Players and House. (For the sake of simplicity any other outputs, such as Government Taxation, are included into House.)

Now let's define these terms.

+ve EV

A Casino Game has +ve EV iff (if and only if) the average Players output is strictly greater than the average Players input.

−ve EV

A Casino Game has −ve EV iff the average Players output is strictly less than the average Players input.

0 EV

A Casino Game has 0 EV iff the average Players output is equal to the average Players input.

A +ve EV game?

From the above, it's easy to conclude that in the absence of non-Player and non-House inputs, a +ve EV game must have higher average House input than average House output. For if not, then:

Code:
House-in + Players-in < House-in + Players-out ≤ House-out + Players-out
House-in + Players-in < House-out + Players-out

Which is clearly impossible. Thus, a +ve EV game must be a losing proposition for the House in the long run.

So what went wrong with the Proposal?

The Proposal failed to specify who is paying for the House's tickets. In the Proposal, these tickets represented a "thin-air" input. Since casinos cannot in general print money, "thin-air" inputs are impossible.

It is assumed that those tickets will be awarded by the House to the House. In the Proposal, calculations were made based on a pot that is a direct consequence of the number of tickets. But if the number of tickets includes tickets that were not paid for, either the pot will shrink or the House will end up needing to pay for the tickets. Such is life.



Source: http://bit.ly/1dzFcZg

I wish to thank forum member dree12, also a Peerbet member, for the critique above as it turns this topic richer in content.

Thank you so much and greetings for all members at Peerbet as well.

P.s. I'm gonna make some notes on a separate reply so we can discuss some details a little further...

LIST • ESCROW providers • Ranking & Scores available!LIST • FOSS BrainwalletsBTC ⇆⚡⇄ BTCBTC aka BTC: 16MBvhaJoRBxW3Vk6apnvz3UYT9HAgraVS ⚡ PGP: 2680207AA9A1B69FE7A033D80DE0F221074384C4 ⚡ If you think freedom matters, please support the development of these privacy projects→DONATE some sats: TailsQubes OSWhonixVeraCryptPicocryptKryptorSimpleX Chat
Financisto (OP)
Hero Member
*****
Offline Offline

Activity: 632
Merit: 768

BTC⇆⚡⇄BTC


View Profile WWW
January 25, 2014, 02:43:20 AM
 #5


A +ve EV game?

From the above, it's easy to conclude that in the absence of non-Player and non-House inputs, a +ve EV game must have higher average House input than average House output. For if not, then:

Code:
House-in + Players-in < House-in + Players-out ≤ House-out + Players-out
House-in + Players-in < House-out + Players-out

Which is clearly impossible. Thus, a +ve EV game must be a losing proposition for the House in the long run.

Let's see an example:

From the picture above, we get game one, 2nd round. Let's consider each round an independent game.

We get the following by your input-output code:

Code:
+EV: House-in + Players-in < House-out + Players-out

1st note: as explained above,  "House's Tickets never add funds to jackpot, they are worthless, their only remaining purpose is to roll over the current pot to next round's jackpot. House does not profit from jackpot when its tickets are chosen".

So:

Code:
House-in = 0

For 2nd round we got (financially):

Code:
Players-in = .01 * 10 = .1

Code:
Players-out = .1694

Code:
House-out = .0006

Then:

Code:
0 + .1 < .1694 + .0006

So when Bob starts playing the game from 2nd round (as shown above) he gets an +EV scenario thanks to progressive jackpot (rolled over from 1st round). Considering 2nd round an independent game from round 1, with brand new different players as well, we have players staking .1 to earn .1694

So what went wrong with the Proposal?

The Proposal failed to specify who is paying for the House's tickets. In the Proposal, these tickets represented a "thin-air" input. Since casinos cannot in general print money, "thin-air" inputs are impossible.

It is assumed that those tickets will be awarded by the House to the House. In the Proposal, calculations were made based on a pot that is a direct consequence of the number of tickets. But if the number of tickets includes tickets that were not paid for, either the pot will shrink or the House will end up needing to pay for the tickets. Such is life.

In fact, the House's role here is such similar to that of Casino's poker games. We got a P2P game where the House is just an ordinary dealer, not a player itself.

LIST • ESCROW providers • Ranking & Scores available!LIST • FOSS BrainwalletsBTC ⇆⚡⇄ BTCBTC aka BTC: 16MBvhaJoRBxW3Vk6apnvz3UYT9HAgraVS ⚡ PGP: 2680207AA9A1B69FE7A033D80DE0F221074384C4 ⚡ If you think freedom matters, please support the development of these privacy projects→DONATE some sats: TailsQubes OSWhonixVeraCryptPicocryptKryptorSimpleX Chat
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!