We already have a released open sourced P2P poker system that's fully operational and ready to play called pokerth_accounting as seen here https://github.com/sacarlson/pokerth_accounting/wiki. It's based on the fast Stellar.org system for uncentralized real asset transactions that enable real time play, and all for free.  You can also check out the demo video's https://github.com/sacarlson/pokerth_accounting/wiki/Demonstration-Videos-of-Pokerth_Accounting

I've made some progress to make free P2P poker a reality in opensource software using the new faster crypo currency engines of Stellar.org and Ripple.com see my github to view the wiki and the present state of my code at https://github.com/sacarlson/pokerth_accounting/wiki that adds a payment modules onto an already existing and popular pokerth software.

pokerth_accounting is ready for testing today not tomaro!! The Mental poker upgrade is mentioned in my wiki as in a future addition that would not be hard to add. The Mental poker c++ libs are already published and tested as seen on another github project that shows times to shuffle well within reason on todays computers. At this point my project is ready for testing. In it's present state we use Stellar.org testnet STR and  trust line generated coins we call CHP (for chips). CHP are a worthless crypto currency that we will us just to keep score at this point and for testing the concept.  The CHP coins  are distributed to member players of pokerth from poker.surething.biz site in a one time 100,000 to start money. As far as other matters that can be a concern like collusion, With the Stellar uncentralized money system were all transaction can be seen by the public. We can track who was playing with who and when on every game ever played to research the possibility of collusion. From this information you can decide weather you want to play on a table with possible colluders or not. I've also added a primitive website that displays all the active members account ballances so you can compare you skills with others at http://poker.surething.biz . This site also contains the database to share your Stellar.org account numbers with other pokerth players. The pokerth_accounting program that runs in the background on your local system does everything invisibly without any added effort from the player of pokerth. After or durring the game you can analize your accounting with an sqlitebrowser to view what you paid who and when. Sqlitebrowser is also used to make changes in the configuration of the system allowing you to change currency or network to real money on a different network like Ripple or other. The software for the most part is completed ready to run but I'm sure we will be finding bugs to fix soon. That's why I need testers. There is no way I can test every function without realtime play involved. So if your willing to help us move this along take a look at our present evolving code at https://github.com/sacarlson/pokerth_accounting/wiki and https://github.com/sacarlson/pokerth_accounting. If you have any question you can find me at #pokerth IRC or even on pokerth game chat as sacarlson or leave me a note on github. Oh and again on the mater of Mental poker algorithm, the present game uses servers that no one ( should say not many) people have access to. So until we start playing with big money I'm not going to wory about it. Remember with Stellar.org that even in real money we can play with very small pots of even less than 1 cent worth of crypto currency of say STR. Transaction costs are so small even in real money (non testnet) the costs would be less than $3 for about 100 years (more than a life time) of play. On testnet in it's present default settings it is completely free. I should note that the next upgrade we are pushing is implementing the built in uncentralized escrow system on Stellar.org. With that and Mental poker added it should be about done. So give it a try and find out for yourself just how close we really are.  

If you have a DSL connection at home you might consider hosting a site from your home to test it out.  you can use no-ip.com to setup a constant dynamic IP address point to it and use a CNAME to redirect it from a real web site name if you have one to your changing dynamic home address example www.multicoin.net.    400    IN    CNAME    surething.no-ip.biz.  as seen with dig @8.8.8.8 www.multicoin.net.  If you need more help on this mater you can ask me direct at my IRC chat I hang out at most the time #multicoin  as nick sacarlson.  Sounds like a good Idea.  I hope I can be of help if you need any.  Good luck and take care.

I can only think that only a real market can control a price of any commodity or currency and the a central bank that dumps and buys as needed to control the price would be the only way I know to make a stable currency possible.  as I said before you can peg the value of a currency to anything you want.  It's "The Trust" holders that should decide what they want to hold as there base of value of the asset holdings and just use the crypto coins to pass the value for P2P transactions.  I have almost completed the infrastructure to make all that possible in the BeerTokens model http://bitcointalk.org/index.php?topic=9493.msg138247#msg138247.  The first beerA coins have already been minted with the new merge mining feature using MulitCoin-exp https://bitcointalk.org/index.php?topic=24209.msg300830#msg300830.  With MultiCoin  we also can setup secure exchanges with escrow deposits to prevent third parties from stealing from a central exchange.  I will continue to develop what I feel is missing in the infrastructure to make what  sounds some of you want in the near future.  The basic concept is that the holders of "The Trust" decide how they want things to be and what needs to be changed, Not the developers and miners.  Each holder on record has a voice.  You just have to make it heard by being a part of it.

