[50 BTC total bounty] for Groupcoin development and help

[markm]

I have received the 5 BTC, thank you.

The specific DB exception problem seemed to be that neither of the two machines I was running it on had been able to download a blockchain from the other.

Both expected to initially download the blockchain but neither actually had any blocks to offer as both had only the genesis block.

I hoped this problem would solve itself once at least one block had been generated by one or the other of the two machines.

However I have now found that not only did that not happen but in fact once a block had been generated stopping and trying to restart resulted in a core dump instead of the DB exception thing.

If each client makes up a new address to generate coins to, presumably that means each client is trying to generate invalid blocks until such time as they arrange to have that address added to the database of valid miner's addresses?

I doubt I can merge your version with the version I have been deriving from the original bitcoin-qt, for example doing a diff of your db.cpp and the db.cpp currently in bitcoin-qt there is much much more change than just your vchGenerateKey stuff.

-MarkM-

[1714016580]

1714016580

[1714016580]

1714016580

[1714016580]

1714016580

[SeriousWorm]

I have a few questions.

How did you get the idea to do this? Did you get the idea yourself, or was it after extended talks with other people? Which other people? Are any of them related to bitcoin development? How did you come up with the 50% percentage? Why did you only include bitcoin open source developers, if you specified "general" open source developers?

Why do you think this idea will be successful, when so many have failed? What are your insights on why would this be a good project? What is your ideal ratio of bitcoin:groupcoin miners? Why the name Groupcoin?

Why would you "incorporate code that would keep the whitelist updated from the web every two weeks", but not incorporate code that would automatically donate 50% of the 50 BTC bounty to the group of open source developers? Do you think that if miners mine every 10 minutes on average, hundreds and potentially thousands of small transactions will generate unnnecessary work for the network? Wouldn't it be maybe more efficient to create a central site/location where miners would donate the 50% as a single transaction and then the site would store the balances of the developers, which they could then somehow access and transfer when they want (or maybe once daily, or at least 0.1btc, etc.)? Do you plan on keeping the currency as BTC? 1 Groupcoin BTC = 1 Bitcoin BTC? How will that work, anyway? I don't think a Groupcoin BTC will be able to be sent to the Bitcoin network since this is a separate blockchain, right?

If setting a single master groupcoin/bitcoin address (see the confusion?) is a potential security risk, there could be a master list of addresses which would rotate on every new block found, or every few dozen blocks, or a similar criterion. They could be fetched from a trusted location.

This project seems to be rather centralized, with lots of trusted individuals, as opposed to the main Bitcoin project.

Thanks!

[Unthinkingbit]

If each client makes up a new address to generate coins to, presumably that means each client is trying to generate invalid blocks until such time as they arrange to have that address added to the database of valid miner's addresses?

At this point there is no validation code.

The major code change is that groupcoin only uses one generation key, rather than using a new key for each block.  This makes it possible to later whitelist and validate.

What is necessary to get the while thing rolling is for you or someone else to make the genesis block, then keep your client running, but stop the miner.  Then post whatever is necessary for other groupcoin clients to link to your client, I speculate that they might need your IP, if you also changed the IRC lookup or made other changes, post whatever information is necessary for other groupcoin clients to link.  If they have to recompile something, that's ok as long as you clearly indicate where and in what files the changes must be made.

Once several groupcoin clients have found each other, then mining can start again, with each client using only one generation key.

Then we can make a whitelist, distribute it to all the miners, then test validation code.

I doubt I can merge your version with the version I have been deriving from the original bitcoin-qt, for example doing a diff of your db.cpp and the db.cpp currently in bitcoin-qt there is much much more change than just your vchGenerateKey stuff.

I prefixed all my code changes with group_coin_change so you can see what they are.

You could try prefixing all your changes with something, then assuming there are fewer of your changes then of the current group_coin_change, I'll go through groupcoin and try to incorporate your changes.  I'm hoping that your changes were few, mostly to do with the genesis block.

[Unthinkingbit]

