Introducing PevPot.com The Bitcoin Lottery

[RHavar]

PevPot.com is a project that I've been working on for a few weeks now, and believe it to be the first of its kind. It's a provably fair lottery where players actually get more out than they put in. Or said more technically it's the holy grail of gambling: +EV

The way that it works is pretty simple, each draw is sponsored by a number of advertisers, who make this possible. 90% of the money the sponsors pay goes directly into the prize pot (we keep 10%). 100% of the tickets players buy go into the prize pot. For every satoshi you send, you get 1 ticket. And every 1000 bitcoin blocks (when it ends in 000) we draw a winner (in a provably fair way, of course).

For more details, please see pevpot.com.

(Also a big thanks to our sponsors who with only a couple hours notice helped make the first draw happen.

I look forward to your feedback. Please buy tickets, share with your friends and support our sponsors who make this possible!

[dooglus]

So I was thinking about the provable fairness, and how to prevent the miner from gaining an edge by withholding his block if it causes him to lose.

If a miner has a sufficient amount of hashing power, and a sufficient amount of pevpot tickets and the pevpot prize pot is big enough it could theoretically be advantegous for a miner to discard a valid bitcoin block if that block would to them losing the pevpot draw. If this theoretical attack looks like it could be a concer, the most obvious fix would be to change verification to be an extremely time-consuming process (e.g. bcrypt the block hash with millions of iterations) so that it would be infeasible for a miner to check if their block won or not (without getting orphaned). If you have any ideas for this, we'd love to hear your input on the forum.

I bolded some typos.

I'm trying to think of a method that prevents the miner from instantly knowing whether his newly solved block results in him winning the lottery or not, without also making the verification of the provable fairness overly burdensome for the players. The bcrypt idea above has the problem that everyone attempting to verify the result also has to run millions of iterations of bcrypt.

I came up with this:

You know how it's really hard to go from a Bitcoin public key to a Bitcoin private key (like *really* hard), but very quick and easy to go the other way... Could we use the same idea but made easier to solve this problem?

Instead of using the secp256k1 curve that Bitcoin uses, use a 48 bit curve or some such, and treat the last 48 bits of the miner's block hash as the public key. Then the proof-of-work to determine the winner involves searching for the corresponding 48 bit private key. Once found, append the private key to the block hash, hash the result, and that's your 256 bit value for deciding who won.

The advantage of this method over the million-bcrypts method is that it takes no work for anyone to verify that the private key matches the public key, but it takes a lot of work to go the other way.

Oh, but it has two problems:

1) the search is easily parallelized - so someone with a lot of hardware (a miner, say) could search quicker than others
2) I'm not sure that there's any guarantee that there's only one private key for each public key

I wonder if it's possible to find a solution which isn't able to be parallelised, takes a long time to solve, but no time to verify.

http://crypto.stackexchange.com/a/9331 looks promising. It gives us:

* slow for the miner to compute
* quick for the users to verify
* not possible to parallelize

but with the disadvantage of the pevpot site having to keep a secret until after the draw, and being able to cheat (by removing the slowness) if it colludes with a miner

[BTC Tipster]

Nice project, fix this  https://www.pevpot.com/how-to-play
It shows provably fair box twice.

Good luck!

[dooglus]

More typos:

"This can only be done from a bitcoin wallet which you can both receive and sign a message from the sending address" -- you mean "with which ..." I think. But even then that's a confusing sentence.

"for every satoshi sent, is one chance of winning" -- that's not grammatical either

"So lets say you send 0.01 BTC" -- "let's"

"This transaction is the wining transaction"

[gampher]

i dont understand the " signing message " thing ?
why would you require it ?

[RHavar]

Nice project, fix this  https://www.pevpot.com/how-to-play
It shows provably fair box twice.

Good luck!

Each column is supposed to be a different way of playing. But seems that page is a bit too complex, I'll totally overhaul it tomorrow =)

[XinXan]

So how does the +EV work exactly? For every satoshi I send I get 1 ticket but anyone can send any amount and there is no limit so my chances of winning will always be variable, right? How can you know if it's going to be +EV if everytime im going to have different chances of winning?

[gampher]

i dont understand the " signing message " thing ?
why would you require it ?

I cover it here: https://www.pevpot.com/faq#signing

