Hmm,

GAE cron jobs could probably keep up to date or close.

Javascript in the browser would not work as a full client for the reasons you suggested, but there is node.js. I think a javascript port of a minimal client would find plenty of uses. For instance, maprejuice.com just launched -- they claim 200,000 web clients already. I imagine one would be interested to run block generation there.

Awesome! I'm in and sequenced. Thanks!

I suppose one might try to reset market prices.

If so, apparently you need a lot more bitcoins than 30,000 to do so, apparently.

Thanks, I've read that. I was hoping for a simpler than code review resource for the exact bits and bytes. If one doesn't turn up, I'll dig a little deeper.

Thanks for the bet return!

Re: hosting -- I think you could host it on google app engine for free at low traffic volumes.. Of course, you have to like python or java.

I had tiered out my buy orders, so I picked up some on the way down, but not nearly as many as he sold.

Standard market movement theories distinguish between short and long term market movement -- if I recall my market math properly, he should have moved the long term price down something like .15 cents or so, if bitcoins act like a security. Looks like this is roughly what happened, although the 'short term' was pretty darn short in this case. : ).

Volume: 30,000 BTC.. Low price $.03x... It looks like somebody really wanted to sell some bitcoins.

What about autosend to an address? That way it could run uninterrupted somewhere and end up in a main account.

UPDATE: I bet. Then I realized that I could (and should) get total coverage for the last number in the block. Then I learned I can't rescind my bets.

Can I request either a 'full coverage' option, or else just a 'remove this bet' button? I think you had 'remove this bet' at one point.

Also, seeding the lottery with 100 bets of your own is different than putting in a 100 BTC jackpot, by the way. : ). I think it will be more appealing to people if you take a cut, and seed, regardless of the underlying math.

a) Can secret sharing be incorporated into Bitcoin's scheme? I'm not sure of the technical pub/private key pairing that it uses.

b) I'm not sure it's an entirely appropriate solution -- Shamir had in mind a sort of 'info bank' or 'lockbox' when he constructed this system -- the payload was more likely imagined to be, say nuclear armament codes or wikileaks style information, not a bank account, as the system doesn't explicitly deal with the 'well, what do we do, now that we can decrypt the information?' question.

Thus, even if you had a shared key, say one that needed 1+n/2 to use their private key for access, all you would get back would be the shared private key -- then it would be a race to cheat with that key, or possibly the final party to apply their private key would get access. This still leaves a trusted party issue in the mix; I'd say the cheapest thing to do is trust the pooler.  In this system, cheating is easily detected (e.g., your client knows it generated a winning block, but you never got a portion of it), trust is hard to repair, and recruiting people to your pool is likely to be far more work than 50BTC are worth in the near future.

Thanks for this. Question for the developers: what do I need to hash, exactly to get the sha-256 hash for this block? Is it the JSON, or is it kept in some other data format in the database? I'm interested in generating blocks myself, and am not clear what exactly is being hashed.

Okay, I put 20 in. Once confirmed, I'll bet them all.

I agree with the sentiment that a small reference client would be hugely helpful. I would like one that ran on Google App Engine, for instance, and as you say, a reference javascript version would be totally fabulous.

This is an FAQ. The answer is 'yep.' Someone got a transaction put into your block which required a small processing fee. You got the fee for processing the transaction. Enjoy!

I just read the New Jersey Pick 3 lottery rules over. They have a simple system:

1) 50% of the ticket sales go to the prize pool
2) (they have a bunch of ways to win, but I'll unitize them all to a number of 'Wins')
    They calculate Ticket intake * .5 / # Wins => Prize Share
3) Each Winning bet gets a prize share.

To compare, the powerball system
A) seeds the jackpot with an amount, ($10mm), advertises twice that as the 'annuitized jackpot', and proceeds as follows:
B) 50% of the ticket sales go to prizes.
C) Roughly 58% of the prizes go to the jackpot, won maybe once a month. The other 42% are for the smaller prizes.


As noted by the powerball website, powerball is designed for people who are motivated by a  big jackpot. Presumably Pick 3 is designed for people who are motivated by a small, frequent (it runs twice a day) payout.

