Topic: Introducing: The Amazing Anonymous Bitcoin Lottery - page 9. (Read 43775 times)

But what about in the long run? You don't want to see very large jackpots there?

You are the ones in charge though, if you prefer blend down to rollover I'll just do it... but read my previous post, might be a good middleground.

Right, in a nutshell keep the 3^16 until we exhaust most of the betting space. Raising the ticket price is actually a great idea, funny how it didn't ever cross my mind. I thought about lowering so people would buy more tickets thus improving their chances of winning, but the pots would invariably be smaller.

I'll adapt the code to cope with different ticket prizes, and open the next draw. I'm inclined to go 78000 / 5BTC *if* the first prize gets moved over, and 78000 / 2BTC if someone wins it.

For now it's ok to experiment, but I want this automated so I need to get a set of rules down. As before, everyone's help is appreciated:

- make draws at 1k block boundaries for primed pots, 2k for empty ones
- 1k draws @ 2BTC, 2k @ 1BTC
- If the pot reaches *SOME_NUMBER_HERE* a special draw, at the next 0.5k boundary is held with tickets @ 5BTC, where the total pot is guaranteed to be distributed like this:
  - For every prize without winners that amount is distributed by the prizes with winners, keeping their relative proportions
  - for example a 1000BTC prize pool would pay 500 to 1st, 240 to second, 240 to third. If there is no second the 240 get divided 162 / 78 added to 1st / 3rd.
  - with the same base as above, no first prize would add 250 to each 2nd and 3rd prize pools

What do you think? What could the *SOME_NUMBER_HERE*? Should we do time span instead?



Was just trying to be sarcastic. No web server is ever fully secured, and in this particular case I only have the basic walls, I'm not being paranoid. Well, not about penetration, but the hardware failure does get me kind of nervous, after the story of the lost 9k BTCs, so there I'm maybe a little over the top, with RAID10 + on site backup + off site backup. But hey, today it's 120 BTCs, which I can cover from my (virtual) pocket, but tomorrow...

That's a pretty good idea, I think I prefer it to the rollover.

Maybe if there is no 1st place winner, the 1st place win pool goes into the 2nd place win pool. If no 2nd place winner, down to 3rd place, etc. This might get more people in invest in the lottery in the early stages, rather than just wait until there are thousands of btc up for grabs, and not such a losing proposition.

I don't know how much various actions hit your server. Maybe before going to 4^16 bet space you could do 2-5BTC tickets, that would keep the number of tickets in your database low, while still being affordable for pretty much anyone to buy a few.

I think 2-5% to charity is good, and I prefer cycling through the best ones as opposed to choosing less and less worth ones over time (like someones blog).

I like a draw every 1000. You could make it longer when there is no rollover. Tickets are a better deal when there is more in the pot, so it will attract bets faster when there is seed money. It might make sense to let it grow for longer whenever it starts from zero.

It could be synced up next time to go at block 78000 then every 1000 from there, but go 2000 if the pot was emptied out after last draw.

I'm a bit confused. Why do you say it isn't secured properly? Isn't that kind of an important thing to fix?

Not any more, right? I'm experimenting with mongodb replication, which implied a db server restart, sorry about that.

I love this idea.. but, the site is down. .

Right. I don't think we can hold the 3 character bet for long, if this ever picks up. That's a 4096 values bet space, so if we ever exhaust 50% of that, I guess it's time to move on. I would probably go for cheaper bets, less probable hits, but I can understand that not everyone thinks like that.


