> Currently the lottery has a 25% cut of the total amount in the lottery. This is used to pay for development, server costs and maintainence. Eventually, my goal is to decrease the fee to as small as possible to allow for the largest winning. This will take place when the development stops (meaning there are no features to be added) and/or the lotteries take place more often.
I find this to be backwards, you are effectively punishing your early adopters. It seems to make much more sense to make the cut lower (or zero) now, and increase it later when you have more users.
It's a good idea but any cut above this will make the lottery very expensive. National lotteries can pay out 50% because they have a monopoly and the remainder usually goes towards a community project.
I will probably increase fees (nothing to exorbitant) to covers costs if this takes off. I don't think it will require to much to run unless it becomes insanely popular. At that time, I will open up more lotteries for different payout ranges to make it more beneficial for costs.
I noticed you have changed your fee. The example in how it works still reflects the old rate. Just letting you know. Nice project BTW I'll give it a shot next time I get some BTC.
And the winner is... Anonymous Coward 961! Who is absolutely not the operator's secret alter-identity! Now if you'll excuse me, this yacht won't buy itself.
I don't know whether this is actually a scam, but you need to put a considerable amount of work to make into making it not look like one. As it is, I see: disposable identity, Bitcoin, and a straightforward opportunity to steal without getting caught.
Of course, you could just watch who the payment is made out to and verify if the owner is the winner. I could show the selection method of the winner and show that it is a random generator that grabs the winner. Either way, its still a gamble. If you don't trust the site (or me) then you won't trust any of the code I post to show the random selection of the user.
This is progress, but it doesn't look done yet - you need to explain how someone would perform the verification, and why prior knowledge of the seed won't let someone manipulate the results by placing strategic bets.
There are already at least hundreds of bitcoin lotteries and casinos, most of which are probably scams (see bitcointalk.org forums). How do you plan to differentiate?
No, it's LEGAL problem. Another profitable enterprise is to take up drug smuggling -- it pays fairly well (so I am told) but being illegal is a bit of a problem for most people.
Actually under the paid out today number you could have a little hyper link that says "verify" and links to the blockchain showing the actual payouts. It might give you some legitimacy.
If I could prove the fairness (paying out to the winner) without compromising anything, I would. If you know of a way, I would be more than willing to do so.
Here is a simple algorithm that gives you the basic ideas. A different bitcoin wallet is set up for each day's lottery. The total number of bitcoins received can be seen in the blockchain. A source of entropy is chosen which can easily be verified but cannot be controlled or predicted before a date after the cutoff for that day's lottery, for instance, use the NYSE stock market closing price. A hash of that is divided by the number of bitcoins received in the lottery (plus an overhead for the small percentage that funds running the lottery) to determine the winner.
Anyone entering can confirm that that their contribution was a certain percentage of the total funds received and that they had that same percentage of the chance for winning: even if the operator of the lottery wanted to be malicious they couldn't do so without making it obvious to anyone who checked.
There are some additional details that would matter, if you wanted to implement this seriously you may contact me separately for a discussion of some of those details.
I already have some of this implemented but, picking a random winner based off of an outside source (provable by providing the algorithm) is only trust worthy if you trust the author posting the correct algorithm. You would still have to trust that I was using the code I said I was using.
I may be understanding you wrong, and if I am please let me know. I would love to make this 100% fullproof and trustworthy.
Publish the algorithm. Anyone who wants to check can run it themselves!
For this to work, ALL of the data needed to run the algorithm and determine the winner must be data that is outside the control of the contest organizer (or published before the contest begins) and publicly available. The algorithm I described should meet this criteria.
Assume you have published (before the contest starts) that the lottery itself takes a 1% cut, and that all funds should be deposited to a particular Bitcoin wallet. Anyone who is suspicious of you (or just very careful) can inspect the blockchain to see the total number of bitcoins received before the contest cutoff time (call it "N"). They can find the closing price of the NYSE and run it through the hash function to find the random input (call it "R"). Then they can perform "X = (N mod R)" and count through the transactions until they find the one that added the "X'th" bitcoin to the wallet. If that was their transaction then they know to expect to receive "0.99*N" bitcoins. Like I said before, for rigorous use, the algorithm needs some details and a little improvement, but this demonstrates the existence of algorithms that allow any participant in the lottery can verify that the lottery is fair.
Here is an alternate algorithm, based on mcherm's suggestion. Choose a publicly available number, such as NYSE closing price, that is not revealed until after the lottery closes. The hash of this is the target. The exact format of what is hashed is announced in advance.
All purchasers' bitcoin addresses are posted publicly, in the order they come in. They are salted with the ticket number, i.e. mybitcoinaddress-001 represents the first ticket I bought. All of these addresses (including salt) are hashed. The one that is closest to the target is the winner. Closeness can be measured as integers (absolute value) with ties possible but extremely unlikely.
I'm curious--how many here would work on this kind of project? I'd love to from an engineering point of view. It would be quite fun.
However, I suspect it will be a net detriment to its typical user, and don't see any real benefits to counteract that, so would have trouble working on such a thing due to the moral issues. People who like to gamble and are able to do so responsibly already have plenty of easy outlets in which to indulge their hobby. It seems to me that this service will disproportionally attract people who have a gambling problem, and I'd feel quite troubled helping with that.
Just to send out an update on the site. Fixed quite a few issues today. Thanks for the help everyone. One of the big things was changing the fee to 1% to help pay any transaction fees and make sure early adopters win almost all of the lottery. Another was the incorrect display of # of tickets purchased and amount of bitcoin in the pool. This has been fixed with no loss of data and there is now more bitcoin showing up in the pool.
I couldn't figure out how long the current lottery was going to run. I didn't see what the target # of tickets sold was for this first round, so I didn't know what the estimated date of the first drawing was.
On your lottery page, I initially thought the addresses listed in the grid were the ones to send bitcoins to. You should really consider laying out that page differently to avoid confusion.
The problem I think is that the bitcoin address to send money to looks like its part of the table header description. So you naturally gloss over it and focus your attention on the table data.
The implementation is really simple. Buy 1 BTC at current prices. Wait a year. Now your 1 BTC is either worth 1000x as much (with low probability) or nothing (with high probability). Instant lottery!
I find this to be backwards, you are effectively punishing your early adopters. It seems to make much more sense to make the cut lower (or zero) now, and increase it later when you have more users.