We now are at preliminary review of the new BeerTokens crypto currency spec that uses MultiCoin-exp as the client.  The multicoin-exp config spec is presently published and will be updated from this site: http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.beerA .  The chain is now running at "difficulty" : 50.0 ,  That is designed to be merge mined by other namecoin miners and or bitcoin miners.  It is designed to pay .0001 BEER for each mined block up to block number 50,000 where it will pay .001 BEER.  These future mining subsidies are subject to change depending on market conditions.  This is all we could possibly afford to pay for mining at the start.  If we find we can't get miners to this payoff we might have to wait for licensed mining.  For some details on how to setup MultiCoin-exp for merge mining of BeerTokens see https://bitcointalk.org/index.php?topic=24209.msg394289#msg394289 . If you have any problems setting it up please ask us direct at freenode chat #multicoin so that we know what we need to add to the documentation to make it work for more people.  Note the spec is not finalized yet and it will be evolving over the next few days or weeks.

Update Aug 4, 2011 8:30pm BKK.  I found we have a big bug in the new Diff_post_triger and Diff_triger_block config settings in MultiCoin-exp that cause orphaned blocks after block 12 when starting a new system from an empty datadir.  So this feature will have to eather be fixed or not used.  I'll take a closer look at it tomaro.  This is what happens when you try to do too much tooo fast.

Update Aug 7, 2011 5:43pm BKK.  The above bug has been isolated and fixed with present release of MultiCoin-exp and a slightly modified bitcoin.conf.beerA .  Preliminary test all look good.  I moved out merge mining to now start at block 1500 to add more test time.  A new difficulty change point has been  added at block 1510 but we will have time to change that or delete it if we find we need to.

Update Aug 9, 2011 6:56 BKK.  We have our first merge miner connected to the beerA config spec chain.  Presently the miner is merged with Namecoin and BeerTokens mining at 370Mh/sec.  Soon there will be many more.

Status of MultiCoin-exp branch and merge mining
This article Last Updated 7/6/11
I finally made some progress on merge mining in the MultiCoin-exp branch.  With  the setup of a cpuminer branch from forrestv found at: https://github.com/forrestv/cpuminer  comitish: f7617f3f7c0eb348e1bf2af21ed5d965f05df24d
This miner was chosen as being the only known miner with algorithms that works best at difficulties less than one as we plan to use this with mergemineTEST net as parent chain that is presently at "difficulty" : 0.12500000.  At that same time the weedsnet was at  "difficulty" : 0.06249911,

and my present build of MultiCoin-exp used to run both the parent and child chains at comitish:
4e13e3527eca861964bb
I had two multicoin-exp bitcoind running with the bitcoin.config.weeds with  port settings of 38333 and rpcport of 38332 and bitcoin.config.mergmine that has port settings of 58333 and rpcport of 58332
these example configs have been released and can be seen at these url bellow:
http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.mergmineTEST
http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.weeds

to start we playing with weedsnet as the child chain and a newly created mergemineTEST chain used as a parent for the weedsnet chain.

setup merged-mine-proxy to run with corrected username:password here:
./merged-mine-proxy --parent-url http://yourusername:yourpassword@127.0.0.1:58332/ --aux-url http://yourusername:yourpassword@127.0.0.1:38332/ -w 9992

setup cpuminer
./minerd --url http://127.0.0.1:9992/ --userpass yourusername:yourpassword -t 1

I was getting these results from the miner
[2011-07-24 17:44:35] JSON-RPC call failed: {

   "message": "Unknown error: -32601 Method not found ''",

   "data": "",

   "code": -32099

}


due to the fact that the documented method shown in merged-mine-proxy shows:
 help='connect to the parent RPC at this address (default: http://pw:un@127.0.0.1:8332/)'  with reversed pw : un  that should be un : pw.   So this took some instrumented lines for me to figure out but finally got results when corrected.

