[50 BTC total bounty] for Groupcoin development and help

[Unthinkingbit]

Groupcoin would be an alternate block chain, where half of the mined coins go to open source developers and writers, and half go to the miners.  To enforce this, only miners on a whitelist are permitted to mine coins.  To get on the whitelist a miner must agree to give half their mined coins to people on the open source contributor list; if a miner ever decides break their promise and keep all the coins, that miner will be removed from the whitelist on the next periodic update.

The contributor list would be the Bitcoin Donation Information list:
https://github.com/Unthinkingbit/charity/blob/master/bitcoindonationinformation.html

with groupcoin addresses added to the contributors.

Development of the groupcoin is started at:
https://github.com/Unthinkingbit/groupcoin

Lots of help is needed to make an alternate block chain.  Currently, when the groupcoin is started for the first time it makes a 'Generation Address', which is displayed on screen and saved in the database.  All mined coins must use the 'Generation Address' for their generated 50 coins.  However, I have not tested that code, and there is no validation code at all to check that the generated coins are from an address on the whitelist.  So the tasks and corresponding bounties follow:

5 BTC to make the new genesis block.  A procedure with the freecoin code is here:
https://github.com/sacarlson/freecoin/blob/master/create_new_genisis_block.txt

It doesn't matter how you make the genesis block, whoever makes it gets the bounty.

1 BTC each for the first 5 people to run miners and keep the new groupcoin network alive until lots of people join.

10 BTC for making valid block with the generation address displayed on your screen, this will require a code fix unless by luck the untested code works.

10 BTC for making validation code to check that the block has a generation address on the whitelist.  The comma separated whitelist would look like:
Permit, 1KrtWgJMS4xq3ZEWYfdBRwYG2fHwhZfter
..

10 BTC to incorporate code that would keep the whitelist updated from the web every two weeks (the typical time for a difficulty change).

10 BTC for general help.

If someone contributes to a task, but doesn't finish it alone, they'll get a portion of the respective bounty.


But Wait There's More!!

Everyone who helps with the groupcoin gets a share of half the groupcoins!

That is, after all, the whole point of the groupcoin.  It is a way for half the coin generation to go to a good use.

In a typical economy, in the ballpark of 1% goes to charity.  So for bitcoin coin generation, that means roughly 1% * roughly 200,000 bitcoins/month = 2,000 bitcoins per month for all the good causes.  With groupcoin, half of mined coins go to charity, which means 50% * roughly 200,000 groupcoins/months = 100,000 groupcoins per month for all the good causes!

Which means even if you divide it among many, many developers, there's still enough per developer.


Groupcoin is based on the QT port of bitcoin at:
https://github.com/laanwj/bitcoin-qt

The thread for which is at:
http://forum.bitcoin.org/index.php?topic=15276.0

To prevent interfrence with bitcoin, the port and directory of groupcoin was changed.  So the home folder is .groupcoin instead of .bitcoin on Linux (Groupcoin instead of Bitcoin for Mac and Windows), also 43,000 was added to the port number.  So port 8,333 is replaced with 51,333; rpcport 8,332 is replaced with 51,332 and the testnet port 18,333 is replaced with 61,333.  Even with these changes there is a chance that groupcoin development will interfere with your bitcoin installation, so please backup and encrypt your bitcoin wallet and make a new user and operate groupcoin in there.  If something disastrous happens, like your bitcoin wallet being destroyed by groupcoin, no bitcoins will be refunded.

[1713513394]

1713513394

[1713513394]

1713513394

[1713513394]

1713513394

[1713513394]

1713513394

[sacarlson]

I can do the first part to create a new block chain in about 1.5 hours,  Sounds like you don't want any fancy changes in inflation so I'll just use the default settings of difficulty and inflation settings.  All you would need after I create the new block would be for me to send you the config file for my Multicoin software http://forum.bitcoin.org/index.php?topic=24209.0 (previosly called freecoin). The secound part I am also interested in having but havn't got it working yet as I call it licenced minning.  I hope you get someone to create that for you so I won't have to.  you will also have to have at least one system setup as minning your new blocks.  It only takes a system that can hash at 300kh/sec to start.  If you have any problems setting it up you can catch me on freenode IRC #multicoin

