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

So what kind of warning do admins get from bitcoind? Is there something we can grep from debug.log? Or will rpc calls raise some specific error? Is there a way to locally force this to happen, for unittesting services?

While you are obviously right in stating the current trend, there are some factors, like the slashdot effect, that will probably be repeated a few times still, but that are maintained in time, especially when you think on a broader time lapse. The bread index, or the milk index or any other basic product for that matter is just a reflex of my observation, not a science I grasp. I used to buy bread cheaper, in absolute values. Maybe taking inflation into account that is not so, but when Bitcoins, not having a Fed making it's value decrease to 'stabilize' the economy, stay at the same value per dollar while 1 dollar buys less bread, I guess you can call it deflationary. It's not that bitcoins are worth less, much the opposite, but this goes against what most everyone is used to, or has been taught is "normal".


Not at all. I'm a native Portuguese speaker. I do have a *lot* of exposure to English, in its most varied forms, though

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

the risk I mentioned was very well contextualized... I called it 'risk'. As in, not a real risk, but something that over and over again is discussed in the threads as a risk. People debunk that, explain, complain and eventually got bark at some other tree, because those who perceive deflation as a problem, or lack of inflation for that matter, are the majority and are pretty stubborn.

I like the fact that Bitcoins are pretty stable, but that actually deflates them when compared to currencies (and notice I didn't say *other* currencies), because the same amount of Bitcoins within 1 year is supposed to be only mildly inflated while the USD will probably be much more so, hence 100 Bitcoins buys less bread, because bread in indexed to the USD. Of course, once there's enough critical mass behind the Bitcoin ecosystem we can index stuff to Bitcoins, but for the time being... Bitcoin is deflationary.

I hope I got the terms straight, I'm not a native English speaker and while I know all the geeky computer terms, the financial theories and their terms escape me completely

Maybe I'm not as paranoid as I advertise, but I actually think there is a social interest in this. On the one side is everyone who, while looking for alternative currencies (because they are pseudo-anonymous, because their favorite mmorpg accepts it or 'simply because') don't really see with good eyes the deflation 'risk', or simply can't cope with following another currency, as because of that end up never adopting bitcoins.

The described system would not overrun or replace bitcoins, but it would allow for a 'buffer mechanism' for those that want to use another currency (which is just dollars, as it is pegged to them, but goes by another name... think linden dollars, they actually have a huge user base). What I don't see is why would anyone take the effort and risk of running this service. It would be a sitting duck if governments ever come after this. I mean, it's dollars by another name, how can it not be a currency controlled by the feds?

Nice... this is very close (in philosophy, not implementation) to one of my wannabe projects, which is a connected exchange framework. It would 'copy' mtgox but operate on a different exchange pair, and under the hood both exchanges would fill out bids and offers by buying/selling bitcoins on the other exchange, if the exchange was favorable.

So, having mtgox doing USD and mtclone doing EUR, and using the exchange rate for USD/EUR without any spreads, we could operate bitcoins in a way that their price actually fluctuates to negate the differences between to USD/EUR pair (assuming enough people trade on both exchanges). This is cool, but now imaging you do that for 10 other currencies too... Bitcoin would become pegged to the balanced average of *all* those currencies, not USD or EUR. I think that would do wonders to get the financial wiz dudes paying close attention to this system.

I'm not a financially educated person, but I am a coder, so if I do find the time to put on this, I will create a package that anyone can use to create their own exchange site, and connect to others they trust as described above. Heck, I may even run one myself!

The only thing still on the open is: how do we get the money in? Paypal is obviously not a good idea. In Europe we have very low wire transfer charges, so that could work but I don't know the legal implications of that.

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.

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.

Thank you, you're too kind. And the nice words totally offset you calling me predictable, so we're good


I didn't mean to say no one will answer. I would answer the poll, but I'd just lie about the 'too personal' question that allow anyone that lays hands on this data (who controls it? how safe is it?) to gain leverage on me. Country? sure, there's 10 million here and it's a very small country, but age? Too specific. Suddenly it's 27k possibilities where I live, taking 365 days in a year into account. Add gender and it halves that. Gather some more data from the thread posts and you know who I am. No can do.

Many will answer because they feel it's a service to the community, getting to know our demographics, but is it? We're opening the door to exposing unknowing users to getting their details on the wild, and remember although we are not all zealots, we all should be aware of the real danger of, if this thing gets raided, things getting ugly for all that traded bitcoins. I don't live in the US (obviously) so I'll be safe, but is everyone else?

I'm not trying to convince you either way, but I'm not one of the 'crazy privacy freaks'... well, maybe I am, but still I just feel very uncomfortable when the unwanted disclosures that may hurt us are started from within the community itself, with the best intentions I'm sure, but that's just too much detail you're asking imho.

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.

You're kidding, right? I mean, collecting that kind of data when we're struggling to stay as anonymous as possible, kind of makes me giggle... and then get seriously worried.

Sorry for the bluntness, but I for one tell no one my age

"I have a plan..."

So you say you want the random to be unique, right? It just sidesteps a bit from 'random' when we get picky, but a subset of random should be random enough, I guess.

As for the list of tickets public, I didn't want to do that while the bets are on because, well, it felt wrong. But I can't find a reason in logic to substantiate that, so if there are no objections I'll make a list of *all* taken numbers.
Remember that 2 blocks from the end the bets are locked, and that's when I though I'd be introducing the list, but I can do it before.

What more information do you need to make sure I (or any other future operator) am not stealing? Knowing the numbers provides you with enough knowledge to block me from stealing a top prize but not from stealing a lower one. For that you need a list of bets *and* how many tickets exist on each bet... How should such data be provided?

I'll start by just posting a list of bets to a page, a big ol' dump, and then I'll think about something on the likes of a csv file that gets generated as the draw is locked.

Is it just me or this conversation has had a very sudden sidetrack here?

Unless the EFF has Australian offices and you'll be sending them the gold along with the letter, of course.

For all of you doing random bets, right now I make sure these bets don't repeat themselves *within your tickets* but would it be useful to make them unique on the whole draw? Luck is luck, there's no real statistical gain for the individual to do it any other way, but we would cover much more betting space, thus making it more probable for the high prizes to be hit, if I were to spread random bets that way.

What do you think, which do you prefer? And, if I do change this, you can always cancel all your tickets and buy them at random again, if you want unique bets system wide (unless someone else manually enters bets matching yours after you did that, of course).

Yeah, well, kind of

It does not log you in automatically, but it does tell you 'Registered!'. If you then log in from that page, you'll stay on the page and get a 'You are already registered' which is only slightly less confusing... but as it is working, that's low on my priority.

Right, so here's what I did:

An optional password can be set on register or in the account page. When set, you'll need it to change the BTCOUT address. You can change it too. That password is not needed for login, the BTCOUT is still the only information required by the system.

There was another unrelated change that was logging people out when they changed BTCOUT. I've fixed that, but now everyone must log back in

It's not too much work at all, but it is a little daunting for basic users... I think asking them to provide a password on register, but allowing it to be kept blank (thus allowing BTCOUT to be changed just by knowing the original) would be a good trade-off. And then you can change that in the account page by changing or clearing the password, I guess.

Will try that, thanks.

Being open source does not mean every user is a coder (I am, but still) so I guess the point that "you can just roll out your own client" is a little off.

But why is satoshi integrating this on the server in the first place? I say that the libbitcoin / bitcoinUI separation is starting to be really important. Put the messaging system on IRC on the UI, make the UI smart enough to stop, block, maim, impair the server running beneath it if certain messages signed with certain keys appear. But DON'T make the server respond to anything outside local GUI control, just because that is too dangerous and in the end does more harm than good.

This way, average users will have the upgrade notices and the generators stopped and whatnot when needed, but those of us running services over bitcoin will not loose shop because of that. Also, if the key gets compromised, the network still runs without worries, and a simple GUI change will unblock everyone.

For server admins, why not a mailing list for update announces? That would certainly be enough for most.

Yeah, I make zero effort of asserting registered address is correct, and other than trying to send bitcoins over, I know not of a method to assert it... probably could patch bitcoind to add an rpc method for that, though.

I can also check string length, I've just been lazy. But if I understand you correctly, it would be ok to deny changing the btcout so we can recover the account safety?