we now have a working proto type merge mine setup using mergemineTEST net as the parent chain for weedsnet.   This has been done with the new released changes from namecoin mergedmine branch  release of commit 6849ac73f3577c1b445787993d134a596c89c09b that has again been merged with MultiCoin-exp.  The changes for MultiCoin-exp have now been released at: https://github.com/sacarlson/MultiCoin-exp as commit 4e13e3527eca861964bb.  I noted that I couldn't use weedsnet as the parent for MergemineTEST net due to the fact that the difficulties for weeds were smaller than that of MergemineTEST net.  This was noted by the error seen from the console of mergeminTEST of:
ERROR: AUX POW parent hash 0000000964b614867559487da64722a0e4876de8fbc45e3b15bd7e07b2f03625 is not under target 00000007fff80000000000000000000000000000000000000000000000000000
When I reversed the nets parent for child everything worked fine. as seen from miner-proxy:
2011-07-26T13:11:47.651525,solve,0,1
2011-07-26T13:16:25.894304,solve,1,1
and noteing results in block counts of both networks on the rise.  So later I will right some more detailed procedures to make clear what needed to be done.

Update: I've also merged the new changes from namecoin that now allow multi chained networks
2011-08-03T03:35:59.129965,solve,1,0,1
in this example I now have one parent and two aux chains by just running more multicoind configs and adding more --aux-url chains on the merge-miner-proxy line with space delimiter
./merged-mine-proxy --parent-url http://yourusername:yourpassword@127.0.0.1:38332/ --aux-url http://yourusername:yourpassword@127.0.0.1:10332/ http://yourusername:yourpassword@127.0.0.1:58332/ -w 9992

I've also created another merge mined chain config for BeerTokens in preliminary review published at: http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.beerA . it's set to pay .0001 for each mined block at a difficulty at block 1000 set to be 23509.0 designed to be mining by namecoin miners as the parent. AuxPowStartBlock point is set to start  at block 1000 for  AuxPowStartBlock that could be from 1 to 4 days depending on mining activity.  I guess we are ready to go just need miners to partisipate.

first problem detected not in MultiCoin-exp but in the infrastructure of our block explorer bitcoin-abe I'm getting this error from a fresh start of abe.py ,  when I run the weeds network in the merge mining mode.  I had planed to upgrade the weeds network as soon as possible to merge mining when we have a solution for this.   I now get this error OverflowError: long int too large to convert to int  detailed trace see: http://paste.ubuntu.com/652878/,  Update 7/6/11 This problem now fixed in the new release of bitcoin-abe we now have support for merge mining in a block explorer thanks again to John Tobey.

Update Aug 4, 2011 8:30pm BKK.  I found we have a big bug in the new Diff_post_triger and Diff_triger_block config settings in MultiCoin-exp that cause orphaned blocks after block 12 when starting a new system from an empty datadir.  So this feature will have to eather be fixed or not used.  This feature has only been used on the one config file http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.beerA so the beerA chain is down until this is fixed. I'll take a closer look at it tomaro.  This is what happens when you try to do too much tooo fast.

Update Aug 5, 2011 4:59pm BKK.  bug above wasn't as bad as I had thought.  it was just that I had changed the block position after it past the point, so from fresh start it would fail with orphaned blocks.  I put the setting of Diff_triger_block=11 back and every thing worked fine.  so I also added another set of values Diff_triger_blockB=1510 Diff_post_trigerB=453237473  and moved the AuxPowStartBlock=1500 to now enable merge mining at block 1500 instead of 1000 to give more time for testing.  We are now back on track all systems go.

Update Aug 14, 2011 6:34pm BKK.   I seem to have a problem with slow mining using merge mining as it's taken 7 hours to get this 2011-08-14T10:09:41.168619,solve,0,0,1,1,1
 I've got many of these 2011-08-14T09:53:57.364787,solve,0,0,0,1,1
 the "difficulty" : 0.06198025,  one the 2nd aux in this case mm2TEST should not have taken 7 hours
 this is with 270kh/sec miner
 I see no errors but it just seems very slow to mine
 ;;bc,calcd 270 0.061  shows it I should get gribble: The average time to generate a block at 270 Khps, given the supplied difficulty of 0.061, is 16 minutes and 10 seconds

I used this in the proxy line:
 /home/sacarlson/Downloads/mmproxy --parent-url http://yourusername:yourpassword@127.0.0.1:48332/ --aux-url http://yourusername:yourpassword@127.0.0.1:10332/ http://yourusername:yourpassword@127.0.0.1:12332/ http://yourusername:yourpassword@127.0.0.1:14332/ http://yourusername:yourpassword@127.0.0.1:13332/ --merkle-size 4 -w 9992

This is using MultiCoin-exp that uses vinced merged mining code for merge mining with chain configs, bitcoin.conf.namecoin diff 94035.90217415 as parent, aux1 beerA difficulty 50.0, aux2 mm2TEST diff 0.06198025, aux3 mm4TEST diff 0.01475864, aux4 mm3TEST diff 0.00441692,