Yep, I think alike. But I didn't make the lottery so people can donate, it's more like touching the greedy bone of people (even if they then get the rewards and distribute to whoever, it's their bitcoins). Everybody likes to win, and while greed is a big problem in the world today, that is only because it's misdirected. There's nothing wrong with wanting to win the lottery, and if you do, what you do with the prize actually tells more about yourself that "it's better if I just donate my 10 bitcoins to someone". In my personal opinion, that is.


I don't know if I understood your proposal, but I don't care for it too much. If you win the bet you get the prize, so then you can give it to anyone, it's up to you. Why should that be part of the framework? Unless, of course, I was to get rid of the bounty purse and just use that, but I honestly am very fond of the bounty purse


This is not 'my site'. I designed it so I could try some new stuff, specifically mongodb and the tornado web server (*) and it is just fun to keep. The problem is I take my pet projects very seriously and I don't just want to put my own view of how things should be in there. Please keep giving your opinion, I need it!


(*) Yes, there is no sql injection path here. Just thought people should know as someone lost some time trying that a couple of days ago. There are other paths into this system, as it is not secured properly, so have fun trying

Hmmm, I could get a BTCIN that would have a BTCOUT to whatever charity, but that would only pay if one of the bets wins. That's what the bounty purse is all about. The more we bet, the more goes to the recipient. I unilaterally decided for the faucet on this one because that's where my first 5 bitcoins came from. And I have worked closely with mtgox, made a little profit I must say and have put an ad to them because I like their work very much. So next up is mtgox, I guess.
Also, because the default client doesn't allow checking the block hashes, I asked Bitcoin Watch to add that to their services, and that is apparently going forward. An independent way for users to check the hash I post as lottery result is the correct one. So they are next in line for the bounty.

In a nutshell:
- Bitcoin Faucet
- MtGox
- Bitcoin Watch

I would really like your input on two more things:
- Is the 6 day (1200 blocks) between draws a good choice? If I make them daily, the prizes will probably be too small. If I make it monthly, I guess people will loose interest, but I could make it every 500 blocks, or 1000, or whatever... what would work best, in your opinion?
- The 2% for bounty arrangement was just a number. I actually wanted to go 10%, but thought that would take too much of a slice from the prizes. Given people's inclination to donate, maybe I could go up? Or as an extra provide, I don't know, 50% of the unclaimed prizes to the bounty purse, and the other 50% are added to the next draw?

Keep in mind that if we start having big bets I'll need a real server, and that costs money, so unless someone donates a VPS somewhere we'll probably need to considers factoring that in too. I can keep the system as it is indefinitely, but there will be regular downtime (yesterday it was off for an hour, due to an IP change). I'll gladly donate my time to keep the thing running and updated.

This has been a lot more fun than I thought it would be

I just made a 5 bitcoin bet for the charity. All proceeds from these bets go to the faucet:

fff
ffe
ffd
ffc
ffb

If you created a charity acct with random picks, I'll do that in the future.

What he said

It's looking so good!

I'm getting excited for the first draw. 600 blocks to go if we average 9/hr from here out that's only 3 days!

The faucet is a good idea. I think we should do MtGox on a big one, or for several or something. A tight market is pretty much the most important thing for bitcoin right now. And we're only getting it because he wrote good code and takes PayPal risk for no profit right now.

Oh, 1btc is small enough imo. If you go much lower than a nickel I won't get excited ;-)

If the value of BTC increases by a lot then obviously revisit the issue. You could even have different size drawings occasionally. Though I suppose it would get weird with the rollover pools and whatnot.

Yes, it is 'unlikely' because he only has 20%. According to my (very suspect) calculations freezing 2 blocks before gives him a 4% chance. So it's not like something he can just do and it'll work, but if he tried all year he might get it to work once. I'm just saying freezing an hour before isn't unreasonable and that makes it more like .0064% instead of 4%. And this will be reduced even more in the future by the dispersion hashing power.

Right now duplicates appear twice, meaning you can assert exactly how many tickets have won by keeping a copy of the bets from before the result is out. I've now put the numbers you own in bold (I'll add an underline later) so you can easily see if there are dups amongst your bets.

If to that I add a download link once the draw is locked, would that be enough to prevent me from cheating? I don't see any other safe way taking advantage (bar stealing the actual bets).


I didn't think that was possible. As the difficulty makes the average ~6 blocks per hour, even holding 20% of the CPU power you can be pretty sure that without those 20% the network would still resolve ~5 blocks per hour. But I'll take your word for it, and honestly I added this locking not to avoid that particular race, but to prevent people from canceling all their bets just before the result, something that would be very hard to explain to other betters: "I don't know where all the money went, it wasn't me, I swear"

Having said all that, I'm targeting one draw per week so holding back 3 hours / 18 blocks would be just fine. I have this idea of, once the system is tuned, making a lower bid, faster turnaround set of draws, say .05 per bet, 2 days, to allow people that just get some from faucet to at least feel a little thrill, but its all about critical mass. The site has been having wonderful reception, but it needs to hold a good number of "returning gamblers" to make it fun.

I'm very impressed by the speedy improvements.

The claiming a duplicate is a pretty easy fraud still. Maybe just put the number purchased in parens after the ticket number if it is not 1.

Another thing:

ArtForz may have up to 20% of the power which means he would be able to know the winner 2 blocks before about 4% of the time. As other people get good code for GPUs it'll be less of a threat. I don't have any reason to think he'd do this, just trying to help make it robust. Making it 5 blocks would be pretty solid vs 20% power. In case it's not clear I'm suggesting he could solve 76774, not release, work on the 76775 early, learn the winner, bet, then release both 76774 and 76775 and win. Wait, even if 76774 is solved while he's working, if he gets a 76775 based on his 76774 then when he releases them it will be longest and accepted. So does he get it 20% or 4%? Either way, not so secure.

Edit: if bets are locked when you hit 76773 then an attacker needs to build a 76773 also, that makes it 4%.

In theory, when there are two block to go to the draw, all is locked up, including the pending ticket acquiring. So it should be safe. If confirmation of the deposit comes after the draw is locked, it simply goes to your account balance, and the pending tickets stay that way.

If I deposit 1btc 4 blocks before the draw, and have a ticket pending, will there be an issue? Not sure of when tickets become final.

Random bets are now unique on the whole draw, until there's only 5% of bet space left, at which point it just takes any number.

You can see the bets for the draw in the details page. I added a blank when bets are not in sequence or duplicated, to indicate a 'hole'. I'll try to make that downloadable once the draw is locked, so everyone can verify the prize distribution when the result block gets issued. I think that's as much disclosure as it is possible, but if you'd rather have some more information, speak up.