So, either of these seem like fine setups -- hard-headed expected-value-discounted-cashflow-type people only play powerball when the advertised annuity is up in the $250MM+ range, and everyone else plays when they like the sound of the jackpot size. No math people play Pick 3, I'm sure.

My takeaways:

I) I think your lottery needs to choose a personality: is it going to be a big prize, monthly-ish win type situation, or a frequent small-scale wins one? I don't mean monthly drawings, just likely 'big' wins at once a month.
II) You probably should have a minimum pot for jackpot winners: this ensures people want to play more often. You would fund this out of your own funds to start, and then whatever you decide your rake should be, eventually.
III) An out of the box idea I had is that you could write some sort of rules algorithm and allow anyone to run their own lottery; you'd take, say 10% off the top, and lotto designers could choose their own payouts, jackpot rollovers, etc. Natural selection will tell you the most successful lottery designs quite quickly, I imagine.



As a sample 'powerball'-esque lottery: if you had a jackpot minimum prize of 10 BTC and two drawings a week, 100 people playing per drawing, odds of winning say 1 in 1000, then you'd see the following:

Week 1, Drawing 1
20 BTC goes in: 10 covers the jackpot: 10 BTC goes to rake
80 BTC goes in: 40 goes to rake, jackpot is now 50.

Week 1, Drawing 2: Jackpot 50
100 BTC goes in: Jackpot is now 100 (no winner)

Week 2, Drawing 1: Jackpot 100
Odds of nobody winning so far: (900 / 1000 ) ^2 = 81%
More people get interested: 150 buy. Nobody wins.

Week 2, Drawing 2: Jackpot 175.
Odds of nobody winning so far: 69%

I don't know if this would be appealing to people or not. I bet if the jackpot were 1,000 BTC, odds of winning say 1 in 5,000 to start then it would be appealing. The simplest way to keep math-oriented speculators out is to keep the expected value down, except in rare  circumstances.

It's gotten too late for me to add more to the conversation, so I'll summarize a TL;DR -- Copy some successful lotteries! Use the rake to provide a guaranteed pool! (Possibly: let people use your software to host their own lotteries).

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

When you are generating blocks, you use the pool's public key; it is not possible to insert your own key in your 'winning' block.

I have a related set of problems, but the other way -- bitcoin on ubuntu 10.04 x64 is extremely reticent to use all available CPU time, but in a totally non-repeatable way: sometimes it will use only 1/8 or 1/4 of my 4 cores available time, never triggering CPU speed increases. other times, it cheerfully chugs along full speed ahead at full speed. This is on a Core i5 laptop.

Older versions of the client would zoom up to 100% pretty consistently, and back off when I needed, but 0.3.10 doesn't seem interested in taking up the right amount of processor time.. renice -5 has no appreciable impact -- it seems like the rate limiting functions got an update, and it's not as good as the old setup.

Leaving early is not an attack. Consider:

You are in the pool, and one minute in to the block, you find the winning hash. There are 4 other pool members, each with equal strength computers.

You get 10 BTC on maturation, like each pool member.

The pool immediately goes to work on the next block. If you leave, the pool strength drops by 20%. The member's BTC shared increases by 20%. They are not worse off without you.

Now, imagine the 'winning' hash gets a 2x share: for each future block all participants' expected value of BTC is the same as it would be going it on their own. "Leaving early" is a little bit like taking your money out at the casino whenever you're up. You're up, good for you, but your odds going forward are the same as they were, and the same as everyone else's.

Playing to 'get lucky' like this is probably not the motivation for such a pooling arrangement once pool members > 10 or so.

Finally, asking people for 50 BTC upfront is absolutely contrary to the reason you would want to pool initially -- getting a few BTC flowing in half an hour or so from download of the application.

p.s., This also begs the central question -- how do you know how fast / strong people are? You could sit around working on other non-pooled hashblocks and just give a 1,000 hash block anytime the server asked you for one. I'm not sure how to probabilistically determine speed and deal with cheaters.

Why not just a program that escrows the private key of an address, and generates an e-mail, a-la paypal: "You've been sent money!"

"You've got bitcoins! Click here to claim them."

Alternately, you could embed a password-protected private key that the bitcoin client can import -- say a .bitkey attachment: "Attached is a bitkey. Click it to open it in BitCoin and claim your money. (Password sent in a separate e-mail)."