anyone else getting slow results with merge mining test or did i configure something wrong or maybe my code problems?  I'll try some simpler experiments with just a parent and 1 aux to take a closer look at results.  I'm using my latest Multicoin-exp release in github commit  06602e7e09875d0e8a46  the multicoin config files are published at: http://exchange.beertokens.info/docs/multicoin/

Update 8/15/11 10:58am BKK:
 I ran another merge mine experiment of just parent and one aux with new difficulties parent of .062  and aux chain diff .010
 experment ran with 280kh/sec run from 15:07 block2 to 3:25 block 52  = about 14.4minits per block  on both parent and aux chain
 so the good news is I get about what I would expect on the parent chain  ;;bc,calcd 280 0.062
gribble: The average time to generate a block at 280 Khps, given the supplied difficulty of 0.062, is 15 minutes and 51 seconds
The bad news is I don't get as much as I would expect from the aux chain.  I just don't have a full understanding why.
;;bc,calcd 280 0.010
gribble: The average time to generate a block at 280 Khps, given the supplied difficulty of 0.010, is 2 minutes and 33 seconds
sample as seen from proxy:
2011-08-14T15:07:12.921571,solve,1,1
2011-08-14T15:08:53.573864,solve,1,1
2011-08-14T15:32:25.379898,solve,1,1
2011-08-14T15:44:39.154894,solve,1,1
2011-08-14T15:52:37.380143,solve,1,1
2011-08-14T16:08:12.520307,solve,1,1
2011-08-14T16:14:12.460611,solve,1,1
2011-08-14T16:38:22.869591,solve,1,1
2011-08-14T16:42:50.560368,solve,1,1
2011-08-14T16:52:16.580440,solve,1,1
2011-08-14T17:04:32.321299,solve,1,1
2011-08-14T17:06:32.312406,solve,1,1
2011-08-14T17:11:56.703054,solve,1,1
2011-08-14T17:15:28.470930,solve,1,1
2011-08-14T17:31:32.309536,solve,1,1
2011-08-14T17:43:20.232165,solve,1,1
2011-08-14T17:49:24.424827,solve,1,1
2011-08-14T18:04:56.335914,solve,1,1

This looks like a very good idea to me.  I've added this to the list of things to be added to MultiCoin so that your features can be used on many other crypto chains including namecoin, weeds, beer, and others that don't even exist yet.  For more details about MultiCoin see http://forum.bitcoin.org/index.php?topic=24209.msg300830#msg300830

See the top article in the create new chain section for more details on that subject.  If you need more help join us at #multicoin in freenode for direct assistance.

NameCoin Support added to MultiCoin and Multicoin-qt
Added support for the namecoin net for both MultiCoin and MultiCoin-qt with small changes and created an example bitcoin.conf.namecoin with namecoin chain specs.  preliminary tested with MultiCoin and MulitCoin-qt have been a success.  To use Multicoin-qt with namecoin I do it like this. 
Create a directory /home/yourhome/.bitcoin/namecoin.  Copy the file bitcoin.conf.namecoin from the MultiCoin-qt/doc/bitcoin.conf.namecoin  into your new created ~/.bitcoin/namecoin/ directory. Rename it to bitcoin.conf in the namecoin dir.   Then run your bitcoin-qt as it's named when it's compiled in the MultiCoin-qt like this:  cd /path_to_multicoin-qt_build/;
  ./bitcoin-qt -datadir=/home/yourhomedir/.bitcoin/namecoin ;

To build see https://github.com/sacarlson/MultiCoin-qt/blob/multicoin-qt/README.rst.  In Ubuntu 10.04  just installed and ran the qtcreator and select the *.pro file in the MultiCoin-qt dirctory and hit the build botton.

Now your starting to get the idea.  As stated in the prospectus any product, commodity or index can be used as the basis of value of the tokens to determine and hold the value to in the units in the crypto block chain.  From the start or over time “The Trust” may change what they decide to use as as a base value index or the name or any settings in the infrastructure.  In this model all decisions are bases on votes of the holders of coins in the chain much like decisions are made in corporations.     BeerTokens with Beer was only chosen in this example as  a means to communicate the concept of a method and the infrastructures needed to support such a concept and a proof of concept.  The names used and indexes or commodity used have no real bearing on the concept method of creating a stable crypto currency.  It's only to illustrate  the infrastructure and tools needed to support such a concept and proof of concept.  To make it simple anything can be changed it's all up to you “The Trust” holders.  And I and others continue to build the other parts of the infrastructure to make this and or other possibilities a reality.  So step up and be counted to make your mark to help shape the future of mankind.  Don't continue to be a helpless fish in a barrel, at the whims and under the control of the software developers, miners and or politicians and bankers.

