Accepting Bitcoins in an online game

[teppy]

I'm accepting Bitcoins now for A Tale in the Desert.

I'm aware that the correct way to do it is to generate a new address for each payment, but I don't yet have the code to generate new addresses in the server. (If someone could point me to such code I'd appreciate it; I spent a few minutes poking around the source but haven't found it yet.)

But let's say that I do have the means to generate a new Bitcoin address on the fly. A player tells the game client that he wants to subscribe. I generate an address and tell him "Send 2000 BTC to <address>", and then when the Bitcoins show up I credit his month of playtime.

Once I have a list of all the "throwaway" addresses that I've created, how do I then go about watching all of them for incoming Bitcoins and forwarding them to my "real" account?

What would be ideal (in my situation anyway) is for there to be a message field as part of a transaction, and then I could just tell everyone to send to my main Bitcoin address and include their character name in the message. It looks like this is supported when sending to an IP address, but not when sending to a Bitcoin address. There must be a reason for this - anyone know what that is?

Teppy

[laszlo]

Teppy, there is a JSON-RPC feature built into the client and that is how people generate integrate it into a web site or other software.  You can send a command to the client to generate an address.  The address that is created is yours forever, and it just allows you to receive payments, but regardless of which address the payment went to, it goes to your wallet.  The coins are 'in' your wallet file and not owned by your address - you don't have to forward it back to your main one.

Check out this thread http://bitcointalk.org/index.php?topic=63.0

[dwdollar]

It sounds like getting it fully automated might be easier on you.  Bitcoin is fully capable of that, but I don't know how easy it will be for your situation.  Is Python good for you?  Where is the user's information normally stored?

[sirius]

The JSON-RPC is not included in the current release build, so you'll need to build it yourself from the SVN (or ask someone to send you the binary for your platform). It will be included in 0.3.

Is Python good for you?

JSON-RPC has implementations for all the common programming languages, so that shouldn't be an issue.

[teppy]

It sounds like getting it fully automated might be easier on you.  Bitcoin is fully capable of that, but I don't know how easy it will be for your situation.  Is Python good for you?  Where is the user's information normally stored?

For ATITD we store everything on the server, which is a C++ program that periodically (every 3 minutes) writes its state to a checkpoint file. The server can pretend to be a web browser - we should be able to run bitcoin as a daemon and use JSON-RPC to generate an address for each payment.

In detail, we would:
1. Have the user request to pay by Bitcoins, using the game client.
2. Have server contact the daemon and asks for a new address.
3. Store that address in the player's record as an unconfirmed payment.
4. Tell the player the address to send the Bitcoins to.
5. Periodically poll the daemon for any recent payments, and change any unconfirmed payments to confirmed.

Here are the problems that I see: (Still wrapping my head around some of this!)
1. Suppose the server crashes after we've generated the address, but before the checkpoint has completed writing (so, up to 3+3=6 minutes), a payment could show up but we'd have no way of knowing what character it was for.
2. A running daemon is one more thing that could fail.

Have I overcomplicated the process? It's too bad that there's no way to embed a message in a payment; if there was, the process would be:
1. User sends payment to the one address that we publish, and writes his character name in the message field. Easy for the user and no game UI required.
2. Periodically poll the daemon for any recent payments, crediting accounts based on the message field.

In this scenario, the daemon would still need to be running for the credit to show up in the user's account, but not for the user to make a payment. In no event would the payment get lost.

Now, practically speaking, the server crash scenario isn't a problem for ATITD, because we're a small game and Bitcoin payments will be a tiny fraction of all payments. But PayPal became popular because it was *so* easy for both merchants and users to understand the "send money to an email address" metaphor.

"Send money to this weird looking address" isn't that much harder to grasp. "Send money to a different address every time", or "send money to an address that I'll tell you in a minute but which will be unique for you" is a bigger leap though.

I don't understand the data structure of "a bitcoin" enough yet to suggest a solution.

[laszlo]

The payments won't get lost because bitcoin writes the data to disk immediately, but in your game you would definitely want to perform the same 'flush' operation to commit the transaction to disk before you display the address to the player.  Other than that, everything you described sounds good to me.. the JSON-RPC communication to the daemon is exactly how it is intended to be integrated right now and it sounds like you have a good understanding of the concept already.

[dwdollar]

Although you need a unique BA for each user, you don't necessarily need to regenerate a new BA for every user's transaction.  You can issue a single BA for each user and then keep tallies (in your database) on the amount received from this ongoing BA.

This sounds like it would work.

In detail, we would:
1. Have the user request to pay by Bitcoins, using the game client.
2. Have server contact the daemon and asks for a new address.
3. Store that address in the player's record as an unconfirmed payment.
4. Tell the player the address to send the Bitcoins to.
5. Periodically poll the daemon for any recent payments, and change any unconfirmed payments to confirmed.

You could...

1. Issue a new BA to ALL users and set a tally value to 0 for each user's BA.
2. Email these BA's to your users.
2. Poll these BA's from the daemon every 10 minutes.
3. If the amount received from a BA is greater then the tally value then count the difference as a new deposit and increment the tally.

Or something similar to that.  This could be done in a separate process too.