Introducing PevPot.com The Bitcoin Lottery

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

[1715276723]

1715276723

[1715276723]

1715276723

[1715276723]

1715276723

[1715276723]

1715276723

[RHavar]

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

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.

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

[TwitchySeal]

Seems like a cool idea - Sent 0.025, then went to register/sign my address and got the "coming soon" message.  Will this be ready for the draw?

Here's the transaction though (my address as also tagged on blockchain.info)

https://blockchain.info/tx/6d76aa4d3684fd392d71f271b44f7fce26368933368b5a86c979c434a91eb7e6


 Address: 1JqxhKj4CdRqFb7mGdXVMYTMy1MQ5qShsn

(also, initially I accidentally sent 0.000025 BTC because my wallet was set to mbtc and I wasn't thinking, that one is still without verification - even though the fee was more than double the send amount haha.  I sent 0.025 BTC a few minutes after)

Thanks for sharing this over at betcoin dooglus

[RHavar]

Seems like a cool idea - Sent 0.025, then went to register/sign my address and got the "coming soon" message.  Will this be ready for the draw?

Here's the transaction though (my address as also tagged on blockchain.info)

https://blockchain.info/tx/6d76aa4d3684fd392d71f271b44f7fce26368933368b5a86c979c434a91eb7e6


 Address: 1JqxhKj4CdRqFb7mGdXVMYTMy1MQ5qShsn

(also, initially I accidentally sent 0.000025 BTC because my wallet was set to mbtc and I wasn't thinking, that one is still without verification - even though the fee was more than double the send amount haha.  I sent 0.025 BTC a few minutes after)

Thanks for sharing this over at betcoin dooglus

Awesome, thanks for playing! Yeah, actually the register thing is already working, just the page is just so ugly that I didn't publish it. I'll release it with the next update =)

[RHavar]

Thanks everyone for their input on how to best mitigate the big-miner-withholding attacks, and think I've come to a pretty good solution:


The draws ends on xxxx000 blocks, but we wait until the subsequent xxxxx006 block to use the hash for the draw. With the xxxxx006 block hash, we apply the following time-wasting function:


PBKDF2 set with:
  hash-function:  sha256
  password: the xxxx006 hex-encoded block hash
  salt:  'pevpot'
  iterations: 5,000,000,000
  output:  256 bits

(Code will be provided for this, included some that you can run in the browser in javascript).

The output of this function will then be modulod by the amount of non-dust satoshis sent to the address during the draw. Transactions sorted by their txid, and then the Nth satoshi pick.


I'm updating the provably fair and the code now =)

[katerniko1]

i need to say that this sounds interesting just from reading +EV lottery you got my attention at that
so i will try it for sure.
regards.
-Katerniko1

[Coef]

Very interesting idea. So basically the more the players gambled, the less positive the EV becomes.
I will surely join it when the provably fair system is finalized.

The Bitcoin Lottery
draw #1 ends in 869 bitcoin blocks (#1233000)

I see on the above on the page, but what does that #1233000 stand for?

[RHavar]

I see on the above on the page, but what does that #1233000 stand for?

Bitcoin block number 1233000



(BTW, I really appreciate all these questions as they help me understand what's not clear about the site to improve it. I got a lot of work cut out for me )

[Coef]

I see on the above on the page, but what does that #1233000 stand for?

Bitcoin block number 1233000



(BTW, I really appreciate all these questions as they help me understand what's not clear about the site to improve it. I got a lot of work cut out for me )

Not sure if I am understanding you correctly there, but the current bitcoin block height is 383134, shouldn't the draw 1 end in block 384000?
BTW, it will take roughly 16 years to get to block 1233000. I am not sure I want to keep my bet stuck for that long lol.

[RHavar]

Not sure if I am understanding you correctly there, but the current bitcoin block height is 383134, shouldn't the draw 1 end in block 384000?
BTW, it will take roughly 16 years to get to block 1233000. I am not sure I want to keep my bet stuck for that long lol.

!! Wow, I never noticed. Major brainfart on my part.



I had hard-coded a mock value in early development, and forgot forgot to replace it with the proper value. With next push, that will be fixed.  

As thanks for pointing that out, I'll give you 0.1 BTC in tickets. What address would you like it to go to, if you win it?  


 

[Coef]

As thanks for pointing that out, I'll give you 0.1 BTC in tickets. What address would you like it to go to, if you win it?  

Oh thanks. 1DnAp7MfiGEkT7MknroXfpgDwP4bM1XwCC please.

[RHavar]

Oh thanks. 1DnAp7MfiGEkT7MknroXfpgDwP4bM1XwCC please.

https://www.pevpot.com/registrations/7182f4d2-f26f-4400-976c-7b546977763a

If the 0.1 wins (tx aa02a98b2dada8c3e3f5cf1ccc7a2f0ea1cc2cfaecc4e3be4f8df51a92505cb8) you'll get your prize automatically sent to you without further action required. Good luck!

[Coef]

Oh thanks. 1DnAp7MfiGEkT7MknroXfpgDwP4bM1XwCC please.

https://www.pevpot.com/registrations/7182f4d2-f26f-4400-976c-7b546977763a

If the 0.1 wins (tx aa02a98b2dada8c3e3f5cf1ccc7a2f0ea1cc2cfaecc4e3be4f8df51a92505cb8) you'll get your prize automatically sent to you without further action required. Good luck!

Nice.



I notice a small issue while I check the link. When I view it using Firefox, the text goes beyond the gray box and I am unable to read the complete message.
Screenshot using Firefox:



When I view it using Chrome, the word wrapping works perfectly.
Screenshot using Chrome:

[RHavar]

Whole bunch of improvements and fixes pushed out, including the finalized new provably fair which should now be robust against miners who withhold blocks or withhold transactions =)

https://www.pevpot.com/provably-fair



Criticism encouraged, and before the actual draw I'll be releasing an independently runnable tool that gives you the draw and winner results =)

[RHavar]

Our first video review:  http://www.youtube.com/watch?v=6dvbRH2P5j0&t=6m10s !

[dooglus]

Criticism encouraged, ...

"Provably fair betting means that we give you a hash of the bet outcome before you make the bet to prove that we did not cheat."

That's presumably copy/pasted from one of your other sites. It doesn't apply to this game.

Frequently Asked Questions

What is my chance of winning

Needs a question mark at the end. Same for other questions - a few are missing question marks. And "How many confirmations needed" is missing an "are".

"The draw actually ends in the xxxxx000 block" - I'd use 3 x's, since block numbers are 6 digits at the moment, and will be for years to come.

"There's quite a few reasons for this" - there is reasons?

[dooglus]

PROVABLY FAIR DETAILS
...because you shouldn't have to take our word for it

The pot starts with 90% of the money that sponsors sent during the previous draw (10% is kept for running the site).

It occurred to me (since this is the first thing listed on the provably fair page) that we can't be sure you're not keeping more than 10% of the sponsor money.

I see "Thanks to our sponsors for putting 0.17658 btc in this draw's pot!", but I can't tell how much each one paid you for you to arrive at that total. I expect I could go through the sponsorship pages one at a time (https://www.pevpot.com/sponsors/1, https://www.pevpot.com/sponsors/2, etc.) to check it but that's kind of a pain, especially as the total number of sponsorship pages grows.

Every satoshi sent to the lottery address during the draw blocks are given 1 chance of winning

Two things: it's not *every* satoshi. It's only the ones making up big-enough payments. There's a dust threshold.

And every one *is* given, not *are* given.

Point 5 is missing a trailing period.

Point 7: some people might not be happy signing a message saying something as ambiguous as "pevpot". It's best practice to be explicit about what a signed message is for. For example I might like to state that the signature is for the sole purpose of claiming a pevpot.com win, and is not to be considered as proof of ownership for any other purpose. Or words to that effect. Maybe you can allow the "purpose" field to be free text so long as the first 6 characters are "pevpot". Or maybe I'm just running out of nits to pick.