TierNolan is correct with 100% backing you can hold the price of anything at any price.  The one fault in his statement is that we don't really plan to hold beer we just hold assets of USD or ERO or treasuries and bonds in many different currencies in many different countries and many different banks to keep the possibilities of any one country or bank or entity from being able to lock us out of any or all of our assets.  We just base the value on the commodity of beer to make it clear to the holders of "The Trust" the value of what they hold for each share.  so we don't have a problem with aging or storage.  what you may not even realize is that 90% or more of the world banks only hold 10% or less of the outstanding debt of there depositors.  We have no plan to be as unstable as any of the known banks.   Remember we have unlimited supply, we can sell as many shares as the market can bare and we can and will buy back any outstanding shares the market wishes to cash out to any degree needed to keep liquidity constant.

I didn't read all the post in your article so I might have missed something but my present MultiCoin does support P2P multisign escrow.  but at this time I can't get the Bitcoin group to be a part of it.  I am already testing it in the weeds proto test chain and will fully implement escrow in beertokens when we have decided on a security model of the new block chain.  I think that is what would be needed to start using your dirivitive escrow contract as I might now call it.  You can see more details about my escrow features in my article at: http://forum.bitcoin.org/index.php?topic=24209.0  and as I see you are also looking at models of new possible currency control method what better way than to control your own in a smaller group of more trusted friends or group you have more faith in than a government.  I see the future of a fractionating currency flood that will have to be controled by a group of people not by algorithms in a program that we can't predict the outcome of.  contracts with asset backing will also help to stablelize as long as the assets are in place to support the outcome.

Maybe you should try and tell that to Chinese who have been doing it for years to pin the value of there currency to the USD by buying and selling US treasuries.  Or maybe you have never been to Los Vegas and used casino chips that are guaranteed to be trade-able for an amount of USD.  Although I must admit I have had my doubts with the large changes in BTC over the past 30 or so days.  It's all a mater of having large enuf reserves of stable enuf asset holdings base to cover fluctuations and have an unlimited yet controlled supply of beer.  As the changes we have seen in the value of BTC go from 30 to 10 and up again I find I would not be able to hold as large a percent of "The Trusts" assets in that class of holdings as I had hoped we could do.  I have changed high estimates of needed preminted Beertokens to 26billion as compared to what we see PayPal.com has in there float units and in the event we run out we would just run a new chain that would be equally trade-able 1 to 1 shares in the central exchange to provide for infinite expansion.  And also THE most important is to have it managed by a GROUP of trustworty people not just one.

Update: as of 6/13/11 we have changed the 4 byte magic number in weeds to fix some problems and help support other things like bitcoin-abe that we now have a working version for weeds presently found in my patched branch of John Tobey's bitcoin-abe found here: https://github.com/sacarlson/bitcoin-abe  .  to upgrade to the new magic number simply update your bitcoin.conf.weeds file from MultiCoin or MultiCoin-qt github software distribution or the updated link found here: http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.weeds.  I have also found that I have to start MultiCoin from a clean empty wallet -datadir or you will still have problems supporting bitcoin-abe.  If you don't use a local running bitcoin-abe then you don't need to mess with any changes of the -datadir wallets to make corrections, just replace the bitcoin.conf.weeds file you now have and restart multicoin. So if you now fail to connect to the Weedsnet and see PROCESSMESSAGE MESSAGESTART NOT FOUND on the console you will know you have not upgraded your bitcoin.conf.weeds or you are running a version of MultiCoin older than 6/7/11.   example the way I set mine up is: cp bitcoin.conf.weeds /home/sacarlson/.bitcoin/weeds/bitcoin.conf ; bitcoind -datadir=/home/sacarlson/.bitcoin/weeds/ ;  the bitcoin.conf.weeds you us should be the new updated version that you could have got with wget http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.weeds  or from the github sources . The one at my exchange site is the most experimental version that is modified first, When I see that works I also transfer the changes to github.  Oh another thing I forgot to say was that the feature for changing the 4 byte magic number is also a somewhat new feature and you will also need to upgrade to a version of multicoin no older than release date of 6/7/11 of commitish 62c428988ec76bc97fe934c76ad8d77b7060229b or later from: https://github.com/sacarlson/MultiCoin.  As far as I can tell multicoin-qt has always had the changable 4 byte magic number feature from day 1 as it was released after 6/7/11 with the merged features from Multicoin.

