Quote from: grondilu on November 25, 2010, 03:15:48 PM

[...] your clients would have an account on your server, and they could change their balance into bitcoin when it reaches a significtive amount, or on a daily basis.

It makes sense to use two systems, each to patch the shortcomings of the other.

Also if clients make a 1BTC deposit (escrowed, if there is no server?), they can go "in debt" in the microcurrency without being overall in debt. This way you don't need CAPTCHAs or trust mechanisms to stop hit'n'run bad debts.

Another idea might be to make a mini-BTC-style currency. AIUI, Bitcoin's neat feature is using the proof of work to enforce one linear timestamped history, and thereby prevent double-spending. You could benefit by hanging your linear coin-spend history off this,

use "mini-blocks" in your world to log the transfers between IDs. The full anonymous wallet private key thing is optional, but the owner must sign the transfer. Presumably your world already has IDs?
choose a "mini-block" creation rate. I think it can be less than 10min, as well as 1:1 or greater delay; but there will always be the Bitcoin multi-block confirmation time if you need to know for "certain" that history is locked down irrevocably.
publish the mini-blocks, and put the hash of the top of your chain into Bitcoin's chain.. by moving 0.01BTC.
you might be able to run on free transactions for this, but otherwise the N participants must spend 0.01BTC/N per mini-block history lockdown. At 1BTC/$0.25 that looks like $1.30/year for N=100 people and 1:1 miniblock:bitcoin sync.

This way you're not sucking CPU out of the main Bitcoin network, just making a small contribution to its running for the small service you need (timestamping of hashes).