I have a few questions.

Actually you have many questions.  They are good questions, but it takes time to answer questions, so next time please pick your top five or less.  Because you asked too many questions, I will not answer all of them.

How did you get the idea to do this?

I've been looking for a way for open source developers to get real money for a long time.  I know about charity, advertising, consulting; but I also know that for most projects, even those that have several thousand users, all of those sources of income combined give less than ten dollars a month.  For instance the bitcoin charity pools:
http://forum.bitcoin.org/index.php?topic=20455.0

currently have only a few GHash between them, one percent of that divided among all the bitcoin developers is less than five dollars per developer per month.

I don't know how successful groupcoin will eventually be, but I do know that the current methods of paying for open source development are nowhere near enough.

Did you get the idea yourself..

Yup.

How did you come up with the 50% percentage?

For maximum protection against thieves, the percentage should be 0%.  For maximum developer revenue the percentage should be 100%.  I chose the middle as the best tradeoff.

Why did you only include bitcoin open source developers, if you specified "general" open source developers?

It will start with only bitcoin open source developers.  If it is sufficiently successful, which I define as being very roughly more than 100$ worth of groupcoins per developer per month, then the criteria would be widened to open source developers in general, not just bitcoin developers.

Why do you think this idea will be successful, when so many have failed?

To the best of my knowledge, no one has attempted to make a whitelist coin to pay open source developers, so none have failed, because none have been tried.

What is your ideal ratio of bitcoin:groupcoin miners?

Eventually, I think people should have roughly equal amounts of bitcoins and groupcoins or derived coins for maximum diversification.  Mining ratios would derive from that.

Why would you "incorporate code that would keep the whitelist updated from the web every two weeks", but not incorporate code that would automatically donate 50% of the 50 BTC bounty to the group of open source developers? Do you think that if miners mine every 10 minutes on average, hundreds and potentially thousands of small transactions will generate unnnecessary work for the network? Wouldn't it be maybe more efficient to create a central site/location where miners would donate the 50% as a single transaction and then the site would store the balances of the developers, which they could then somehow access and transfer when they want (or maybe once daily, or at least 0.1btc, etc.)?

If groupcoin works, I plan on offering groupcoin bounties for a more sophisticated derived coin.  I'm starting with the simpler groupcoin because going directly to the sophisticated coin might be a bridge too far.

Do you plan on keeping the currency as BTC? 1 Groupcoin BTC = 1 Bitcoin BTC? How will that work, anyway? I don't think a Groupcoin BTC will be able to be sent to the Bitcoin network since this is a separate blockchain, right?

Groupcoin is a separate blockchain.  Not only is the genesis block & port different, but also the rules.  Any value relation between bitcoin and groupcoin would be determined by the market.

If setting a single master groupcoin/bitcoin address (see the confusion?) is a potential security risk, there could be a master list of addresses which would rotate on every new block found, or every few dozen blocks, or a similar criterion. They could be fetched from a trusted location.

This project seems to be rather centralized, with lots of trusted individuals, as opposed to the main Bitcoin project.

No matter how you try to work it, because you need a synchronized whitelist, there will be centralization and there will be an additional security risk.  However, this is the only way you could direct 50% of the mining revenue towards developers, or some kind of good cause, rather than the current roughly 1% charity; so the tradeoff is worth it.

[sacarlson]

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.

[SeriousWorm]

I have a few questions.

Actually you have many questions.  They are good questions, but it takes time to answer questions, so next time please pick your top five or less.  Because you asked too many questions, I will not answer all of them.

(cut)

Ok, thanks for the detailed answers! I know you think the questions were overly verbose but I was really curious. Good luck with the project, I hope support for mining will be added soon so we miners could start contributing.

If this takes off, I could contribute with a groupcoin<>bitcoin exchange, a live ratio ticker similar to the one on my site (see sig), and possibly other stuff.

The project channel is #groupcoin @ freenode, right?

[Transisto]

What decide who can be defined as a developer, ?