I would like to get into more detail of how I would like to implement an alternate block chain method using licensed miners.   And start to answer some of the questions that might be asked.

What is licensed Mining?
Licensed mining as I envision it would be an alternate chain method with some small modifications to the present bitcoin chain rule method.  The Lic. Miner method would only allow certain miners that hold certain private keys to be able to mine as an option in some of the newly created alternate block chains of new currencies or other type data chains.  And allow networks to change the rules later if and or when they get big enough to no longer need lic. Mining.

Why would we ever need Licensed Mining?
First of all you should ask why not just make a small network clone of how bitcoin does it?  Well with a small network I have seen with my own eyes for example in testnet that my transactions I did yesterday magically disappeared.  This is what can happen in a very small underpowered network like testnet and others.  Not that I really cared in this case as I was only testing something.  But in the real world if you wanted to start a small network and start using it for something of real value you would run into problems.
    I feel small side block chains could be very useful for many different things including trust share trade transactions,  gaming score keeping and many others like something similar to namecoin for open secure methods of data keeping and transaction.  It is also useful to open up new methods of transactions sooner like P2P escrow and to provide a platform for developers to work from in a smaller scale and still be provided security even in a very small underpowered network.  And yet keep any government or other entity from having the ability to disable it by shutting down a site or stealing a computer server system.

What are the advantages?
The biggest advantage that I see is that you don't need a large powerful power hungry network to develop and test new smaller network secure methods of trade and transaction.   To accomplish some of the future goals of crypto chain transaction of speed of transaction combined with improved security between transactors with added contract embedding into the chain transactions without having to wait for these edge ideas to be accepted into the main stream bitcoin network.  To open up testing of these new methods and to prove there usefulness or possibilities for failure.  Also as I presently see it this method of distributed secured data storage would not require as much power to secure.  In this model at the very small end you only need 2 or 3 redundant miners that only require to run at about 1 hash/minit. Wow I't a GREEN idea?  In this model we don't need to burn tera flops of power to be relatively secure. for example if some government agency tried to shut a server miner down or someone steals one of the servers they wouldn't  be stopping anything and getting nothing since it would be a requirement of a miner system to use a luks encrypted partitioned system similar to something like this https://sites.google.com/site/remotekeyencrypt/home to make it difficult to even obtain one of the miner keys if stolen.  and the other miners would continue to operate as if a single miner in bitcoin network was shut down, no problem.  Even by chance the government or thief after obtaining one of the encrypted miners found a way to crack the luks encypted partition and obtained one of the miner keys out of it, that miner key could be removed from the list of accepted miners and again we would be back to normal.

What are the disadvantages?
Well in this case your talking to the wrong person oh the disadvantage is we don't have it yet.
ok I was asked how would you provide for distribution with such a method of currency?  you can't have only some miners get all the money they mine.  How could you store value in such a thing?  well I'm not sure about this part as each group would be doing different things in different ways but for example http://forum.bitcoin.org/index.php?topic=9493.0 was one of many possible alternative methods of distrubution. I'm sure there will be others that come up with better ones. (06:58:36 AM) gmaxwell: sacarlson: What is the disadvantage? Come on. The disadvantage is that it's distributed but not decentralized.  If you're worried about secondary chains getting easily reversed, why not bind them to bitcoin via the alternative chains stuff?  (07:00:11 AM) gmaxwell: Well, it's not for no reason. I mean— there are problems with small bitcoins.. basically the bitcoin security model only works if there is only one hashchain, or just a few nearly equally sized ones.  (07:00:26 AM) gmaxwell: But binding to the bitcoin chain solves that neatly. I've also been told that this idea isn't even close to what bitcoin is and is totally unrelated and that this could be done with other methods other than bitcoin or bitcoin like methods.

