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

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.

I'm a bit of a sucker for simplicity, so I do like the idea of "winner takes all". Provably fair doesn't imply that you're probably going to win, it just means that you can verify it's fairness. =)

(i.e. For $1 if you have a 1 in a million chance of winning a million dollars, you're probably not going to win .. but it's still fair)

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. But if there's any problems with the winner signing a message, I'm more than happy to work with them to make sure the money arrives in the right hands. The point of the signed message isn't to be an obstacle, it's designed to stop mistakes =)

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

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:




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.

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

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

Thanks for the proof-reading Dooglus, I'll pushed up some fixes  


This is quite interesting, as it's basically like having a "server secret" that I don't need to worry about losing. But if the amounts in the lottery are sufficiently large that this is an issue, I believe the issue of "pevpot colluding with a miner" would be problematic. So I would steal lean towards a function that took an hour of computation time to verify (and compute initially). 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 =)

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!

The best I have for now is just "bcrypt with millions of iterations". The nice thing about this, is you can't parallelize it, which means you can make a very good estimate of the amount of time it would take to solve. Even if it took people ~30 minutes to solve, it'd be a bit inconvenient to verify, but not show-stoppingly so.  


Thanks, I'll add this. As long as it gets confirmed on or before the draw hash, it counts. If it doesn't get confirmed by the draw hash, it'll just be part of the next draw. (I will reuse the lottery address, specifically for this reason)


In the case of reorgs, the hash is used from the chain with the most work. No payments are automatic (the lottery address is part of my cold wallet) and won't be sent immediately (I want to give people time to verify the draw outcome before I sent payment) so it won't really be an issue. Worst case is someone will think they won, then there will be a re-org and a different winner is picked =)

(I believe this is really the only way to do it provably fairly, otherwise if there was a block race it's not possible for me to prove I saw X before Y)

This is something I've been thinking about. There exists a certain point where if you had a miner with a sufficiently large percent of the bitcoin hashing power, and a sufficiently large amount of a huge pevpot draw, they would be ncentivized to discard their solved block (and lose 25 btc) rather than lose the pevpot draw. When this become a remote reality, I think I have a nice idea for how to solve for it:

Instead of using the blockhash directly, apply an extremely time-consuming function on it.  Something that is not parallelizable, and would take a modern computer a significant amount of time to compute (e.g. bcrypt with hundreds of millions of iterations). Ideally though a function where verification is cheaper than the original computation. This could quickly make it uneconomical for a miner to check if their block has won or not, as it would almost guarantee their block gets orphaned.

Typo for "with our" 



That's correct.

Thanks for the early sponsors! Locking, to create the main thread now!


Hi guys,

In a few hours, I'll be launching my newest project PevPot.com which is going to be the first ever +EV lottery

The way it works is pretty simple, everyone sends bitcoins to a lottery address and for every satoshi you send you get 1 chance of winning. Every 1000 blocks (~7 days), we use the block hash to find a winner (with our provably fair). So if there's a total of 100 BTC sent, and you sent 0.03 BTC you would have a 0.03/100 chance of winning, and if you win you get the ENTIRE pot PLUS  "sponsorship" money. This means players get better than their the "fair odds" of winning, making it +EV

So what's sponsorship money? Basically a way for advertisers to get noticed. The top 5 sponsors of every draw (it's an auction) are prominently displayed during the draw (and forever in the history). 90% of the money that sponsors pay goes into the prize pot (that's what makes it +EV) and the remaining 10% I get to keep (my business model).

The site will soft-launch in a couple hours (bitcoin block) 383000, so if you want a chance to become a sponsor for the first ever draw now's your chance to throw a few bitcents and make history:

https://www.pevpot.com/sponsor

Images are the same size as: https://thebitcoinstrip.com/  if you need a place to grab one from


(Note: The first draw I intend to be pretty relatively low key, as I want to iron out all the issues with it, and release some independent verification tools and what not)

As long as it can make http/json requests, any programming language is fine. If it's browser-based, you're definitely best off using javascript or something that compiles to it =)

It seems this plan would require the digger to be completely oblivious to what's going on? If it ever looked like his digging was going to be stopped, what's stopping him just digging everything at once? I guess this is mildly better than the current situation, as he'd be forced to show his entire hand but he could even likely start using his clams to vote "digging-allowed" and prevent an overwhelming majority consensus.

I'm not sure I follow your reasoning. Moneypot does massively reduce the barriers to entry (especially when combined with Dan's script) but I'm not convinced that's entirely a bad thing. I mean, no one's forcing you to play at any of them and I don't see harm if someone wants to make a little micro-community they and their friends can hang out and bet.

Also if you remember back to before the proliferation of untitled-dice sites, it was CoinDice sites that were popping up on a weekly basis, which invariably ended with players and operators getting their money stollen. So far, I haven't heard of a single player or operator getting screwed by with this script, so I think the status-quo is a lot better =)

That's correct. I've never looked at tothemoon's deposit code but bustabit doesn't use blockr.io at all, but rather uses the code from https://github.com/moneypot/bustabit-depositor which itself queries bitcoin-core (over rpc) and directly (through the database) updates users balances/deposit history*. I do not believe there is or has been an exploit in this.

(Personally I'm far too paranoid to trust a third party to tell me abouts deposits)



* The code is kind of shit, I wouldn't advise people to copy it or use it as inspiration if starting from scratch. It suffers from a few design problems, which I've fixed in the moneypot depositor. I've been meaning to backport it to bustabit, but never got around to it.

The house only "always" wins if people infinitely re-gamble all payouts they make. Eventually the house edge will whittle them down to nothing. This is a good enough approximation for a witty expression, but in reality there are a lot of other factors. People can win at the casino and stop playing, or they can win and go somewhere else. Or they can win, and you need to divest. Or they can win and your investment gets diluted so much it can't recover.

I like the forum idea, but the primary reason I took it down was that there's just not enough activity to warrant it. So it's conversation is probably better off here, or maybe forum.bitcoin.com


Just a heads up, I've deployed code that automatically disables the sessions of people grossly abusing the betting api (i.e. parallelizing api calls). It's quite lenient right now (only disables sessions of people who consistently paralleize request), but will get more strict as time comes.  I'll work on creating an acceptable use policy shortly, with some hard limits