I've now created a MultiCoin-qt that also supports your present groupcoin coin specs.  It's now published at https://github.com/sacarlson/MultiCoin-qt   It can send and recieve on your new coin addresses spec from the qt lib gui.  your present coin spec if you didn't change it again I have published to: http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.groupcoinB the ~multicoin/docs dir also has other coin config specs that can be used for testing if you continue to have problems with your minners.  present problem I see in your minners department is lack of listeners.  for a functional network you must have at least one node that can listen to connect the group.  presently I have never seen any listeners in your #groupcoin so I was unable to test it.  A listener doesn't have to mine just enable connections on their listen port.  your only minner you have now is behind a firewall that can't be opened due to ISP problems.

Updated: appears today at two different times you have a new steady miner in your network, it looks like from france that is a listener and your net appears to be working ok at this time.

I accept any and all contributions and donations: 15jU1BqqmcaAmGcScv6nxcnuiTfdQ8tLDa

[Unthinkingbit]

I can do the first part to create a new block chain in about 1.5 hours.

That would be great.

Sounds like you don't want any fancy changes in inflation so I'll just use the default settings of difficulty and inflation settings.

Actually, I forgot to mention that I changed the generation to be constant, 50 BTC per block forever.  This change was made to give perpetual income to developers.  The change is already made in main.cpp so I don't think anything else need be changed.

The secound part I am also interested in having but havn't got it working yet as I call it licenced minning.  I hope you get someone to create that for you so I won't have to.  you will also have to have at least one system setup as minning your new blocks.

Indeed, the group coin is licensed mining.  Once it's made, people could fork it in turn to make stuff like a town coin or project coin.

[Tunes0710]

I'm happy to put one of my miners on this once it's up and running... will only be around 300MHash.. but should be enough to help kick off the project :-)

[Gavin Andresen]

if a miner ever decides break their promise and keep all the coins, that miner will be removed from the whitelist on the next periodic update.

Who decides whether or not a miner has broken the rules?

[TierNolan]

Who decides whether or not a miner has broken the rules?

It is whoever controls this page.

[markm]

I am interested in the criteria for the genesis block, because I have run several alternative blockchains for months using a ridiculously simple hack of the part of the code that creates the genesis block.

I think all I did was change the newspaper headline.

Either it seemed to me that all the math to make things add up right or hash right or whatever was in the code, or just possibly I might have moved something just a little bit to make sure the calculation did happen.

All the hints I have seen in various places about what one does to make a genesis block have caused me to be amazed that my simple hack seems to have actually worked.

A cost though is the fact that I left Satoshi his 50 coins - his ownership of the genesis block. I figured what the heck, so he gets 50 coins out of each batch of 21,000,000 that I make, am I going to begrudge him that?

Gosh I could have made an extra 50 coins by usurping Satoshi's 50 coins per blockchain. Was I a fool not to do so?

As to approved miners, since pools seem to be the wave of the future anyway why bother retrofitting approval into the daemon?

You could simply make it part of the protocol that only one or more specific hard-coded addresses can be given the generated coins, and have one pool per each such approved address. The daemons and clients need not care who the pools pay to mine, so long as the mined coins go to the designated addresses that could be all the daemons and clients need to know?

To unapprove a miner simply delete their login at the pools. They are still free to mine, they just won't be paid to.

Now about git... Sourceforge back in the day showed me exactly what command to use to suck back an svn snapshot and svn up was easy to remember ever since to stay up to date.

Can someone translate "svn co" and "svn up" into gittish, that gitorious place doesn't seem to be getting that info through to me somehow.

Sourceforge makes it clear to me how to grab a tarball made right then and there for me of the latest/current state. Sometimes the downloads button at gitorious offers more than just do you want tgz or zip but today that was all the choice I saw so I picked tgz.

Standard three-hack new currency...