How does it work?
I gave you the basics above in what is Lic mining.  The how it works part is a bit more complex but I'll try to keep this in as simple a form as possible here.  First we can setup a miner with very low difficulty (07:25:58 AM) lfm: hradly, put a sleep in the mining loop and reduce the difficulty to 0.00000001.  When a miner creates a block in about the same manner as in bitcoin he adds something extra into the data of the block that includes a published nonce (an almost never to repeat incrementing number) or  just the hash of the block data  would be good enough and he signs that nonce/hash with his private key and also publishes this signed nonce and his public key number into the data.  Much the same way that we do proof of identity in bitcoin-otc with signed random number we can prove that this is one of the accepted miners for blocks.  So now on the client side when we do a scan for proof of work we add a stage that also looks at the nonce/hash  data and it's signed data and published public key,  and verify that to see if it has been signed by one of the miners by checking it against the list of public keys for each accepted miner that the client keeps in his config.   The list of accepted miners public keys could be one or many and they could be turned on or off at any time by changing the contents of the list in the configs of the clients software.  These configs could be distributed in many different methods to be decided by in the group that plan to use it.   Probably by publishing the configs at some https site would be one possible method or in the distribution method of the clients software would be another.  But it will also require that with a syncing rule that all  clients change the list of accepted miners at the same block count time so at some interval of a block counts would require update change over on the client side would have to be performed and be setup to change before the transition of the update mark block count.  This however could be overruled in the event of a rouge minner that needed to be shut down.  In that event a forced upgrade of the config at some random time might be required but hopefully never or very rarely.

Anything Else?
At this point this is only a rough draft of an idea.  I await others to provide input and corrections to this and I will continue to keep editing this post as newer better ideas come to me by others.  I hope to see even totally different methods to accomplish the same thing in a different way.  If it's too different I won't add it to this post but create another.  I am hoping to see example software patches to MultiCoin or MultiCoin-qt  or any of the other branches from Bitcoin or Bitcoin-qt for ways of doing something like this.   I will publish links to anything I find like github code that appear to be moving in a similar direction.  I don't have any money to offer you in exchange but only an added ora of love from the universal conciseness.   Thank you for your interest.

I have released my MultiCoin-qt at: https://github.com/sacarlson/MultiCoin-qt  that has now been tested to send and receive on your present spec network.  This new gui client is completely configurable for unlimited chain types and also configurable gui icon and windows title changes all from the config file.  This version also incorporates what was already in the spec that I provided you to eliminate flooding from bitcoin mainnet stream with the port and standard_ports_only=1 settings that I'm not sure you ever implemented.  The present if not changed again spec is also published at: http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.groupcoinB other specs for test and other uses are also in that directory to try if you wish.  I try to keep a library of all coin specs known so if you have new one's I will publish them too.
for more details about MultiCoin see http://forum.bitcoin.org/index.php?topic=24209.0
  
Also you might want to look at my article pertaining to Lic. Mining at: http://forum.bitcoin.org/index.php?topic=24209.msg347203#msg347203  That is working toward the goal of Lic minning as from what I see your group doing, I will have it long before you do.  Note you need to learn to crawl before you can run.

I still haven't seen any donations as I thought we had already agreed  appear, I'll provide another bitcoin address in the event you may have forgotten it.
15jU1BqqmcaAmGcScv6nxcnuiTfdQ8tLDa

Created another branch of MultiCoin called MultiCoin-qt that is a branch of bitcoin-qt using the qt gui libs
this is now completed with preliminary tests complete and published at:
https://github.com/sacarlson/MultiCoin-qt  in this gui version you can make cosmetic changes to the gui
from the config file including changing windows title and graphic icon. this version has most of the features of Multicoin except escrow at this time.

mark the spec I published only has one IRC bootstrap or #groupcoin channel not 99 as in bitcoin spec as for a smaller network we don't need it yet.  When and if groupcoin get's bigger and more premanent nodes exist you can add that change if needed.

commit 08018add715bf551402a887542b5525cbb0cdfdf for https://github.com/sacarlson/MultiCoin is now tested and working to  recieve but now have found it will not send from groupcoin config spec.  transactions were tested to the groupcoin https://github.com/sacarlson/groupcoin build commit 2239255ae7428892b1c9 that is setup to the present groupcoin spec

