Last weekend, the boys and I were at a bar and we started playing on one of those “parlor game” machines. If you’re unfamiliar, they’re basically a computer with a touch screen in a glorified case. They’re loaded up with dozens of games like “spot the difference”, traditional casino games, and of course X-rated versions of everything. As we were burning cash playing, we started thinking out loud that the game would be “cooler” if you could actually win money back. Games like this do exist in Vegas but they’re consequently heavily regulated by gambling related laws. As we were discussing this, someone mentioned building the game using Bitcoin in hopes of skirting gambling regulations. So, how could you go about building a real world game using Bitcoin for payments?
Hardware
The natural choice here would be to run with a WiFi enabled RaspberryPi along with a capacitive touchscreen. I’ve never done any work with touchscreens but it looks like TigerDirect has 22″ Planar ones for under $300. Couple that with a WiFi RaspberryPi kit for $50 and we should be in business for <$500. You could obviously grab a smaller screen but go big or go home right?
Authentication
Now things get interesting. Philosophically, I think you do want to enforce authentication so that users can save scores, carry a BTC balance, and generally make the experience “stickier”. The straightforward approach would be to offer a traditional sign up using an email address and password but that would totally sacrifice leveraging social media. Allowing users to easily “sign in” with Twitter or Facebook would allow you leverage their social graphs to find their friends and drive awareness of the game. An issue I’ve run into in the past is that “kiosks” always ask you to enter you Facebook or Twitter credentials directly on the kiosk – which is a non-starter for most people.
So how can we avoid this? The big idea is that you really just need the user’s OAuth tokens for whatever service they want to use – not their credentials. To do this, you’d need to either distribute an app or have a website where the user could “sign in” while already logged in on Facebook or Twitter on their mobile phone. Then, you’d be able to capture their OAuth tokens and log them in to the kiosk.
Getting the Bitcoin
Ok, so the user is logged in, now we need to get them some Bitcoin to play with. I think what you’d want to do is generate a wallet for each authenticated user and let them transfer in to an address as need be. So since their account is unfunded, they’d be presented with a QR code for an address that they can use to fund it. Another interesting idea would be to let users buy BTC in cash from the bartender which would in turn automatically fund their account. To support this, you’d need an app or website where the bartender could transfer BTC into the user’s wallet after receiving cash on site.
In terms of software to facilitate this, it seems like bitcoinj would be the best option. Written in Java, bitcoinj is a “client node only” implementation of the Bitcoin protocol that allows it to run without a full local copy of the Blockchain. Because of this, bitcoinj will run in resource constrained environments like the RaspberryPi. In addition, bitcoinj supports “simplified payment verification” so you’d be able to clear transactions instantly without waiting for confirmations to settle.
The Games
Graphically and conceptually, the games are all pretty straightforward so your best bet is probably implementing with JavaScript with HTML and CSS. The benefits would be you’re development cycles would be short and you’d be able to develop the games independently of the device itself. With HTML5 hitting it’s stride, you’d also be able to enable “multiplayer” versions using WebSockets.
One interesting consideration is that without being able to definitely vouch for the physical security of the kiosk how can you verify that the running code is authentic?
Sending the Bitcoin
The final step in the dance (and what makes it special) is allowing the user to cash BTC out of their account. I think you’d want to offer the option of allowing the use to generate a “send to” address if they have a mobile wallet and also allow them to cash out in person. If they can generate a “send to” address, they’d have to use the kiosk to scan a QR code where their BTC balance would get sent. To facilitate this, you’d need a webcam attached to the RaspberryPi and then use something like ZXing to decode the data in the QR code.
For the “in-person” option, you’d need to build out functionality to allow the bartender to initiate a transfer from the user’s wallet back to the bar from the web or mobile app. After it settles, they’d simply hand the user back some cash and the account would be settled.
Is this legal?
Therein lays the rub. It probably is but I’m not 100% sure. Eliminating the option to exchange BTC for cash might help the case for legality. Along with that, if you can side step “making odds” as well it might help your case. Would love any thoughts on this!