Are there plans to do block verification (of multiple blocks) in parralel?
Especially during bootstrap.dat loading this would be very useful (because we all have multi core machines) - possibly even utilising the gpu to speed up the process some more.

Ich bin da und fände mehr über bitcoins auch spannend!

Did you just overlook my post or is there a specific reason for not giving me the promo?

An alternative to your suggestion (which needs protocol level changes and is only useful to very few people) would be to have a very locked down system running an application which implements your requirements. Only your application is accessible over the network.

You could configure a lock-down time in the application and your "main" web application could send transaction requests to the system. When the system receives a transaction request the transaction would be executed after n (2) days you get notified (by e-mail?) and can interfere before that happens.
The key here is of course to have the system locked down as much as possible as it will have programmatic access to the private keys with your funds. Blocking all incoming ports and denying all incoming and outgoing traffic except that for your application  (possibly on a hardware firewall and on your system) and making your application secure enough shouldn't be that much of a challenge.
You could optionally run bitcoind on the system however that's a fairly complex bit of software performs many operations which could go wrong so it's probably better to not do that and to broadcast the signed transactions to the network in some other way (your outside application could poll it and then insert it into the network when it's appropiate).

Your locked down application therefore would need the following API functionality available over network:
- Create Transaction
- Cancel Transaction (you probably want to be able to do that over network)
- Poll created transactions

LMYGPFgAdCjMSNCvtg5Mhrm3WbcwUBoJ3L thank you!

kraken.com darf man seit kurzem auch als deutscher, geht sehr flott, man muss halt die Überweisung abwarten, dann kann gekauft werden

How did you reach the design choice "node.js"? Why not rails, django, play or anything different? What do you see in node? I'm always interested in working on cool projects that bring new things to the world but I wouldn't want to without knowing anything. The basics you described can be easily implemented in any programming language however what is the goal?

Seems like the site is completely unusable again. Is there any ETA when this will get fixed?
(Note: Maybe the performance would be better if the page wouldn't make about 5 http requests per second)

This is NOT provably fair. If I send a transaction now you can select a random seed which makes me lose quite easily. This is bad. You don't need to change it for me but don't claim it's provably fair if it's not. Look into what the others are doing. A solution that works for on-chain games like yours is to have a secret of the day that doesn't change and have the SHA-256 (or whatever) hash of that secret known, the secret should be at least 16 bytes so it's hard to find by brute force searching (feel free to use longer secrets). When calculating the result you combine the secret of the day with the transaction id in same way and then find a card from the deck in some way.

For example you could: card = (HMAC_SHA256(secret,txid)/2^256)/52, the result is an index in a deck of 52 cards (note: this uses big integer arithmetic)

After the day is over you publish the secret. Now everyone can verify that the SHA-256 of the secret (which was known to players beforehand) is the same as calculating SHA-256(secret) when the secret is known.

Yes you can screw up implementing provably fair and leak your bet results beforehand but you can also do it correctly and the game becomes provably fair for everyone.

Maybe you should look into what all the dice sites are doing it's basically what I described.

It's not provably fair. To make it provably fair you need to show information which will allow players to know that the result of the draw can not be influenced by you before they make a deposit.

A possible implementation is the hash of the random seed (possibly add some salt). You will make people even more happy if you use the incoming transaction id as the client seed in addition.

The client does not send a seed.

It makes sense that the game state is only known on the server during the game otherwise your client would know which tiles are save which would allow you to automatically win. They can however tinker with selecting fields for mines that you (as a human) are more likely to click as there is no client seed involved.

I highly doubt it. The price won't drop that low again unless any important country bans btc by law. That however might hinder growth to 1000 quite a lot.