1) You already changed the ports.

2) You didn't change the IRC channel so I have.  (s/bit/group/).

3) A glance at freecoin (now known as multicoin) seemed to hint one need not preserve the string length of the headline, but what the heck I always have so might as well do so again:

const char* pszTimestamp =   "For Satoshi. http://forum.bitcoin.org/index.php?topic=24813.msg312224"

That would be it, except for this new feature about restricting where minted coins go, lets grep -i validate, aha looks like actually we want CheckBlock:

main.cpp line 1699/4062

Code:

    // First transaction must be coinbase, the rest must not be
    if (vtx.empty() || !vtx[0].IsCoinBase())
        return error("CheckBlock() : first tx is not coinbase");
    for (int i = 1; i < vtx.size(); i++)
        if (vtx[i].IsCoinBase())
            return error("CheckBlock() : more than one coinbase");

I am guessing there will turn out to be a vtc[0].something which is the address the minted coins went to. That would be what we'd want to check. Once we figure out where it gets set of course so we can set it to what our check is going to check for.

If we really wanted to deny unapproved miners every crumb of solace we could worry about the checking of the rest of the transactions if possibly transaction fees might not be bundled into the coinbase transaction but hey, you want minting forever anyway so how vindictive need we be toward people who choose to mine "for free"? (As in do you want to worry about them maybe getting a transaction fee now and then?)

-MarkM-

[Unthinkingbit]

I'm happy to put one of my miners on this once it's up and running... will only be around 300MHash.. but should be enough to help kick off the project :-)

Thanks for the offer, when the groupcoin net is started I'll post the stuff in this thread.  You would be the second miner, so you'd get a bitcoin.

The contribution list for sharing 50% of your mining will be up shortly after the net is working.

Who decides whether or not a miner has broken the rules?

An extra validation step would be added in the groupcoin clients.  It would check that the coinbase address in on the whitelist.  As Markm pointed out, that extra step would be somewhere around here:

Code:

    // First transaction must be coinbase, the rest must not be
    if (vtx.empty() || !vtx[0].IsCoinBase())
        return error("CheckBlock() : first tx is not coinbase");

In pseudo code it would look like:

Code:

    // First transaction must be coinbase, the rest must not be
    if (!IsInWhitelist(vtx[0]))
        return error("CheckBlock() : first tx public key is not in whitelist");
..

bool IsInWhitelist(tx)
    transactionKey = getPublicKeybyTransaction(tx);
    whitelistKeys = getWhitelistKeysByFile();
    for (int i = 0; i < whitelistKeys.size(); i++)
        if transactionKey == whitelistKeys[i];
            return true;
    return false;

It is whoever controls this page.

Yup, that's where the list would start.  Once the groupcoin net is running, I'll ask contributors if they'd like to be administrators.  When a new contributor is nominated, if there are no objections they're added to the list.  If there is an objection, three administrators are chosen at random to see if the contributor should be added.  If the answer is no, the candidate can't ask again to be added for at least a month.

The adminstrators would get a share of the 10% administration fee.  So 50% would go to miners, 10% to administrators and 40% to the contributors.

I am interested in the criteria for the genesis block, because I have run several alternative blockchains for months using a ridiculously simple hack of the part of the code that creates the genesis block.

I think all I did was change the newspaper headline.

Either it seemed to me that all the math to make things add up right or hash right or whatever was in the code, or just possibly I might have moved something just a little bit to make sure the calculation did happen.

All the hints I have seen in various places about what one does to make a genesis block have caused me to be amazed that my simple hack seems to have actually worked.

If your system works, you'll get 3 BTC.  I can not judge whether it works or not, so if there are no objections within 3 days I'll assume it's good.

You could simply make it part of the protocol that only one or more specific hard-coded addresses can be given the generated coins, and have one pool per each such approved address. The daemons and clients need not care who the pools pay to mine, so long as the mined coins go to the designated addresses that could be all the daemons and clients need to know?

I decided on the periodically updated whitelist because if a generation key is stolen, all the clients would have to be updated.  Then if you have updating capability, you may as well make it periodic.

