[BITLOTTO] Mar 1 draw over $2000 or 50BTC! Tickets now 0.1 BTC for Apr 5

[Otoh]

I vote announce & start that any amount may be sent & what's not divisible by 0.25 coins (the last left over bit) goes in to the JP tip jar starting with next week's May lotto (to keep things simple this time, as we've already had the one major change this month to accept multiple 0.25 bets in one tx) & I confirm that I shall be seeding it with 100 coins on day 1 or sooner if bitlotto sends me the address beforehand which he said that he's going to do

Second.  The 1% rake is fantastic.  This will keep the rake the same but give bitlotto a bit more - either on purpose or by accident.

actually I meant for any over-payments portions to go to the pot as bitlotto said; it keeps the total received = jackpot, so nice & simple, but I'm cool with them going to bitlotto as a tip for vanity amount bets etc also

edit: jackpot now plenty enough for a BTF Lab's BitForce Single  

[finway]

This is really facinating lotto ,
just got in this month,
hope this lotto grow to 10kBTCs size this year.

[BurtW]

I vote announce & start that any amount may be sent & what's not divisible by 0.25 coins (the last left over bit) goes in to the JP tip jar starting with next week's May lotto (to keep things simple this time, as we've already had the one major change this month to accept multiple 0.25 bets in one tx) & I confirm that I shall be seeding it with 100 coins on day 1 or sooner if bitlotto sends me the address beforehand which he said that he's going to do

Second.  The 1% rake is fantastic.  This will keep the rake the same but give bitlotto a bit more - either on purpose or by accident.

actually I meant for any over-payments portions to go to the pot as bitlotto said; it keeps the total received = jackpot, so nice & simple, but I'm cool with them going to bitlotto as a tip for vanity amount bets etc also

edit: jackpot now plenty enough for a BTF Lab's BitForce Single  

I get it now JP = jackpot, I was wondering about that.  Either way is fine with me.  I can always send a donation directly to bitlotto.  It is nice to be able to look at the block explorer and see the total jackpot amount (minus 1%).

I cannot decide.  You all decide.  It is not enough to worry about either way.

Whatever is easier for bitlotto - that is my vote.

[Stephen Gornick]

I notice the winner of the last draw (March 7th's) hasn't gone public nor has spent the funds (102.5275001 BTC) yet:

The coins were spent shortly after that post:
 - https://blockexplorer.com/tx/c7cfda90010b1629ace639e3b996cd1eb36473510c9f5ea9c07ee4fb9366b96b#i4919097

But the winner remain anonymous.

That's another difference that differentiates between BitLotto and a state-run lottery like MegaMillions!

[Otoh]

oops BW ty, I forgot the total on BE is -1% for the JP

I think it would be cool if you could commission some Casascius 1 BTC coins with your web site URL around the top www.bitlotto.com that people could use for promotional purposes, tips etc - I don't think that Casascius offers this service as yet but someone should suggest it to him as many companies may wish to have a run of promotional physical Bitcoins made (sometimes maybe on pre-order if that's the right word, so that the run isn't produced until enough people have pre-ordered the total quantity required to make it happen, if there weren't enough orders in by a given cut off date then they just get regular Cas coins, this could also work for limited edition coins) - also he would probably need to have his own web site https://www.casascius.com/ prominently shown first which I'm anyway surprised isn't on the coins atm as far as I can see, around the edge would be good too or a shorted version like http://goo.gl/ajbZb maybe



& this would make a nice round 100 bets coin with www.bitlotto.com URL around the top - great for those little client gifts & perks where you don't want compliance or the regulators to know just how generous you've been 

[bitlotto]

oops BW ty, I forgot the total on BE is -1% for the JP

I think it would be cool if you could commission some Casascius 1 BTC coins with your web site URL around the top www.bitlotto.com that people could use for promotional purposes, tips etc -

That would be sweet. Probably out of my price range though. I think the BTC in my name are in the single digits! LOL. It's the few lucky ones using my service that seem to have more!

Anyways, if the odd chance someone does pay a tiny bit extra (none 0.25 multiple) I'll just add it to the jackpot. Minus the 1% and pay it out. I honestly don't think it will happen that often though. That tiny little bit will probably help in paying any tx fees that occur. I usually end up paying a bit as there are so many tx's being summed together. I'll add a note in the details on my website.

[bitlotto]

Otoh I like the signature! Thanks!

Oh, and I guess it's worth mentioning?, so someone does not try hacking blockexplorer hoping to alter the site to fake the hashes or something, that the hashes come from BitLotto's own wallet itself for determining the winner. Blockexplorer is a great site to check the results though!!!

[Stephen Gornick]

This MegaMillions madness is making me think about the long-term possibilities and risks of BitLotto.

Now since the winning hash is a SHA256 hash of: luckyblockhash+lotterynumbers I am comfortable trusting that a miner won't be holding on to any blocks mined to affect the results of BitLotto because at that time mining that block occurs the MegaMillions lottery results are not yet known.

One risk is ... what if the block isn't solved by the time the lottery starts?  We've had hour plus delays between blocks before.  I'm sure there are several solutions, including reverting to the last block solved before the lottery pick occurred I suppose.  But not having this decided in advance could give someone an argument against the results on the off chance that this actually happens one day.

But the primary question I have has to do with the sha256 algorithm.  The algorithm wasn't built to be used as a lottery picking system.  Generally, using an algorithm for a purpose that it wasn't designed for can expose problems that might not normally exist when used for the algorithm's stated purpose.  Using SHA256 for this alternate approach, is each "pick" truly random?   Or is there some association where, lets say since the megamillions pick can only be 01 through 46 then does knowing that the character in the second to last character position won't exceed 4 mean that the resultant hash will be more likely to result in one that begins with one set of characteristics over another?  

I don't know nor do I think that for the current sub-$1K BitLotto prize is there anyone putting much though into any using characteristics of SHA256 to gain an advantage at BitLotto.   But with MegaMillions at $640 million or some similar number, at some point the BitLotto jackpot could grow to where if there is any gain possible, the incentive will be there for it to be found.

I've no idea the answer, I just wonder to what degree the question has already been considered.

[bitlotto]

One risk is ... what if the block isn't solved by the time the lottery starts?  We've had hour plus delays between blocks before.  I'm sure there are several solutions, including reverting to the last block solved before the lottery pick occurred I suppose.  But not having this decided in advance could give someone an argument against the results on the off chance that this actually happens one day.

Very good point!!! Ya, figuring it out in advance is definitely a must! It would have to be hours of no blocks but I guess it's possible. In that case the draw would not be over. IN the VERY rare chance that occurs, the lottery numbers will come from the mega millions draw that occurs on Friday but with the same time limit for tickets having to be in. Wednesday block time. I'll add a note about that in the details.

But the primary question I have has to do with the sha256 algorithm.  The algorithm wasn't built to be used as a lottery picking system.  Generally, using an algorithm for a purpose that it wasn't designed for can expose problems that might not normally exist when used for the algorithm's stated purpose.  Using SHA256 for this alternate approach, is each "pick" truly random?   Or is there some association where, lets say since the megamillions pick can only be 01 through 46 then does knowing that the character in the second to last character position won't exceed 4 mean that the resultant hash will be more likely to result in one that begins with one set of characteristics over another?  

I have thought about that. I'm really busy right now but I'll tell you my thoughts on that the next day.

[bitlotto]

But the primary question I have has to do with the sha256 algorithm.  The algorithm wasn't built to be used as a lottery picking system.  Generally, using an algorithm for a purpose that it wasn't designed for can expose problems that might not normally exist when used for the algorithm's stated purpose.  Using SHA256 for this alternate approach, is each "pick" truly random?   Or is there some association where, lets say since the megamillions pick can only be 01 through 46 then does knowing that the character in the second to last character position won't exceed 4 mean that the resultant hash will be more likely to result in one that begins with one set of characteristics over another?  

Because it's a sha256 of a random event we can be pretty certain that the hash is totally unpredictable. That's what we really need. A mix of digits that we can't predict. The chance of each digit are unknown until the event occurs. My main reason for adding the blockhash was someone could, in theory, create a list of every possible mega millions outcome and create a hash for it. They could then see if the hashes have certain digits at the beginning occurring more than others. This would give them an unfair advantage as they could manipulate their tx so that a tx hash occurs that has more of those digits. Adding the blockhash makes it impossible to figure out frequency outcomes for winning picks.

The main problem is really with the selection process. I'm actually in the process of possibly slightly altering the algorithm for picking the winner. The important thing is that I do it at least a few days before the draw of course. I hate changing it though, but I think it needs to be done. It does add a *little* more complication to the calculations. The problem with known ticket hashes prior to the draw is people could do frequency analysis of the tx hashes. They could see if by random chance some combinations of digits are not as frequent amongst the hashes. Then get tickets with those more rare combinations. It would be pretty tricky to do but I guess as the money goes up, people will try to get any advantage they can no matter how slim. I'm sure it would be pretty hard to do as the tx's go up there is a lot of tx's to analyze. They would also have to wait till the very end so it would be quite the feat for a very very tiny advantage.  

So, to make it pretty much impossible to do any analysis I was thinking of rehashing ALL tx's!! It would make it harder for others to check the results casually but I'd release a txt file with contents something similar to this for every draw:

Code:

720b8516a286a6588ae636c16e8c550366931620623050b34d9dc0e3856c945c -> c533da9261c21db0bf12d9e6061b10f7652db674a6a0007ec9dfa1b9fe15e219  -
99a38da78eee8132ac2be9d2cbef69df7d81c2adf78423d9c2ee21819f70772d -> 6a4e06c1a1d4bcfd21ddc0bd060a09a92c58334c3aca067106c515beaf7b7bcd  -
.520000
b46482a6f375297e0c2dc74603fb0d455912a6748ca65efd8130a96211e9f36a -> be7baa0fc748e3c44e5cc26f9165ed15fc7da62db3443a6cefbf0cf4986575d8  -
.150000
5ae95246eabb8fb7229db1fcc3aebe258d1a68aae21b4747ecf992a946e902df -> 093c9522b279bf0653304eb33cc9e6b1599199bc413dd647cf99fe604f6d4561  -
9120dec5bfe999743ba3b44d7828dd76196a82cca3486497b74e37fd6a8500d0 -> 198cb6b9ebd194bd79f19fac8b153808b385024929c1cffd320819be4983fa38  -
367b185f2af5d60a72469839d66e07f4c0145a646c48bc6fb2a8304096865266 -> a9a52a45e7252e7e0238f4dc7cdf0f7d6d2ed5a3d4c70e55f9960c103cf1d4a1  -
985ec0242ba5ca7d8af982644eaa056d8e1af8de3bb5c056aa39ae3ff358ab8b -> 7ea9843c17026e2c7681cd1185b4edc32e51aecc4414174cf5082bbfd8aa8b58  -
5b2b7fe513b77bf333b3e202f370699cb914526cdeb49f14b0df78ae16608926 -> 97cfa87250deab7f2d821fc26a7eadb561428f28b1540af51baa22867111994f  -
5dc34f516c14115ce10051f3f73f92892ce704083d22832e4d155f6c87c3abc6 -> 2312b230ae328384202d7b65b7bac25d036a5bd0a86b805c56cffbdf618eac35  -
15ce39e11aecf0a402d2da8bd829cec6505b5fbad023ba8021f663df1d077716 -> 6bdd36da928e20617baa139e0ee6b1c096d891cad8cb5fa2997abc9c7eb4c8cf  -
b67003391d72709ce1b8cf159a7c38e69ce09cc64f8c509fb898dd20af967237 -> 09a63f04c4775eb5976d68df695f679667a59cb68bc07afa889f8539bc2591df  -
1328e3d465132c4b012d44e5d28bff76e6f31566dc87f1e59c593bc94b73da39 -> e767f076d208cfdcf388bc0e7edd06367d95c1dc9a08c87bbd6848ecf4fb23bc  -
7514500e9d536146575055de0f6ef9675d4b829f3329a8e4a2c20cc4bdcd09dd -> 3550fb0a84247be1656d46b23874ca357827e0423cba2e58f56062c6a4bb919a  -
bba5ee2812dbb43da4014f27c83a63488dcc2305ece1f7412b8646911cc9ba67 -> 8c023c452e1cc5207eb8de8d3af3b132aee553adc4098d4767a7543125025ac5  -
111dc53308d19a5a74a0537165a7f3a002269a5049d590f7a664909c3c07263f -> 5518205694948464143c4b30959ce36b8f2dd431502e7bbbbd9b361742a683d3  -
07f664b68ec82238a3465ce570215eb001ef795f906abe67e8f11e7d4fa1e338 -> eec308f8df80ad59dff7c9902acde257feb9efb6f1f499838d1a08ef06c518ec  -
470daaedb373af852030e71eace9cfffe51f2e38fb085f08d42098e627d58b82 -> e71dd2934da9c61b045fb7a1ed5213ad6cdb8533191297632ee0287a3bca8bcc  -
ba5e9c70817ffe8148d99774b4dc777dab5949727c8f7a73e49624d662501f02 -> 8d07912630e1ba0b96fe72d0bcfccf906498b6b9f12bfbb4aff55558de673535  -
9629cfd252f00c0de1063874e46ed3f574a0732425ae28e2776502da8613b017 -> a64fd00c9f22b7ee992ee6949f4e0ae2c1ff658ff04eb8c4fe3aad5612c9ee77  -
9e37ee5af0fc5d0c20cf1f7e93a579ff149a29bcdbc92da9181bde88074170c5 -> b2919892d4aca12f2269bf4401a86bb6abfd2487ebabd9402cf3e5ed1996f5b5  -
4.260000
bf9f0c11fc2f1ff82fa5f4b4769169c619b237dd62e93fbcdf2e091abc1d29ec -> 233c01ffba150ad136ee4d589d03ea9f82067e6bce581e6a404d200f0fddb463  -
.250000
f08f16cb4acac8e334d4e99155085cd5f03730936b06e1ea68c2d1fd0ece18d2 -> dba501b70e179611a39515b2c7c32882a9ecc56154444f351994420c616ce3ab  -
.350000 
59e8d1b6c351cb4d2a738f246a74f373f5245bdf0e485e622d4411a048ac8802 -> 52d8914b1aea413a6ecae1108cb6653bdf38799d3a152bfc15a9de64f0fbfaf5  -
.250000

(I added "test" at the end of the hash then sha256 it, and yes the 0.15 hash can't win since it's too small)
This would show the original tx hash and the new hash that's used for picking the winner.
Doing this makes it impossible for anyone to analyze tx's since the hashes can't be know till it's over! I'll probably end up hashing the tx's with the winning picks added. THEN use the new hashes to find the winner.

It fits in with BitLotto's goal of being cheat proof and still remains transparent.

Unless of course someone can think of something more simple and still cheat-proof?

[BurtW]

Then get tickets with those more rare combinations

Can you really control the hash of a transaction?  How would you go about that?  Sounds pretty hard to me.

[bitlotto]

Then get tickets with those more rare combinations

Can you really control the hash of a transaction?  How would you go about that?  Sounds pretty hard to me.

It would be hard and highly unlikely so far and the gain would be really small. But I'm more comfortable with impossible! They would have to use diff amounts from diff addresses to create many tx's to see what the hashes are and then broadcast the one that's the best.

[bitlotto]

We have improved the method for calculating the winner! This adds even more measures preventing any possible manipulation. And even though it makes it a little more work for me to generate the winner it's worth it. BUT, thankfully, it's actually EASIER for people to compare their tickets to the winner!
http://bitlotto.com/details.html

What happens now is:
-there is still a hash of 'lucky block' and Mega Millions numbers -> becomes 'mixer hash'
-this 'mixer hash' is added to the end of everyone's ticket (or hash)
-the hash+mixerhash is hashed again
-hashes are sorted 0-9,a-f
-whoever sorts to the beginning wins!

Why it's easier to COMPARE:
-say I say the winner's hash ended up as:
002e0a9d212cbb9c4fc2050a7cc6977e27ee0456a32f9f3ef4b5d8e716733a00
anybody could then hash their own tx themselves (or even a website that does it)
and do sha256(txhash+mixerhash) and see if it has more 0's at the beginning making theirs the winner.

Hopefully everyone is happy with the change. It actually makes it more simple and cleaner of an implementation and is more secure against any manipulation.

Good luck to everyone who entered!!!!!!!!!

[BurtW]

Number of zeros - kind of ala Bitcoin protocol...

[Stephen Gornick]

We have improved the method for calculating the winner!
http://bitlotto.com/details.html

Yes, hashing each transaction hash with a value that isn't known until after the deadline eliminates the (even microscopic) concern that I had.

So that there is a backup of the change, I'm reposting the content from details here:

Complete Details:

[Update: That page doesn't have the change yet. 
Maybe putting the pages for the site in github or some other version control and then signing each rev of this page would be a better archive?]
 

[bitlotto]

We have improved the method for calculating the winner!
http://bitlotto.com/details.html

Yes, hashing each transaction hash with a value that isn't known until after the deadline eliminates the (even microscopic) concern that I had.

So that there is a backup of the change, I'm reposting the content from details here:

Complete Details:

[Update: That page doesn't have the change yet. 
Maybe putting the pages for the site in github or some other version control and then signing each rev of this page would be a better archive?]
 

Um, the page is update. Try refreshing it. It works on my end.
I like the idea of saving the old changes. I kind of wish I had what I wrote at the very beginning. It would be good for historical reasons.

[bitlotto]

From another thread:

In regards to your recent change of rules for Bitlotto.

1) You are absolutely correct in your latest change.  Your new scheme is much more secure.  I don't see any statistical problems with it.

2) It is absolutely possible to select transaction IDs.  You simply use a client like bitcoinJ which allows you to create a bunch of transactions then examine/simulate with them to see which one helps you cover the most lucky number space in conjunction with your other transactions.  Then you commit only those transactions that help you the most.
.......

Now my odds are the same as all the other dumb money chumps.

That was close! We are sure glad we decided to change the method now rather than later!

We have talked to others well versed in crypto and math and our new system is immune from any type of manipulation as mentioned above! The key was to change the tickets in an unpredictable fashion. Hopefully we don't have to change again as we kind of like this new method!

Good luck everyone, this draw is probably going to be over 200 BTC!!!!

[bitlotto]

About 22 hrs left to buy a ticket for the April 4 draw!

GOOD LUCK EVERYONE!!!

[baldrick]

I'll work on a program for the new rules and I'll try to have it ready by drawing time.

[baldrick]

I have a program to crunch the results.

Here is what it outputs:
http://pastebin.com/Wt1wNVjd

Not the real run obviously but I'll run it and post once the real mixer string is known.