I found there is some strange bug in this version of groupcoin I havn't figured out that  has a problems starting from a clean empty .bitcoin datadir that cause:
bitcoin-qt: src/main.cpp:2015: bool LoadBlockIndex(bool): Assertion `block.hashMerkleRoot == uint256("0xd597477ef4dac6078bebd0240be7da16556ba881f047823791ddc83676d16fde")' failed.
Aborted

It might be easier and more useful to just merge the present bitcoin or at least my branch into bitcoin-qt to have something that works that might have usage here and else were.  I like this gui so when I have time I'll try to work on it.

I did find a solution for the block.hashMerkleRoot  problem above and the fix has been updated in my github at https://github.com/sacarlson/groupcoin . it was due to the unseen \"  quote simbols in the psztimestamp that made the merkleroot fail.  I never had to convert to hardcoded values in a program so didn't know about this kind or problem.

I can now start from clean datadir address and recieve coins but still can't send after the coins are recieved with error coin validation problems.  for something so simple hard to beleave it could be so hard.

Unthinkingbit where did all those changes of your in your last post go?  I looked in your https://github.com/Unthinkingbit/groupcoin for a commit for the last changes but I see nothing changed.  Don't make people repeat work you have already done or prevent them from seeing what you might have done wrong.  push the changes you made to another branch so we can start seeing and using them.  I agree with part of what mark says, stick with the -testnet function first as main has other complexities including check points that are not worth dealing with at this time.  I disagree with mark on the side to keep the same 8 bit header version code on the address.  It is true it will work without change but it adds the posibility that people will try to send BTC or testnet on your version client or other client and wonder why nothing comes out.  I know these specs are working as I'm already minning with these specs now in MultiCoin.   Also why aren't we seeing you Unthinkingbit in the freenode IRC #groupcoin?  head to head chat sometimes makes things move quicker.   Ok I was a bit busy with work on escrow features and had assumed mark could get you going from here.  Oh and I see you seem to want two block chains as I maybe didn't make clear main and testnet are completely different chains,  I did create a secound chain that I published for your -testnet at http://exchange.surething.biz/docs/multicoin/bitcoin.conf.groupcointest  but I thought you didn't want it so if now you changed your mind here it is.  I haven't mined any of them yet and didn't plan to.  I created a branch of your groupcoin at https://github.com/sacarlson/groupcoin with some of the changes that would be needed to run the groupcoin  spec in -testnet mode.  you can force it to be testnet all the time or reverse it to make testnet to be main and later make a testnet that works.  I have now compiled it and tested it to some degree and it seem to be working with your new spec in your code.

Ok I found the secrete to compiling the bitcoin-qt and your groupcoin version.  Not sure what you are using but in Ubuntu we use qtcreator with this you just open the *.pro file and hit the build botton.  Not sure why no one could tell me about this tool as I normaly use the command line to compile with.   I'm sure there are command line methods also that should be easy enuf to document in the doc section of your code.   After that I noted that there are a lot of differences that I couldn't easily merge my changes into so it will require custom mods.   I'm not sure at what state you are in now or what code commitish we should be working from at this time but I would suggest one small step at a time.  If it hasn't already been done these are the steps I would start from before adding the more complex licenced minning:

1.modify listen port 51333
2.modify sendto port 51333 ; I had to modify this to prevent from connecting to other running bitcoin that I and others  would be running
3.modify AddressVerson=244  ; or to another address header number from 0 - 255 so that you can't send to the wrong version of bitcoin or testnet.  I had hoped to add human readable headers to my addresses at some point like weeds_  beer_
4.add rpcport=51332 to config or change as default
5.modify inflation settings but low priority since they won't be changing for years
6.modify pszTimestamp="New York Times 1/Jul/11 page 1, U.S. Will Widen 2 C.I.A. Inquiries Into Jail Deaths"  or other you might have chosen
7.modify block_hashMerkleRoot=0xd597477ef4dac6078bebd0240be7da16556ba881f047823791ddc83676d16fde  or other you might have chosen
8.modify genesisblock=0x00000004d621bf2f4e8209d56371b456a0181018f9416142c7a7f8a0b6f976fa
9.modify block_nTime=1309517065
10.modify block_nNonce=1109660235

11.modify irc_channel=groupcoin
12.modify irc_address=irc.lfnet.org
I”m not sure the changes for dns were added in this version they are using of bitcoin so the irc_address here might need to be an ip address number instead of a name.   After these changes are made do a quick test of mining and sending transactions.   Make that one of the commitish points.   

Next step start working on the licenced minner aditions.  Looks like you have some good ideas that at some point should work.  But I think you have to move just one step at a time not do all at once.   And to stay in sync with what each of you are doing you should all meet on IRC at freenode #groupcoin  as I checked it is free.

well I'm not able to figure out the details needed to compile your groupcoin or bitcoin-qt,  I just get warnings and nothing seems to build.  I think I have all the needed libs installed on Ubuntu 10.04.  Other than that you can take a look at the configs for Multicoin that you can use as a reference or just use as a  branch point  to continue development.  I think I prefer Qt as a user so eather way is cool for me.  the link to a posible config can be found at: http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.groupcoin  that I have tested with MultiCoin https://github.com/sacarlson/MultiCoin  I have test mined it and am now at block 54.  If you want to try link into it and try it you can addnode=www.beertokens.info, and dns=1.  I don't have the IRC active at this time.