For the first validation bounty, you just need to validate against a file in the client directory.

The second bounty requires the client to periodically check for updates.

Now about git... Sourceforge back in the day showed me exactly what command to use to suck back an svn snapshot and svn up was easy to remember ever since to stay up to date.

Can someone translate "svn co" and "svn up" into gittish, that gitorious place doesn't seem to be getting that info through to me somehow.

I found gitorious hard to use and github easy to use.  The best git guide I found is:
http://www.kernel.org/pub/software/scm/git/docs/everyday.html

To add groupcoin to my github account I followed the github instructions made when I registered.  Then to not upload the backup files, object files and QT Creatir files, I set the .gitignore file to the following:
*~
*.o
*.pro
*.pro.user

added the entire directory recursively with:
git add .

commited with:
git commmit -a -m first

then uploaded with:
git push -u origin master

2) You didn't change the IRC channel so I have.  (s/bit/group/).

Thanks for pointing that out, I'll change that in groupcoin.

If we really wanted to deny unapproved miners every crumb of solace we could worry about the checking of the rest of the transactions if possibly transaction fees might not be bundled into the coinbase transaction but hey, you want minting forever anyway so how vindictive need we be toward people who choose to mine "for free"? (As in do you want to worry about them maybe getting a transaction fee now and then?)

If someone wants to deny themselves 25 BTC to collect crumbs, they may be able to, but I'm not worried about it.

[markm]

I decided on the periodically updated whitelist because if a generation key is stolen, all the clients would have to be updated.  Then if you have updating capability, you may as well make it periodic.

If a generation key is stolen, the thief can make some groupcoins, whoopie sheet, big deal, at least they cannot update all the clients.

If on the other hand the update key is stolen...

If you cannot keep keys safe widening the scope of the damage inappropriate access could do doesn't sound very wise to me.

...

Oh was it github not gitorius, I hardly even remembered those are two different sites.

I dont think doing the create remote archive from what is on my local disk is quite what I would be doing even though what is on my local disk is the bundle from the remote site.

I seem to recall having figured some kind of clone type command might be what they use instead of checkout but never did get it puzzled out, being usually more interested in getting compile to work.

Fedora 15 seems to have both qt and qt4, but then also it seems as if the qt is qt4. There is no qmake, but there is a qmake-qt4.

Compiling ends at an error 1 without any apparent explanation of what error has been encountered, getting rid of the -Wall in case it is merely some limit on the number of warnings allowed before sheer number of warnings counts as an error doesn't help.

I am installing qt-creator now to attempt to use project instead of makefile...

...Ouch, a GUI so stupid that it wont even let me mouse-sweep its error messages to paste. so that I have to try to hand type them from memory: "_ was not declared in this scope" or some such thing - is truly ghastly-pathetic-gross. A development tool for people who want to make sure they won't be getting any detailed error reports or something?