I would think the threshold to become a writer or developer is extremely vague and nothing can efficiently stop a crappy developer but good miner to send all of his other 50% to himself.

Don't the peoples with 100k+ BTC have an already high enough incentive to support development for the whole ecosystem ?

What will happen when everything BTC related that had to be done has been done ?

Look a lot like circle jerking to me.

[Unthinkingbit]

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

Thanks for posting the list of modifications.  I brought them in as noted below:

These were already done in groupcoin or bitcoin-qt.

1.already in groupcoin   modify listen port 51333
2.already in groupcoin   sendto port 51333 ; I had to modify this to prevent from connecting to other running bitcoin that I and others  would be running
4.already in groupcoin   add rpcport=51332 to config or change as default
5.already in groupcoin   modify inflation settings but low priority since they won't be changing for years

12.already in bitcoin-qt   modify irc_address=irc.lfnet.org

These were not done and I changed them in groupcoin.

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_

Changed in base58.h:
#define ADDRESSVERSION   ((unsigned char)(fTestNet ? 244 : 245))


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

Changed in main.cpp:
const char* pszTimestamp = "New York Times 1/Jul/11 page 1, U.S. Will Widen 2 C.I.A. Inquiries Into Jail Deaths";


7.modify block_hashMerkleRoot=0xd597477ef4dac6078bebd0240be7da16556ba881f047823791ddc83676d16fde  or other you might have chosen

Note, I could not define block.hashMerkleRoot because it is built in main.cpp, I could only change the assertion.
Changed in main.cpp:
assert(block.hashMerkleRoot == uint256("0xd597477ef4dac6078bebd0240be7da16556ba881f047823791ddc83676d16fde"));

8.modify genesisblock=0x00000004d621bf2f4e8209d56371b456a0181018f9416142c7a7f8a0b6f976fa

Changed in main.cpp:
uint256 hashGenesisBlock("0x00000004d621bf2f4e8209d56371b456a0181018f9416142c7a7f8a0b6f976fa");

9.modify block_nTime=1309517065

Changed in main.cpp:
block.nTime    = 1309517065;

10.modify block_nNonce=1109660235

Changed in main.cpp:
block.nNonce   = 1109660235;

11.modify irc_channel=groupcoin

Changed in irc.cpp:
if (fTestNet) {
    Send(hSocket, "JOIN #groupcoinTEST\r");
    Send(hSocket, "WHO #groupcoinTEST\r");
} else {
    // randomly join #groupcoin00-#groupcoin99
    int channel_number = GetRandInt(100);
    Send(hSocket, strprintf("JOIN #groupcoin%02d\r", channel_number).c_str());
    Send(hSocket, strprintf("WHO #groupcoin%02d\r", channel_number).c_str());
}


After I made the changes and tried to run it, I got the following runtime error:

bitcoin-qt: src/main.cpp:2022: bool LoadBlockIndex(bool): Assertion `block.hashMerkleRoot == uint256("0xd597477ef4dac6078bebd0240be7da16556ba881f047823791ddc83676d16fde")' failed.


Could you please try to run groupcoin with the changes mentioned above for the genesis block in order to reproduce the error?

[markm]

That is solvable, however, solving it for the -testnet case is sixteen times less difficult than solving it for the mainline-blockchain case.

What would have taken an hour or so to solve for -testnet using CPUs can be expcted to take 16 hours or so to solve for the mainline blockchain.

Basically all the block-building is sixteen times as difficult on the main line; multicoind mostly assumes people will be working with the -testnet version of their new currency, for example weeds exists because it is the testnet for beertokens, beertokens themselves do not exist yet.

Once I had worked through how multicoin does it with testnet chains, I then proceeded to work with the mainline part, which has been taking longer because I have not diverted any of my GPU mining to solving of groupcoin blocks (yet).

All of the hours my CPUs have been putting in though have been using the "headline" I posted earlier in this thread, pointing to this thread instead of to a newspaper.

I have changed many occurences of "Bitcoin" or "bitcoin" in the code, so that the GUI will mostly be talking about Groupcoin rather than Bitcoin.

I have not caused addresses to begin with something other than a 1 because having the same address work in several different currencies can be used to do things such as setting up exchange-bots watching for various currencies being sent to an exchange address in one currency and sending a different currency in return to the same address that sent the first currency to the exchange address. It also facilitates things like "here is my donation address, send me bitcoins or botcoins or weeds or groupcoins or whatever you wish to donate". It is my address because I have the private key, it does not matter whether any particular currency allows me to use that address it is still mine even if some currencies deny me the use of it.

-MarkM-

[sacarlson]

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.

[markm]

I have been working from bitcoin-qt

I have forked it into https://github.com/knotwork/bitcoin-qt

I don't know how to change the name of that fork so it doesn't look like I am trying to work on bitcoin-qt instead of trying to fork it to make groupcoin-qt

What I have committed there just now is from my machine that has my github keys on it, which is not actually either of my compile-boxes (I have a 32-bit compile box running Fedora 14 and a 64-bit compile box running Fedora 15).

Thus this initial test-commit does not work, it is just a starting test of how to use github, done while my actual compile-and-test boxes are busy doing other things. When the tests on the compile-and-test boxes are completed I will grab back the changes onto the communications box that communicates with github and send it to github again.

-MarkM-

[markm]

Okay I have pushed my latest changes.

There are 99 IRC channels so we'll need a lot of clients up and running if people are to have much chance of finding each other via IRC.

I am now going to try telling a normal bitcoind the hashes and so on for this blockchain to try to resolve a seeming conflict between groupcoin-qt and multicoin when multicoin is given the same values.

The values multicoin came up with for making the genesis block worked fine for multicoin but groupcoin-qt could not start from scratch with those values; any time I actually needed to build the genesis block it "realised" the merkle was wrong. The merkle that I had set in accordance with what multicoin thought it should be and worked fine with.

So I figure on trying good old bitcoind with the same values and see if it has yet another completely different idea what that hash should be or if not then whether it agrees with groupcoin-qt or multicoin as to what is should be.

-MarkM-

[sacarlson]

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]

..
push the changes you made to another branch so we can start seeing and using them.

I just created a groupcoin_unstable branch so people can reproduce the merkle assertion error:
https://github.com/Unthinkingbit/groupcoin_unstable

Also why aren't we seeing you Unthinkingbit in the freenode IRC #groupcoin?  head to head chat sometimes makes things move quicker.

I prefer the concise, permanent record of a forum thread.  Chat sometimes makes things move faster, but it takes time of its own, so I won't be there.

..
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.
..

Thanks for setting stuff up.  Once the merkle assertion error is resolved, I'll go from there.

..
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.

Good point, I'll change that in irc.cpp in my next update.

[Unthinkingbit]

If this takes off, I could contribute with a groupcoin<>bitcoin exchange, a live ratio ticker similar to the one on my site (see sig), and possibly other stuff.

Thanks for the offer.  When the project is stable enough, I'll announce that it is ready for an exchange.

I do not want a groupcoin<>bitcoin exchange before then, because there may be problems and we might have to restart block chain, which would burn people who bought groupcoins, or the derived coin, with bitcoins.

The project channel is #groupcoin @ freenode, right?

It is, but I only post in forums so I won't be there.

[Timo Y]

So whoever controls the whitelist controls the flow of money - negating the main advantage of bitcoin, that this is done by predefined algorithms, not people.

Your intentions might be good, but how do I know I can trust you in the long term (or whatever bureaucracy ends up controlling the whitelist)?  How do I know that this central authority won't start awarding itself Groupcoins by indirect means?

Also, the whole point of  a block chain is to eliminate the need for trusting a third party.  But if you are reintroducing this need, why use something as inefficient as a block chain?  You may as well just record the signed transactions in a database on your server and publish the database regularly.

[Unthinkingbit]

So whoever controls the whitelist controls the flow of money - negating the main advantage of bitcoin, that this is done by predefined algorithms, not people.

The whitelist controls the generation of money, it does not control storage or transfer.

Your intentions might be good, but how do I know I can trust you in the long term (or whatever bureaucracy ends up controlling the whitelist)?  How do I know that this central authority won't start awarding itself Groupcoins by indirect means?

It will eventually be a bureaucracy controlling the list.  The members will be drawn from the open source developers.

Indeed, in the long term, most organizations become corrupt, regardless of the intentions of the founders.  The single best defense against the corruption of an organization is competition.  Groupcoin, or its derived coin, would be the first currency to give part of its generation to developers.  However, developers are welcome to fork it in turn, and create say a reformcoin, that also gives generation to developers, but starts with another set of founders.  If the reformcoin is less corrupt than the original coin, people will sell the original coin and buy reformcoins.  Even if most people remain with the original coin, just the possibility that people could move to reformcoin will tend to rein in the corruption of the original coin.

Also, the whole point of  a block chain is to eliminate the need for trusting a third party.  But if you are reintroducing this need, why use something as inefficient as a block chain?  You may as well just record the signed transactions in a database on your server and publish the database regularly.

The need for centralization is being reintroduced for generation.  The storage and transfer is still in the hands of the client.  So it is more decentralized than handling all the transactions on one server.

[markm]

I just realised that github does not seem to recognise your fork of bitcoin-qt *as* a fork of bitcoin-qt.

Thats might complicate both inheritance of fixes and improvements to the upstream source and the use of "pull requests" and such.

I had thought that since my fork at https://github.com/knotwork/bitcoin-qt and yours were both forks of the same upstream github would have facilities useful for picking specific functionalities / additions to pull in from one to the other, but it seems that might somehow have been broken or something.

I am almost ready to branch mine, as what I have done so far will be useful for any number of bitcoin-variants whereas continuing to adapt it toward your goals will be a branching away from normal generic bitcoin-clones.

I have two instances running main code and two doing -testnet code, testing the -testnet I have found it does not switch its rpcport correclt,y is stays with the main net rpc port, otherwise I'd have four running main and four running testnet.

-MarkM-

[markm]

Since only miners need to mine, the ability to mine can simply be turned off in non-miner's clients.

So I have built groupcoind and groupcoin from the standard bitcoind and bitcoin, without cosmetics. In other words the rpcport and the datadir and the conf file name one is expected to set using commandline options or config file settings.

The groupcoin-qt though *is* cosmetic. The window it brings up is named Groupcoin, the messages it gives the user say groupcoin instead of bitcoin and so on. That is what is at https://github.com/knotwork/bitcoin-qt

The who gets to mine function should be done in a way that can be pulled into all these clients since they all are based on the standard code. It should simple be another option for the commandline or config file to turn it on or off, though the fully cosmetic groupcoin-qt would preumably have it locked into being on.

(The reason for making it an option is for ease of future variant blockchains to use the feature or not use it.)

-MarkM-

[Unthinkingbit]

I just realised that github does not seem to recognise your fork of bitcoin-qt *as* a fork of bitcoin-qt.

Indeed, I am using a copy rather a fork so I can make the generation UI change without it being overriden by the bitcoin-qt improvements.  When groupcoin, or the derived coin, is tested and stable, it will be maintained from a fork.

I have two instances running main code and two doing -testnet code, testing the -testnet I have found it does not switch its rpcport correclt,y is stays with the main net rpc port, otherwise I'd have four running main and four running testnet.

If and when you have a groupcoin version with a genesis block which whose merkle hash passes the assert, please post the parameters or a link to that version.

The who gets to mine function should be done in a way that can be pulled into all these clients since they all are based on the standard code. It should simple be another option for the commandline or config file to turn it on or off, though the fully cosmetic groupcoin-qt would preumably have it locked into being on.

I agree.  If groupcoin gets tested and stable there will be an option to turn it on or off.  Until then, during the testing phase it will continue to be on.