Although the idea itself sounds quite simple this would mean a huge increase of complexity on satoshidice side. Right now each and every bet is a very simple process: Transaction comes in, payment is sent out. This is a quite atomic process which can be tested easily, and is a perfect candidate for scaling up. You could set up 20 bitcoinds (or whatever backend they use) on 10 different servers behind three loadbalancers and each instance could work fully independent of each other. (Beware, this is probably over-simplified. But you should get the idea )

With your proposal the "atomicness" of each bet is lost. Now you have to collect and combine payouts from each backend instance, put them in some kind of distributed task queue, add a payment service that works on this task queue to push the combined payments out. And do all this in a failsafe and scaleable way.

So I fully agree that the transaction spam and fees are a huge PITA, but I can also understand why the implementation on Satoshidice is done like this.

With bitbattle.me I was trying from the beginning to NOT have transaction spamming, but took a different approach by introducing the player & session concept. This has some advantages (you save a lot of transaction fees, have a lot less transactions, have individual bet addresses and stats) but also some disadvantages (code complexity, scaling potential), the biggest being that you need the website in order to keep up with your bet results (there is no tx created for lost bets - You only will see on the website that your bet was actually placed).
Personally i consider the website dependency not a big problem compared to the transaction fees and spam, but this is of course a matter of personal preference.
 
Edit:
I hope this does not look too much like thread highjacking. This is just a topic i spent a lot of time thinking about, so i felt the urge to reply. If this is deemed unappropriate in this thread feel free to delete this posting.

Update launched today:

• New "Get started!" page that should be more user-friendly
• "Find Player" on the frontpage to directly locate your player dashboard
• You can now start/join multiplayer sessions with your player
• Your bet addresses are now shown in a dedicated popup-window, so you can always keep them around
• whole bunch of UI design/layout improvements and cleanups

Unfortunately one nice feature did not make the change: Right now you can not create invitation sessions anymore. But this feature will come back soon 

And did I mention that win payouts of bitbattle.me do not directly rely on the outpoints of incoming bets? So even if some double-spends would come through this will have no effect on people's win payouts. 

Btw:
This is not as easy as it sounded in the beginning Since the whole site works without authentication there is no easy way to prevent anybody from closing your running session if I just add an according link. So this feature is not (yet) in.

Good point about being able to stop a singleplayer session. I will definitely add this

Player srmagic was the lucky guy to make bitbattle.me reach a significant first milestone: 1000th bet!, placed today at 17:28:41+0100 (unfortunately lost once again  )

I did not expect to hit this number of bets so fast, so I take this as a sign of both trust and really having fun - Thank you to everyone who used the site so far!

There are already a lot of improvements planned, especially I want to focus on the multiplayer part. Right now there are just too few players so it is very unlikely that you get an opponent when starting a multiplayer session. Naturally, this can only be changed by you :-) While the active player base is reaching critical mass for multiplayer I am working on making it a smoother experience. First thing on the list is to make it possible to join multiplayer game with your existing player, instead of always needing to handle temporary bet addresses.

So stay tuned and keep rolling 

Hmm... For a "successfull" Martingale shouldn't you take the win odds into account?
Like for a 50% win odd you double each time you loose. For a 25% win odd you have to multiply your bet by 4, etc?

Wenn es dir nur um das erhalten von Zahlungen geht kannst du auch mal http://bitcoinmonitor.net anschauen, insbesondere die http-callbacks. Ist (noch) kein OpenSource, aber dafür kann ich dich direkt und auf Deutsch supporten falls du Fragen hast :-)

In case you did not realize it - The player stats were totally wonky . This is fixed now (together with better validation of Bitcoin Address when creating a new player)!
Right now jammm is by far the most active player with 348 bets.

Thanks for your feedback steamgames!
I noticed that someone created a player with an invalid payout address and actually won 0.35302. Naturally the transaction is still in "pending" state. So, if you read this please contact me so we can sort this out - In the meantime I'm back to coding to improve validation of payout addresses :-)

Edit:
Another thing, some user probably by mistake created a new player for each session. This is not necessary, the idea is that you just create a player once and then keep using it for as many sessions as you like. Whenever you place a bet by sending some coins to one of your bet addresses a new session is automatically started. Or, in other words: If you created a player the bet addresses are permanent, they will NOT expire when your session ends.

Watching.

bitbattle.me now officially supports "sendmany" transactions!
Sample session: http://bitbattle.me/game/8afa3fcb48e14274900051e2591a1114/
All three bets of this session were included in one transaction. (And all of them lost )