But a huge reason is help protect people from themselves, while still being provably fair.  Actually already someone has played the lottery directly from their bustabit account (instead of using the forwarding feature). If I blindly returned money to the sending address, it'd end up in someone else's account.  Now if that transaction wins the lottery, I can actually take the time to sort it out. For instance what I'll do on behalf of the user is generate a signed message from the sending address which direct proper payment and then I can then publish the signed message (so you can verify I sent to the right spot).

yeah but why would people send it from their bustabit accounts ? i mean they clearly cant sign a message from there.
you can restrict them to use only home wallet's or blockchain ..etc.
people lose their wallet and addresses many times and also export keys for several reason's .
it's tricky .

[RHavar]

yeah but why would people send it from their bustabit accounts ? i mean they clearly cant sign a message from there.

Yet people will do it anyway. I've probably had >25 support tickets from people withdrawing from their bustabit accounts to on-chain gambling games like satoshidice / satoshibones / lucky.bit even despite:

you can restrict them to use only home wallet's or blockchain ..etc.
people lose their wallet and addresses many times and also export keys for several reason's .
it's tricky .

In all those cases, users should be able to easily sign a message and direct payment of the prize if they win (including direct to their cold storage).


The idea is that the weekly prize amounts are supposed to be significant amounts of money, and I don't want to blindly send them hoping they arrive in the right spot. It also allows me to do the forwarding-addresses (pevpot.com/play) more efficiently, because when I generate the forwarding address I immediately sign (and save) a message directing proper payment.

[RHavar]

So how does the +EV work exactly? For every satoshi I send I get 1 ticket but anyone can send any amount and there is no limit so my chances of winning will always be variable, right? How can you know if it's going to be +EV if everytime im going to have different chances of winning?