Presumably (_( manages to be as unlikely a construct as it at first blush might appear to someone more used to C than whatever this stuff manages to rewrite itself into. Is _ a primitive of C# or C++ or gosh knows how preprocessed by q q-code or whatever this stuff is meant to end up as or is it maybe just a macro that isn't being defined as expected, I wonder... Hey might it even be a "translate-able string follows" signal like in WML? Maybe even the very thing WML inherits that "put an underline before strings if they are to be translate-able" quirk from?

Is the localisation stuff that does that maybe some other dependency not mentioned in the README ?

Die, GUI. Lets try qmake-qt4 followed by make, again, at least mousesweep-into-pastebuffer works in text mode:

Code:

In file included from src/headers.h:91:0,
                 from src/init.cpp:4:
src/serialize.h: At global scope:
src/serialize.h: In instantiation of ‘unsigned int SerReadWrite(Stream&, T&, int, int, CSerActionUnserialize) [with Stream = CDataStream, T = CFlatData]’:
src/main.h:216:1044:   instantiated from ‘void COutPoint::Unserialize(Stream&, int, int) [with Stream = CDataStream]’
src/serialize.h:398:5:   instantiated from ‘void Unserialize(Stream&, T&, long int, int) [with Stream = CDataStream, T = COutPoint]’
src/serialize.h:739:5:   instantiated from ‘unsigned int SerReadWrite(Stream&, T&, int, int, CSerActionUnserialize) [with Stream = CDataStream, T = COutPoint]’
src/main.h:280:1230:   instantiated from ‘void CTxIn::Unserialize(Stream&, int, int) [with Stream = CDataStream]’
src/serialize.h:398:5:   instantiated from ‘void Unserialize(Stream&, T&, long int, int) [with Stream = CDataStream, T = CTxIn]’
src/serialize.h:520:13:   [ skipping 8 instantiation contexts ]
src/serialize.h:739:5:   instantiated from ‘unsigned int SerReadWrite(Stream&, T&, int, int, CSerActionUnserialize) [with Stream = CDataStream, T = CMerkleTx]’
src/main.h:870:19342:   instantiated from ‘void CWalletTx::Unserialize(Stream&, int, int) [with Stream = CDataStream]’
src/serialize.h:398:5:   instantiated from ‘void Unserialize(Stream&, T&, long int, int) [with Stream = CDataStream, T = CWalletTx]’
src/serialize.h:1089:9:   instantiated from ‘CDataStream& CDataStream::operator>>(T&) [with T = CWalletTx, CDataStream = CDataStream]’
src/db.h:89:9:   instantiated from ‘bool CDB::Read(const K&, T&) [with K = std::pair<std::basic_string<char>, uint256>, T = CWalletTx]’
src/db.h:396:65:   instantiated from here
src/serialize.h:737:21: warning: unused parameter ‘ser_action’ [-Wunused-parameter]
make: *** [init.o] Error 1

I see a warning but not an error other than "Error 1", which make tends in past experience to seem to expect whatever died to have provided some explanation of prior to dying...

-MarkM-

[Unthinkingbit]

If a generation key is stolen, the thief can make some groupcoins, whoopie sheet, big deal,
..

Actually it is a big deal, because with a stolen generation key a thief can make a huge stolen profit and eventually take over the network; this is why:

Mining is a competitive free market, with relatively low barriers to entry, so the typical profit is small.  Assume, for the sake of argument, that the typical miner revenue is 110%/month of cost, giving a profit of 10%/month, so in a market at equilibrium, the typical miner takes home 10%/month (10/110 * revenue).

Now, a thief hacks into a whitelisted miner and gets a generation key.  That thief keeps all the generation instead of sharing half, so the thief's revenue is double that of the sharing miners, so the thief's miner revenue is 220%/month of cost, giving a profit of 120%/month, which minus the take home 10/110 * revenue of 220%/month = 20%/month, gives a growth rate of 100%/month.  Say the thief starts with a mining operation which has 1% of the hash power, this is the hash power growth:

Time, Thief Hash Power
Month 1, 1%
Month 2, 2%
Month 3, 4%
Month 4, 8%
Month 5, 16%
Month 6, 32%
Month 7, 64% --> big trouble

A different profit ratio and/or take home percentage will change the time for big trouble to come; but the point is, if a thief gets a generation key and there is no way of shutting down that key, the thief will make a huge and growing profit and on top of that eventually big trouble will come.

..
at least they cannot update all the clients.

If on the other hand the update key is stolen...

If you cannot keep keys safe widening the scope of the damage inappropriate access could do doesn't sound very wise to me.

There is no single update key.

The update would be handled by the client grabbing text files from several web sites.  If more than 60% of them are identical, then the client would update its whitelist with the identical files.  The prototype of this is implemented at:
https://github.com/Unthinkingbit/charity/blob/master/pluribusunum.py

This method also gives resistance to DDOS attacks, because an attacker would have to shut down at least 40% of the web sites to stop the clients.

The web sites would be managed by administrators, who get paid for their work out of the 10% administration portion.

Compiling ends at an error 1 without any apparent explanation of what error has been encountered
..

I compiled bitcoin-qt and the derived groupcoin on Ubuntu 10.04 LTS (Lucid).

You could try compiling the original bitcoin-qt at:
https://github.com/laanwj/bitcoin-qt

The thread for which is at:
http://forum.bitcoin.org/index.php?topic=15276.0

If there are still problems, ask for help there, that's where the bitcoin-qt developers are.

The changes I made to bitcoin-qt to derive groupcoin were minor, so if you can get the original to work, the derived groupcoin should work also.  If you can get the original to work and for some reason you can not compile groupcoin, then please post the error with the derived groupcoin on this thread.

[markm]

If it is from miners that thieves are to obtain keys, keeping keys out of the hands of miners seems like a good idea.

It would not only be more code, but also more points of failure and a larger attack surface, while also being un-necessary.

If we hard-code addresses that minted coins must go to, anyone who does manage to obtain the private key of one of those addresses will be able to reward miners, or anyone else, based on any criteria they choose to use, including basing it on completed work shares in mining pools.

We can update the clients anyway in the normal way: making new versions available from official distribution sources which people are free to download and use if they choose to.

If a key does get stolen, next official version of the client can have the address associated with the stolen key removed.

Making things more complex just so that more attack surfaces will be exposed doesn't seem right, somehow.

To minimise damage from stolen keys we could change the keys on a schedule, such as each time the difficulty adjustment time comes the key(s) also change. They could change based on a hard-coded pre-generated list, and the client could even be set to die when it runs out of pre-generated keys in order to phase out old clients on a schedule too so people will have reason to come looking for updated versions from time to time.

-MarkM-

[markm]

Actual bitcoin-qt was not hard to compile, mostly I just had to tell it about ../deps/include and ../deps/lib so it could find the openssl I compiled with the parts bitcoin uses that Fedora prefers not to include in their distributions.

Maybe you could do whatever clever git thing it is that git users do to bring their branch up to date with the latest main branch or something, as yours seems rather nastily broken.

For example your Makefile wants there to be a .pro file but you have not provided that .pro file.

Also qmake-qt4 just works with the main branch, but in your branch it spews a whole bunch of help about things like having a -project mode and a -makefile mode, evidently it is confused as to which to use. Only by doing both a few times in various sequences did I get a Makefile that even attempted to compile, whereupon i am back at the unexplained Error 1 again.

Backburnered for now pending fixing of your branch I guess.

-MarkM-

[Unthinkingbit]

2) You didn't change the IRC channel so I have.  (s/bit/group/).

I looked for the IRC channel, but could not find it.  What do I have to replace with (s/bit/group).

If a key does get stolen, next official version of the client can have the address associated with the stolen key removed.

For validation code to work, all clients have to have identical whitelists.  If the whitelist is only updated when people downloaded the next client version, there will be different whitelists on different computers, which would break validation.

Making things more complex just so that more attack surfaces will be exposed doesn't seem right, somehow.

To minimise damage from stolen keys we could change the keys on a schedule, such as each time the difficulty adjustment time comes the key(s) also change. They could change based on a hard-coded pre-generated list, and the client could even be set to die when it runs out of pre-generated keys in order to phase out old clients on a schedule too so people will have resaon to come looking for updated versions from time to time.

The point is that somehow the keys have to be changed on a schedule in order to prevent damage from stolen keys.  The complexity is necessary because updating is necessary.

The complexity is manageable, pluribusunum.py is already tested, the client just has to somehow link to it to get the bounty.  Later, the code can be incorporated into the client.

Maybe you could do whatever clever git thing it is that git users do to bring their branch up to date with the latest main branch or something, as yours seems rather nastily broken.

For example your Makefile wants there to be a .pro file but you have not provided that .pro file.

Thank you for testing the bitcoin-qt branch and groupcoin.  I did not know that it was necessary to include the .pro file so I've added that to the latest groupcoin.  Please try the latest groupcoin, and see if there are still problems.

Thanks in general for the testing you've done and sharing your knowledge.  If you send me or post a bitcoin donation address, I'll send you 5 BTC from the general help bounty.

[sacarlson]

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.

[markm]

Thank you for testing the bitcoin-qt branch and groupcoin.  I did not know that it was necessary to include the .pro file so I've added that to the latest groupcoin.  Please try the latest groupcoin, and see if there are still problems.

Thanks in general for the testing you've done and sharing your knowledge.  If you send me or post a bitcoin donation address, I'll send you 5 BTC from the general help bounty.

Thanks, that .pro file might be the magic bullet.

Thanks denominated in BTC can be sent to the BTC address 1E5RcwrLGpKSSEELyg5ZbqzJaQ3XyqgULp

-MarkM

[qed]

Why anyone should prefer Grupcoin instead of Bitcoin?

[markm]

I now have the thing running initially, but after I exit the next time I try to run it a popup comes up complaining about blkindex.dat

At the commandline it output:

terminate called after throwing an instance of 'DbException'
  what():  DbEnv::close: Invalid argument
Aborted (core dumped)

I saw that you added code to plug in addresses for coins generated to be sent to, but, I didn't see you initialise that, where is it supposed to get those addresses from?

You seemed to be putting them into the wallet?

I don't see what if anything that would have to do with blkindex.dat though so i don't know what you did that might be messing up the block index.

Guess it is time to go through these same steps (firing it up on two machines, connecting them with -addnode, using -gen=1 to try to get them to mine) with the original bitcoin-qt just to make sure it is in fact something you or I did that is causing the problem...

-MarkM-

PP: even if I did prefer GRP to BTC, why would I prefer it to MBC, NKL, CDN or UKB?

[markm]

Okay, I think I have figured out that DB exception.

I have also created myself an account on github and forked bitcoin and groupcoin so I'll be ready to publish any changes ("pull requests" I guess they are called).

I have not actually published any changes yet though.

I cannot figure out how/where you are setting the actual value of the vchGenerationKey.

You seem to be storing them in the wallet, so you are presumably also loading them out of the wallet, but I do not see any place where an actual value is assigned that isn't simply another variable (where does 8that* variable get it from?)

So I do not see any example of how to put an actual string - a copy/paste of an actual address - into vchGenerateKey.

I can run the thing, generating blocks and thereby generating addresses that will have to be regarded as valid eventually since they are in the blockchain. I was going to paste the first one thus created into vchGenerateBlock so that I could have that same address continue to be used for subsequent blocks until such time as we get more addresses to plug in and some kind of database that can be used to validate the blockchain against the set of addresses that were valid at each point along the blockchain.

(You do realise, don't you, that if you want to invalidate an address from a certain block number forward you will need to record along with each address the first block at which it started being valid and the last block that it was valid?)

-MarkM-

[Unthinkingbit]

I saw that you added code to plug in addresses for coins generated to be sent to, but, I didn't see you initialise that, where is it supposed to get those addresses from?

You seemed to be putting them into the wallet?

There is only one generation address per client.  The client creates it on the first start up.  The creation code starts with:
if (mapKeys.count(vchGenerationKey))

in the file:
https://github.com/Unthinkingbit/groupcoin/blob/master/src/db.cpp

PP: even if I did prefer GRP to BTC, why would I prefer it to MBC, NKL, CDN or UKB?

When you buy, trade, give and hold GRP, you help boost the groupcoin currency, which boosts the value of all the open source developers coins.

You would prefer it to fiat currencies primarily for a moral reason, when you use GRP you help developers, when you use fiat currencies, you help banks.

Okay, I think I have figured out that DB exception.

Please post how you fixed the exception.  If it's a general problem I'll update groupcoin, if it's a specific problem, posting might help someone else who runs into the same problem.

Also, I just sent 5 BTC to the address you posted, please confirm that you received it.

[Unthinkingbit]

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.

The experts on bitcoin-qt, and Qt in general, are at:
http://forum.bitcoin.org/index.php?topic=15276.0

I can compile bitcoin-qt and groupcoin, but I do not have their knowledge and can not help anyone else with compiling qt.