Some time ago I heard of https://www.gittip.com/. I really like the idea and concept behind it compared to existing crowdfunding or one-time tip systems. and naturally think that this would be even more awesome when bitcoins are used.
Right now you need to put a credit card on file for tipping anyone, and you need a bank account for getting your money out of the system with all known limitations and attached fees.
The devs are actively discussing bitcoin integration (https://github.com/whit537/www.gittip.com/issues/14), but have no consensus found so far. But the discussion there seems to indicate that they are only willing to partner with a bitcoin payment system like bitpay.com on the frontend, and basically stick to USD for everything else.

I am tempted to start an open-source clone of this with full focus on bitcoin (and only bitcoin), without depending on external services like bitpay and the related direct and indirect fees. So you only can tip in bitcoins and you only can cash out in bitcoins, no interface to banks etc.

What is your opinion? Would efforts be better spent trying to get bitcoin integtated into gittip.com? Or would you prefer a bitcoin-only clone of the project, made by "us", the bitcoin community?

I checked your message and it seems something is already borked while processing your message on txt4coins side. In my database there are already only questionmarks stored :-(
I need to check this in more detail and try to get it fixed. In the meantime i will of course give you a refund - just provide me a payment address :-)

Duh. So the only thing I could do today with locktime is to create transactions that will be confirmed "delayed"? No way of cancelling or changing, and also not possible to "override" by issuing new transactions without locktime using the same inputs? 

Server up again with some major new features:

• Have your own set of permanent bet addresses
• Track all your bets and sessions with personal statistics
• Watch your and other people's bets and sessions live in the browser
• All kinds of statistics

And:

• House edge is down to 1.8% for all bets
• Max bet amounts are doubled for all bets

And this all without accounts or registration !

=> Check the updated first post for more details or visit bitbattle.me right away!

Server will be down for approximately one day due to some infrastructure changes. For compensation there will be some exciting new features when it launches again!

Yes, I am also thinking about this option. But it would introduce a whole new set of dependencies and complexity. To make it right and fully decouple the offsite wallet, communication should be one-way only - The off-site bitcoind service would regularly pull from the site the current "jobs" and needs to push any status change (balance, transactionIDs, confirmations etc.). Implementing this in a fail-safe and clean way is a huge effort, not including administrative overhead to keep multiple servers up and running, backed up etc. etc. That's the reason i started tossing ideas around about different approaches with less complexity but still high security.

I am thinking about possibilities for implementing recurring payments service with as little risk and user-interaction as possible.

Goals:
-> Keep the site's hot wallet balance as low as possible to make it unattractive for robbing
-> Allow the user to "pre-pay" for as long as he wants.
-> Allow the user to always cancel not-yet-paid payments

Scenario:
Let's say user wants to pay 1 BTC each week to an address.
User goes to service website, enters information "pay 1 BTC/week to Address X".
User sends 10 BTC to website.
Website splits these 10 BTC into 10 transactions of 1 BTC, each with a locktime one week further in the future.
=> User is done
=> Receiver gets 1 BTC/week
=> Receiver literally can see in the blockchain that payments to him are really planned (of course this is just for information - unlocked payments could be cancelled anytime)
=> Few days before the last pay date is reached site sends a reminder mail to user if he wants to continue the recurring payment he has to send funds.
=> Happiness  

Now let's say the user wants to cancel the not-yet-paid transactions:
-> User goes to site, says to stop all payments
-> Site updates the unlocked transactions with a new Outpoint (The users address).
=> Q: Can the user get back his coins immediately? Can the locktime be modified also at this place, so the user gets his coins back right away? Or does he still have to wait for the locktime to be reached? Or could the site generate just a new normal transaction with all unlocked transaction's inputs as inputs that "overrides" the waiting transactions?

Now assume the site gets robbed and an attacker obtains the wallet.dat:
What is the actual balance of the wallet? If all incoming payments from Users are immediately broadcast with according locktime to the recipients - Would the wallet appear to the robber as "empty"? What additional information would he need to change all existing unlocked transactions to point to his address?
In general: Would this approach give any security boost over a classical "pay from hot wallet via cronjob"-approach?

Awesome!

Sorry, I have no idea if these settings are correct or not. Maybe you can try it with a different xmpp/jabber account (get one for free from jabber.org) to see if it is a google-talk specific issue?

Hmm, I don't know what the problem might be. I could successfully send a test message to my own jabber account (made a fresh test account at einfachjabber.de). Also checked the logs and your test message was sent out without any error.
Maybe still some setting not right on Google side?