Because for instance in this draw (#1) the prize is always going to be 0.17658 BTC more than players put in (thanks to the sponsor). So as more and more tickets are bought, the EV will get closer and closer to 0 but it'll always stay positive

[gampher]

The idea is that the weekly prize amounts are supposed to be significant amounts of money, and I don't want to blindly send them hoping they arrive in the right spot.

but it might be a problem if the user wins and is not able to sign a message ....or the alterative could be that the user can sign a message from the sending addy in case of any loss of wallet or addy's, In that case you need to remove the date and time thing .
however it is lesslikely to happen but it is possible.

[XinXan]

So how does the +EV work exactly? For every satoshi I send I get 1 ticket but anyone can send any amount and there is no limit so my chances of winning will always be variable, right? How can you know if it's going to be +EV if everytime im going to have different chances of winning?

Because for instance in this draw (#1) the prize is always going to be 0.17658 BTC more than players put in (thanks to the sponsor). So as more and more tickets are bought, the EV will get closer and closer to 0 but it'll always stay positive

Oh I see, so basically if I were to play alone no matter how many bitcoins i send the sponsors are always going to send more. Seems pretty nice, hopefully it's +EV for you too in the long run.

[gampher]

but it might be a problem if the user wins and is not able to sign a message ....or the alterative could be that the user can sign a message from the sending addy in case of any loss of wallet or addy's, In that case you need to remove the date and time thing .
however it is lesslikely to happen but it is possible.

If a user is not able to sign a message, they should be using the forwarding feature (pevpot.com/play) which does it all automatically for you.

sounds quite comfortable than the previous deal, there should be an alternate always.

[Joel_Jantsen]

How come its probably fair when you choose only 1 winner ?If 1000 people buys tickets and only 1 is winning then the probability of win is almost 1/1000 which is completely random .You should have atlest first seocnd  and third place winners as well

[ndnh]

How come its probably fair when you choose only 1 winner ?If 1000 people buys tickets and only 1 is winning then the probability of win is almost 1/1000 which is completely random .You should have atlest first seocnd  and third place winners as well

It is provably fair lol.

It means the lottery result can be independently verified, that is, the fairness is provable.

[dooglus]

Oh I see, so basically if I were to play alone no matter how many bitcoins i send the sponsors are always going to send more.

No, the amount the sponsors add is fixed before each round begins.

This week the sponsors are adding 0.17658 BTC.

If you play alone, and bet 1 BTC, you get back 1.17658 BTC. That's 0.17658 BTC more than you bet.

If you play alone, and bet 1000 BTC, you get back 1000.17658 BTC. That's 0.17658 BTC more than you bet.

See how that works? The prize pool is bigger than the sum of the bets by a fixed amount, so the game is +EV to play.

Seems pretty nice, hopefully it's +EV for you too in the long run.

The game itself is +EV for Ryan, since he has no risk and gets 10% of the sponsor money. But then he has to pay for hosting and other expenses out of that. I would guess there's quite a low cap on how much people are willing to pay as sponsors, and so quite a low cap on Ryan's take from the site. I can imagine the pot itself growing quite large, and Ryan making very little from it. But ass we see from bustabit he's probably happy taking a small amount.

[dooglus]

I've spent a while looking, but haven't found a function that satisfies:

* Is not parallelizable
* Slow to compute, fast to verify
* Offers no collusion possibility (i.e. no server secret)

any 2/3 however seems easy =)

I think you should probably have something in place asap despite it not being perfect.

The pot size could escalate very quickly towards the end of the week.

Imagine someone seeing the current pot of 0.59 BTC and buying 10 BTC worth of tickets to try to make a quick almost guaranteed +EV profit. It only takes one more player to go to 50 BTC, following the same thinking and then you have a pot worth block-withholding to win.

Oh, and it's even worse. As a miner, I see a 50 BTC pot, so I create but do not broadcast a 5000 BTC bet. I try mining block xxx000 including my secret bet transaction. If I manage it, I check whether it wins (it probably does) and broadcast the block if it does. If it doesn't win, I don't broadcast the block, so I lose the 25 BTC block reward, but I never lose my 5000 BTC bet. So in the event that I am able to mine that block, I have a 99% chance of winning 75 BTC and a 1% chance of losing 25 BTC. That's very +EV since I've eliminated the possibility of losing anything but the block reward.

It really does need to be impossible for a miner (or anyone else) to know who won until half an hour after the xxx000 block is mined.

[dooglus]

Oh, and it's even worse. As a miner, I see a 50 BTC pot, so I create but do not broadcast a 5000 BTC bet. I try mining block xxx000 including my secret bet transaction. If I manage it, I check whether it wins (it probably does) and broadcast the block if it does. If it doesn't win, I don't broadcast the block, so I lose the 25 BTC block reward, but I never lose my 5000 BTC bet. So in the event that I am able to mine that block, I have a 99% chance of winning 75 BTC and a 1% chance of losing 25 BTC. That's very +EV since I've eliminated the possibility of losing anything but the block reward.

Excellent observation, and something I missed.  I believe an powerful fix for this would be that transactions in "draw block" are not part of the draw. So in concrete terms, the draw still is decided by block 1233000 however any transactions in block 1233000 are part of draw 2, not draw 1.

A (very large) miner could still use a variant of the attack to privately withhold a xxx999 block with the 5000 BTC transaction, and then attempt to privately mine the xxx000 block but now it's getting much, much harder (with a larger penalty for failure).

Why not just make it that bets need 5 or 6 confs to count, effectively eliminating this attack completely? So bets in block xxx996 to yyy995 are in the zzz000 draw.

I'll do some benchmarking on a high-end computer, and try figure out some parameters to slow down verification to prevent any  <large minger attack> as well. I'll revise the provably fair prior to 24 hours before the draw, and add a notice on the provably fair page, linking to this post.

Your typos are getting funner.

[RHavar]

Why not just make it that bets need 5 or 6 confs to count, effectively eliminating this attack completely? So bets in block xxx996 to yyy995 are in the zzz000 draw.

Yeah it makes a lot of sense, but I don't like how that would complicate the draw. I think I'd rather have a very difficult to run verification function

[RHavar]

So I think I have the parameters for the draw.

So I'm looking at using PBKDF2. It seems well studied, nice and simple with some already some highly optimized implementations out there and available in pretty much every environment.

PBKDF2 is defined as PBKDF2(PRF, Password, Salt, iterations, dkLen) which I'll use as PBKDF2('sha256', BLOCK_HASH, 'pevpot', 10000000000, 32)

The fastest implementation I could find was openssl, which when compiled with -O3 took about 2h47m to run. With the fastest virtual machine I could get my hands on (c4.8xlarge), I got it running in about 2h1m.


So this should also solve the problem of a miner creating a giant private transaction (and only releasing it if they mine the correct block), as it would mean that *if* a miner does solve for a block that includes their "private transaction" it would incur an **additional** two hours of validation time. A miner could optimistically assume the block wins the lottery and (privately) mine on top of it, but it'd be taking a huge bet that in two hours the network hasn't caught up or surpassed it.