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

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

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

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

[markm]

That version has been on github all along. I mentioned quite some time ago it was working.

However, with regard to showing a generated block with its address on screen, it turned out the this GUI does not show address of generated coins. For some reason it likes to keep their addresses secret, it seems.

Apparently there is some problem with using multicoin to work out the merklehash because it imbedded extraneous quotes into the thing making it not match the string entered normally in the source code of the various clients (ones based on bitcoin, bitcoind and bitcoin-qt
so I am computing the correct merkle, and thus the correct dependent blockhash, using the genesis block creation helper loops built into my fork of bitcoin-q

The it history probably also has somewhere in it the values for use with the string as I originally game it in this thread; it was argued that the actual date on which the referred-to thread/post had happened should be in the string so I added that date and re-did the computation of the hashes. resulting in the version now online. Another version will be forthcoming with the correct values for the New York Times string in case you decide to go with that string instead.

-MarkM-

[markm]

Okay, I have generated the values for the New York Times string:

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

block.nTime    = 1309654033;
block.nBits    = 0x1d00ffff;
block.nNonce   = 4004307127;

uint256 hashGenesisBlock("0x00000000afed1142e9ce8c78ee1a9adf56540c68d6c0e0b9ebcb2f8b6872e7f9");

assert(block.hashMerkleRoot == uint256("0x20c0e8b25a781040a8edb4e106eb68bbc6bdcfbba63e0c83abb8a73e083722d2"));

I have not re-done the -testnet values yet for this string.

I also have not done  checkpoints for the first 120 blocks like in the version on github,

EDIT: ok, now I have:

    // Check that the block chain matches the known block chain up to a checkpoint
    if (!fTestNet)
        if ((nHeight ==      1 && hash != uint256("0x00000000c58f75e0fcc7c0658f55d1bced6db68848a29c5c6b0ecc7d4af2b2e3")) ||
            (nHeight ==      3 && hash != uint256("0x000000002a6634395ba29addc1e4c34035d4da1d4c39bc864a94518f7fad4f14")) ||
            (nHeight ==     10 && hash != uint256("0x00000000d0c6020c64c9c29523d8f44d775a50b9fd9cf5dfe8992f5b872534f1")) ||
            (nHeight ==     15 && hash != uint256("0x00000000ae012af62aa3182d52c7e548f41415d8c43627393a5f8198e1dcee36")) ||
            (nHeight ==     50 && hash != uint256("0x0000000054d78938cc9747d4ce6d3a98530d3f5190bdfcdff9e48db0a6824ef6")) ||
            (nHeight ==     75 && hash != uint256("0x00000000646651ee10fc2677ae7f1cfa3b3968cb71006b747e3493ae894840b2")) ||
            (nHeight ==    120 && hash != uint256("0x00000000a02bd785d293ed3403040b47f209cf5a6839fdcfbe242063fc0fb0fd")))
            return error("AcceptBlock() : rejected by checkpoint lockin at %d", nHeight);

EDIT: for the -testnet part of the code you need a separate hashGenesisBlock, time, difficulty and nonce, which are set within if fTestnet conditons so they only apply in -testnet mode:

hashGenesisBlock = uint256("0x00000003021d7adb34661a872038cc573a1faf4b6bdd6c5c82caeead586dae8f");

block.nTime    = 1309654033;
block.nBits    = 0x1d07fff8;
block.nNonce   = 200863596;

-MarkM-

[Unthinkingbit]

Okay, I have generated the values for the New York Times string:

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

block.nTime    = 1309654033;
block.nBits    = 0x1d00ffff;
block.nNonce   = 4004307127;

uint256 hashGenesisBlock("0x00000000afed1142e9ce8c78ee1a9adf56540c68d6c0e0b9ebcb2f8b6872e7f9");

assert(block.hashMerkleRoot == uint256("0x20c0e8b25a781040a8edb4e106eb68bbc6bdcfbba63e0c83abb8a73e083722d2"));
..

Great work Mark!  I tried out those values and groupcoin worked.  I've updated groupcoin and groupcoin_unstable accordingly.

So I'll release the genesis block and miner bounties.  I believe 3 BTC of the 5 BTC for the genesis block plus 1 BTC for maintaining the net = 4 BTC for you is fair.  Please confirm that you accept this.

For sacarlson, I believe 2 BTC of the 5 BTC for the genesis block plus 1 BTC for maintaining the net = 3 BTC is fair.  Please confirm that you accept this.

However, with regard to showing a generated block with its address on screen, it turned out the this GUI does not show address of generated coins. For some reason it likes to keep their addresses secret, it seems.

Could you explain further what is happening?  The groupcoin GUI displays the generation address on the main screen; are the generation addresses different that the displayed address? Are the generation addresses all the same or are they different?

[markm]

Because your groupcoin-qt did not seem to work, I forked from the upstrean: bitcoin-qt figuring that way I would be better able to distinguish whether you had broken something or it was already broken in the code you started from.

The actual chain of blocks following the genesis block will need to be started fresh as you suggested, once we know what addresses to use for the miners' half of the coins and what addresses to use for the other half of the coins.

The bitcoin-qt GUI seems to think people should not know the addresses of their generated coins. This even though I churned through 120 blocks to as to mature some coins their addres remained hidden.

Now I know what to do that actually works, I can plug these genesis values into your version since it is now known that they will work in there. I was more concerned whether they would work in bitcoin, bitcoind and bitcoin-qt, so as to be sure we really were building the chain correctly.

As to fair, sure, no problem here. Thanks,

Are you going to use 244 and 245 out of the limited number (256) of first-byte-of-address values?

If each currency uses up two,  a whole new artificial scarcity is threatened, leading maybe to a whole Assigned Numbers Authority and all that kind of politics and articially created monopolies by artificially limiting which vanity names people can use with which of thewir wallets and on and on like that, a whole ghastly can of worms

Tose numbers will determine what addresses get generated by getnewaddress, so what is shown when the addresses the coins are generated to will depend on what value the client that made that block was using at the time it made the block.

If you attempt to actually stop people using various values for that byte, then you mess up vanity addresses that people can have invested huge amounts of time and electricity computing. I know if I ever managed to find an address starting with "markmetson" I would not be pleased to find various different blockchain based currencies trying to restrict my use of that address.

However since you want to centralise a list of miners maybe creating the ground up0on which a whole new Assigned Numbers Authority and bribes or registration fees or auctions to obtain a piece of that artificially limited number of bits of addresses is well in line with your philosophy?

I noticed you code had 0 for main net addresses and 111 for test net addresses, the same as normal in most other clients. However some of the variations we played with included trying 244 for main and 245 for testnet.

Do you plan at some time to outlaw from your blockchain addresses that do not fit your idea of which species race or faithfulness of first byte is acceptable? (Artificial digital apartheid?)

-MarkM-

[markm]

I plagged the magic constants into your code and sure enough this time it did manage to bring up the GUI.

However it does not see my transactions, and furthermore i suspect it trashed my wallet because now that yours has run the groupcoin-qt I had been using all along also cannot see any transactions.

So something you are doing seems to be wiping out the contents of the wallet.

Which address it shows for my generation addresx will change depending on what value we plug in as ADDRESSVERSION, currently since your code uses 0 for main chain, it shows an address starting with a 1 in base58.

At least we will no longer have to worry about how to divide up the coins in the first 20 blocks, if the keys were destroyed by whatever it is that your code does to wallets.

-MarkM-

[markm]

When ADDRESSVERSION is set to 244 : 245,, the generation addresses shown that with a 2 instead of a 1.

They do not seem to work though. So I guess the 0 : 111 shown in your code is the correct setting for that, to get addresses that start with 1?

Or is it just that this thing is not going to work until we install the stuff about going looking for a list of address and so on?

EDIT: okay maybe it *is* working, I was used to seeing gradually-maturing blocks in bitcoin-qt so I didn't see that in fact the list of already matured blocks is streadily growing, The blocks seem to be showing up instantly? Or the ones that aren't fully matured maybe aren't showing at all?

EDIT AGAIN: definitely something strange going on. Log still shows it chugging along, but the GUI no longer does, no more transactions appearing, balance no longer climbing.

BitcoinMiner:
proof-of-work found 
  hash: 00000000a5d99f31cdfa4747fef0184d97a33b7e61c209d537a7a0b4316f34e3 
target: 00000000ffff0000000000000000000000000000000000000000000000000000
CBlock(hash=00000000a5d99f31cdfa, ver=1, hashPrevBlock=00000000ecc9d5bf51f8, hashMerkleRoot=f5cbf38951, nTime=1309995057, nBits=1d00ffff, nNonce=3601751839, vtx=1)
  CTransaction(hash=f5cbf38951, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, -1), coinbase 04ffff001d0139)
    CTxOut(error)
  vMerkleTree: f5cbf38951
07/06/2011 23:31 generated 50.00

It seems to be creating incorrect transaction-outputs.

-MarkM-

[Unthinkingbit]

As to fair, sure, no problem here. Thanks,

Four BTC have been sent.

When ADDRESSVERSION is set to 244 : 245,, the generation addresses shown that with a 2 instead of a 1.

The reason I changed the address version was because of sacarlson's post:

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_

Since this may be causing trouble, and we're on a different port than bitcoin so it's unlikely they'll be a conflict, I switched it back to 0 : 111 in:
https://github.com/Unthinkingbit/groupcoin

However it does not see my transactions, and furthermore i suspect it trashed my wallet because now that yours has run the groupcoin-qt I had been using all along also cannot see any transactions.

So something you are doing seems to be wiping out the contents of the wallet.

When groupcoin is first run, which it determines by checking to see if there is a default key, it creates a generation key.  If you ran groupcoin with the wallet already in existence created by another program which did not load the wallet with a generation key, it would see a default key so it would not make a generation key, which might lead eventually to calling a non existent key.

So please trash the groupcoin wallet, and try running groupcoin again and post the results.

There is also a really small chance that the Berkeley database version is different, as mentioned at the bottom of the bitcoin-qt readme:
https://github.com/laanwj/bitcoin-qt

However, I think that is unlikely because if you compiled both my groupcoin and your groupcoin on your machine, they would link to the same Berkeley libraries.

[markm]

The checkpoint at block 120 is a stopper, it stops you from going onward, you have to remove that checkpoint in order to proceed with block 120 and beyond.

That however assumes you are using the 244:245

To use 111:0 you might have to remove all the checkpoints, at least if you want to create using 111:0 versions instead of 244:245 versions.

When using 111:0 do all the blocks you generate have the error I showed in an earlier post?

I do not yet know whether your code always produces that error regardless of how you set ADDRESSVERSION or if maybe you are doing osmething with the address version that works when done using a 0 or 111 but fails when done with a 244 or a 245.

-MarkM-

[Unthinkingbit]

When using 111:0 do all the blocks you generate have the error I showed in an earlier post?

I haven't generated any blocks, I don't have a GPU and have never mined seriously.  All I did was run groupcoin and check to see that it passed the genesis block assert and displayed the generator key on screen.

I do not yet know whether your code always produces that error regardless of how you set ADDRESSVERSION or if maybe you are doing osmething with the address version that works when done using a 0 or 111 but fails when done with a 244 or a 245.

I'm happy to use 0 or 111, so that's why I set it back in the latest version of groupcoin.  When I changed ADDRESSVERSION I did not know it would cause problems.  May as well restart with ADDRESSVERSION 0 or 111.

There is no need for a long string of blocks.  Only two generated blocks are needed to check that the generation code is working properly.

[SeriousWorm]

If you need me to generate some blocks on my GPU just point me to the repo I need to use to build the daemon so I can connect a GPU miner to that.

I have a slowish CPU, though, and I don't mind that this is only for testing.

[markm]

This is the error that the modifications to the coin generation seem to be causing:

BitcoinMiner:
proof-of-work found 
  hash: 00000000e8441c92149b61b95f5904326491d023bf75902c0c54e70f4158e4e9 
target: 00000000ffff0000000000000000000000000000000000000000000000000000
CBlock(hash=00000000e8441c92149b, ver=1, hashPrevBlock=000000008985152e6b3c, hashMerkleRoot=2e85face5e, nTime=1310037179, nBits=1d00ffff, nNonce=2338818950, vtx=1)
  CTransaction(hash=2e85face5e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, -1), coinbase 04ffff001d0129)
    CTxOut(error)
  vMerkleTree: 2e85face5e
07/07/2011 11:13 generated 50.00
SetBestChain: new best=00000000e8441c92149b  height=129  work=558354268290
ProcessBlock: ACCEPTED

That example is with ADDRESSVERSION of 0 for main net.

Same error I was seeing when it tried to create coins with ADDRESSVERSION set to 244.

-MarkM-

[Unthinkingbit]

This is the error that the modifications to the coin generation seem to be causing:
..
    CTxOut(error)
..

I have no idea how to fix that error.  Therefore, it is time for Plan B!

Groupcoin was intended as a stepping stone to the more sophisticated Devcoin, where every miner would automatically send to a receiver on a synchronized list, according to the block number.  I started with groupcoin because I figured it would be easier, but since it turns out there's a groupcoin problem with no known solution, the only way out is to go straight to devcoin.  There will be an equivalent 50 BTC total bounty for devcoin development, the details of which will be posted later.  I will end up paying a total of at least 100 BTC for the final devcoin.

The key issue with devcoin is how to send an extra transaction.  The first test will be by creating another coinbase.  In the new devcoin at:
https://github.com/Unthinkingbit/devcoin

two coinbases are created, and the validation has been changed so that it lets through the first two coinbases.

Please try this out and see if it works.  If it does work, the subsidy will be changed, a list of receivers will be used, the second coinbase will be checked, and development will proceed from there.  If there is an error, then we'll look for another way of sending a second transaction.

There is no need to make a long block chain.  Just a few blocks would be enough to know if the idea works or not.  Even if everything works fine, the chain would have to be restarted anyways because the subsidy would have to be changed.  This is only a test.

[markm]

YOur error seems to be simply that you are either using an invalid vector as miner's address from wallet or you are using an empty one (probably by failing to retrieve it from the wallet or failing to generate it correctly before putting it into the wallet in the first place.

I am running a test right now in which I simply define the mining address as a constant right there in CrateNewBlock instead of relying on your wallet stuff to get one from the wallet.

That will at least discover whether you even are using the correct "type" for the variable you are trying to use as miner's address.

EDIT: okay, I at least have it now creating valid coinbase transactions as in not errors:

BitcoinMiner:
proof-of-work found 
  hash: 000000009b19061defaf5167c195a0d219b140badef86fe1a54d34f8e015dd8b 
target: 00000000ffff0000000000000000000000000000000000000000000000000000
CBlock(hash=000000009b19061defaf, ver=1, hashPrevBlock=00000000bbc6bf0682f3, hashMerkleRoot=2212b38bc9, nTime=1310071422, nBits=1d00ffff, nNonce=2014149509, vtx=1)
  CTransaction(hash=2212b38bc9, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, -1), coinbase 04ffff001d0123)
    CTxOut(nValue=50.00000000, scriptPubKey=326873744b5868637377524b76754e)
  vMerkleTree: 2212b38bc9
07/07/2011 20:43 generated 50.00
SetBestChain: new best=000000009b19061defaf  height=2  work=12885098499
ProcessBlock: ACCEPTED


The constant I used for the address was 2hstKXhcswRKvuN3ePuGd5DiMZ2L9EikX5T

Whether the scriptPubKey=326873744b5868637377524b76754e is simply a different representation of that same address or just some random garbage obtained by failure to convert the human-readable represenation of the address into the internal representation used as key I do not know.

-MarkM-

[markm]

In devcoin you hae exact same problem as in groupcoin, you have simply duplicated it by trying to have two coinbase transactions we would still need to find a way to specify the same miner every time for, instead of just one.

it is a violation of the protocol, checked elsewhere to result in rejecting of the block, to have more than one coinbase transaction in a block.

What it is that you need to do is to correctly construct a same again and again value to use in place of reservekey.GetReservedKey() in the line

txNew.vout[0].scriptPubKey << reservekey.GetReservedKey() << OP_CHECKSIG;

-MarkM-

[Unthinkingbit]

EDIT: okay, I at least have it now creating valid coinbase transactions as in not errors:
..    CTxOut(nValue=50.00000000, scriptPubKey=326873744b5868637377524b76754e)
..
The constant I used for the address was 2hstKXhcswRKvuN3ePuGd5DiMZ2L9EikX5T

Whether the scriptPubKey=326873744b5868637377524b76754e is simply a different representation of that same address or just some random garbage obtained by failure to convert the human-readable represenation of the address into the internal representation used as key I do not know.

If you can mine into a given key, that's great.  I first changed the generation key because I didn't know if you could mine into a public key whose private part you may not even have.

In theory, if you use a key from your receive list, you should see the transaction coming into your account.

In devcoin you hae exact same problem as in groupcoin, you have simply duplicated it by trying to have two coinbase transactions we would still need to find a way to specify the same miner every time for, instead of just one.

it is a violation of the protocol, checked elsewhere to result in rejecting of the block, to have more than one coinbase transaction in a block.

What it is that you need to do is to correctly construct a same again and again value to use in place of reservekey.GetReservedKey() in the line

txNew.vout[0].scriptPubKey << reservekey.GetReservedKey() << OP_CHECKSIG;

The point of the devcoin is that part of the generation is directly sent by the miner to a receiver on the receive list accoding to the block number.  So given the list at:
https://raw.github.com/Unthinkingbit/charity/master/almoner.csv

when the modulo of the block number and the number of entries (17 at the time of this writing) is zero the developer portion would be sent to the zeroth entry on the list:
1JEnRbir5ceXZYH7HXyQZabM4LRQU7MRsx

when the modulo is one the developer portion would be sent to the count one entry on the list:
1FyMZskjC9fXSYATVXP3TH3NNeD9E1Pynp

and so on.

The first coinbase goes to the miner as usual, it uses the GetReservedKey() function as before.  The second coinbase would go to the modulo entry on the list, although for the test it is simply going to another GetReservedKey().  To test this I changed the validation code so that it only checks if there are more than two coinbase entries in the block:

Code:

    //_devcoin_change_unthinkingbit
    //for (int i = 1; i < vtx.size(); i++)
    for (int i = 2; i < vtx.size(); i++)

        if (vtx[i].IsCoinBase())
            return error("CheckBlock() : more than one coinbase");

The initial change is just to test if a block chain can be generated with two coinbases and if the wallets all add up.  Later the coinbase generation would be changed to send the coinbase to the correct receiver for that block number and the validation would be changed to see that the second coinbase is indeed being sent in the correct amount to the correct receiver for that block number.

[markm]

More than one coinbase in a block is specifically checked for as an error by tools/code that check the blockchain is valid.

Also, if you want to send to an address, that is what normal transactions do. The problem with coinbase is there is only one coinbase transaction per block and it sends to a pubkey not to an address.

So if you want to use the coinbase to send, even if only using one coinbase like you're supposed to, you need a pubkey to send to, not an address.

Remember too that blocks have timestamps, the genesis block has a time on it so that the entire timeline can be checked for whether it looks suspicious. Blocks coming in weeks late could look like an attack, where did the missing blocks go. So it would probably be best if starting a new chain to re-do a genesis block, with a new timestamp reflecting the actual time from whence blocks then flow regular as clockwork on an average of one every ten minutes.

-MarkM-

[Unthinkingbit]

More than one coinbase in a block is specifically checked for as an error by tools/code that check the blockchain is valid.

Also, if you want to send to an address, that is what normal transactions do. The problem with coinbase is there is only one coinbase transaction per block and it sends to a pubkey not to an address.

Thank you for the information.

So if you want to use the coinbase to send, even if only using one coinbase like you're supposed to, you need a pubkey to send to, not an address.

Would it possible to make give a portion of a mined block even if your account has no money?  For example, if your account had zero coins, you mined a block worth fifty, then as the last transaction on the block the client added 'send 25 coins to a developer', would that transaction get through?

Remember too that blocks have timestamps, the genesis block has a time on it so that the entire timeline can be checked for whether it looks suspicious. Blocks coming in weeks late could look like an attack, where did the missing blocks go. So it would probably be best if starting a new chain to re-do a genesis block, with a new timestamp reflecting the actual time from whence blocks then flow regular as clockwork on an average of one every ten minutes.

Thanks for that information.  When the actual block chain goes live, it will certainly be redone from stratch.  Hopefully the testing can be done without making too many block chains.

[markm]

You can reference the output of the coinbase transaction to make a transaction that says 25 of the coins go to wherever and the change goes to wherever else. The transaction should float around waiting for the coinbase transaction to mature, I believe, whereupon it should be able to go through.

There will be a whole lot more processing to do for the checking after the fact though if you do that. Every transaction will have to be checked to see if it uses coins from the coinbase transaction, then if so all recipients checked against the list of authorised recipients.

-MarkM-

[Unthinkingbit]

You can reference the output of the coinbase transaction to make a transaction that says 25 of the coins go to wherever and the change goes to wherever else. The transaction should float around waiting for the coinbase transaction to mature, I believe, whereupon it should be able to go through.

Why would it need to wait for the coinbase transaction to mature?  Since they're in the same block, if the generate 50 coinbase transaction fails, wouldn't the send 25 coins transaction also fail?

[markm]

You can reference the output of the coinbase transaction to make a transaction that says 25 of the coins go to wherever and the change goes to wherever else. The transaction should float around waiting for the coinbase transaction to mature, I believe, whereupon it should be able to go through.

Why would it need to wait for the coinbase transaction to mature?  Since they're in the same block, if the generate 50 coinbase transaction fails, wouldn't the send 25 coins transaction also fail?

Hmm I suspect you have to NOT put the transaction that sends the coins into the same block the coins are generated in, because the sending of them cannot happen until they mature, so the transaction sending them cannot get into a block until they mature.

I think you'd make a transaction to send the coins, and just publish it so it is outside in the waiting-room waiting to get into a block.

Eventually, if the coins do mature, any transactions depending on them will finally be able to get into a block.

----------------------------------------

Meanwhile, I have found out how to plug in a hard coded miner, the commented out lines are ones I used in the process of figuring out what exactly it was that was needed for the coinbase transaction:

//    std::vector<unsigned char> minerkeyvector = reservekey.GetReservedKey();
//    std::string minerkeystring(minerkeyvector.begin(), minerkeyvector.end());
//    cout << "Reserved Key: " << EncodeBase58(minerkeyvector) << endl;
    minerkeyvector.clear();
    DecodeBase58("RXSLqizSdv5Rvsa2NtcrsgUsmYfNmpJTRzDynpid8F6cmr6MqSx3Pk9PQFPSswHoJ6ddwfsdb4ZWCRt KqzB6ZpJs",minerkeyvector);

//    std::string mineraddressstring = "2iThgTwrTtbWbRRL8WbbHGh6BX1EviRvBjz";
//    std::string minerhashstring = "2E471A48E2EDF39BC3A9DBA8703A6A36CC227F74";
//    std::vector<unsigned char> mineraddressvector(mineraddressstring.begin(), mineraddressstring.end());
//    std::vector<unsigned char> minerhashvector(minerhashstring.begin(), minerhashstring.end());

    // Create coinbase tx
    CTransaction txNew;
    txNew.vin.resize(1);
    txNew.vin[0].prevout.SetNull();
    txNew.vout.resize(1);

    //txNew.vout[0].scriptPubKey << reservekey.GetReservedKey() << OP_CHECKSIG;
    txNew.vout[0].scriptPubKey << minerkeyvector << OP_CHECKSIG;

---------------------------------------------

I suspect that RXSLqizSdv5Rvsa2NtcrsgUsmYfNmpJTRzDynpid8F6cmr6MqSx3Pk9PQFPSswHoJ6ddwfsdb4ZWCRt KqzB6ZpJs is quite likely a private key. The coinbase transactions that result though all have the same sig by which it can be recognised that the miner who signed that 50 coin transaction had the private key.

So the list you would need probably for validating that an authorised miner mined a block would be, for each miner, the sig that miner's signing of 50 coins results in.

If you were over time changing how many coins are in a coinbase transaction, like in the normal standard Bitcoin, you would maybe need for each miner the sig that results when they sign each of the numbers of coins, as I expect the sig would be different for 50 coins mined than for 25 coins mined and so on.

The test net could be useful for the miner to test what sig they do produce by signing a 50 coin (or other number of coin) coinbase transaction. It is fortunate that you plan to never change how many coins get mined!

I am about to push these changes to https://github.com/knotwork/bitcoin-qt if you will use that instead of the vanilla bitcoin-qt to base your changes on you will find most of the cosmetics making it actually look like Groupcoin rather than Bitcoin, including using .groupcoin default datadir and groupcoin.config default config file and so on and so on are also already in place.

Since Groupcoin is stale and you want to move on to Devcoin anyway, I have generated a new genesis block for a new set of cosmetics that say Devcoin and use .devcoin default data dir and devcoin.conf default config file and so on.

We can continue to test using Groupcoin then when ready to restart use Devcoin for the production system.

It occurs to me that if Groupcoin claims to be for groups, maybe either it should be a template from which to generate Thisgroupcoin and Thatgroupcoin and so on for each/any group, or it should ask the user right off the bat whether they wish to join an existing group or start a new group kind of idea. That is, take seriously the idea of being for groups, plural, instead of acting like its for some specific group.

I will likely also make the cosmetics etc for one called Towncoin, figuring that although townspeople are in principle maybe a group they might prefer to use specifically for towns Towncoins instead of generic for any group Groupcoins.

-MarkM-

[Unthinkingbit]

..
I suspect that RXSLqizSdv5Rvsa2NtcrsgUsmYfNmpJTRzDynpid8F6cmr6MqSx3Pk9PQFPSswHoJ6ddwfsdb4ZWCRt KqzB6ZpJs is quite likely a private key. The coinbase transactions that result though all have the same sig by which it can be recognised that the miner who signed that 50 coin transaction had the private key.

Wow, that's great.  Because you're making valid identical coinbases, but there is still no user friendly way to get the generation key, I'll release half the '10 BTC for making valid block with the generation address displayed on your screen', is this acceptable?

There's no need to spend much effort to make a user friendly way to get a generation key because if devcoin works, polishing of groupcoin would be abandoned.  Any unused bounties from groupcoin would be transferred to devcoin equivalents.

So the list you would need probably for validating that an authorised miner mined a block would be, for each miner, the sig that miner's signing of 50 coins results in.

If you can check the coinbase in the validation code, somewhere around here:

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

I'll try to send the coinbase value with a popen command to the generator_validator.py script:
https://github.com/Unthinkingbit/charity/blob/master/generator_validator.py

The test net could be useful for the miner to test what sig they do produce by signing a 50 coin (or other number of coin) coinbase transaction. It is fortunate that you plan to never change how many coins get mined!

The reason I'm using constant generation is so that there would always be reward for development.  Simplifying code is a nice bonus.

We can continue to test using Groupcoin then when ready to restart use Devcoin for the production system.

That's great.  Groupcoin would be an adequate coin, but because it would be necessary to keep a continuous watch on the miners it would be a lot of extra administrative work to keep the system going.  I sure hope devcoin can somehow be made to work.

It occurs to me that if Groupcoin claims to be for groups, maybe either it should be a template from which to generate Thisgroupcoin and Thatgroupcoin and so on for each/any group, or it should ask the user right off the bat whether they wish to join an existing group or start a new group kind of idea. That is, take seriously the idea of being for groups, plural, instead of acting like its for some specific group.

I will likely also make the cosmetics etc for one called Towncoin, figuring that although townspeople are in principle maybe a group they might prefer to use specifically for towns Towncoins instead of generic for any group Groupcoins.

If devcoin works, groupcoin would be dropped entirely and alternate coins would be derived from devcoin.  Groupcoin is just a stepping stone, and a fallback in case devcoin can't work.

[markm]

Wow, that's great.  Because you're making valid identical coinbases, but there is still no user friendly way to get the generation key, I'll release half the '10 BTC for making valid block with the generation address displayed on your screen', is this acceptable?

Sure, thanks. If displaying it to screen is should be like WARNING!!!!!!! THIS IS SECRET!!!!!! ANYONE WHO KNOWS IT CAN STEAL YOUR COINS!!!!!

At least that is the case if it is in fact a private key.

Maybe though the short public keys we usually see are just hashes of larger public keys and this is actually a large public key.

I do not know what it is, I simply printed what was in the variable we needed to replace, converted it into printable form, then hardcoded the printable form into the code and did the reverse conversion into the "horrible alien character set if you try to print it" form that was what actually was going into the transactions.

Look at the code commented out neaby, it has code for printing the address on stdout (console or log), so firing it up with that code uncommended and generation turned off would display on text mode screen or in log the code you need to plug in.

-MarkM-

[Unthinkingbit]

Five coins are on their way.

If displaying it to screen is should be like WARNING!!!!!!! THIS IS SECRET!!!!!! ANYONE WHO KNOWS IT CAN STEAL YOUR COINS!!!!!

At least that is the case if it is in fact a private key.

What I meant was the private part would be written to the wallet or a file and the public coinbase signature would be displayed on screen.  Regardless, this would only be useful if the devcoin can not be made, so there's no point in working on it now.

Hmm I suspect you have to NOT put the transaction that sends the coins into the same block the coins are generated in, because the sending of them cannot happen until they mature, so the transaction sending them cannot get into a block until they mature.

Would it be possible if the miners were required to have at least 25 devcoins to be allowed to mine?  Then if they mined a block they would make a normal send 25 devcoin transaction to the receiver on the list?

[sacarlson]

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

[markm]

Using modulus seems like a promising idea, how about simply combining modulus with odd-vs-even or something like that, basically odd blocks one group gets the coins even blocks the other group gets them.

So every other block it's change as to whether it must have gone to one of the devs or one of the miners.

I had modulo in mind for groups anyway, so that each group could focus their mining power on groupcoin only when it is the block their own group will get the coins from, if they chose to be selfish aka optimal-for-them about it.

Another idea would be to require transactions that take coins from the coinbase transactions to have a high transaction fee, so that even if a block isn't going to reward a particular miner with minted coins there are still transaction fees to be made a lot of the time.

Unfortunately though if that key thing *is* a private key, miners wil not really be able to mine on behalf of someone else. So although the checking of validity can just go through the lists comparing to the result-string each valid miner/dev should get, the miners wouldn't be able to walk through the lists creating coins using the correct other-person's code to give the coins to the correct party in order to move along toward the block they themselves will get the coins of.

The whole chain would be stuck waiting for the person who does have the key that the list says the next block is to be mined by.

I recall from somewhere though something about a nickname of a key, a shorter form, some kind of hash, used for example to make the addresses seen and used by human users. The key I hard-coded might just be the large form of the public key, not a private key afterall.

If that is the case, any miner can mine using any of those keys, simply following the correct sequence according to modulo and/or odd/even, basically creating coins for all the people in the lists. If that is so and they are on the list too, for some it might not seem too awful to crank out the blocks that go to others in order to as rapidly as possible get around to doing the block that goes to themselves.

-MarkM-

[Unthinkingbit]

Unfortunately though if that key thing *is* a private key, miners wil not really be able to mine on behalf of someone else.

To clarify, when you're making blocks with the hard coded miner key, is the scriptPubKey of each block the same?   By scriptPubKey I mean, for example the public out / scriptPubKey in block 1:
http://blockexplorer.com/rawblock/00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048

If that is the case, any miner can mine using any of those keys, simply following the correct sequence according to modulo and/or odd/even, basically creating coins for all the people in the lists. If that is so and they are on the list too, for some it might not seem too awful to crank out the blocks that go to others in order to as rapidly as possible get around to doing the block that goes to themselves.

That means that miners could mine groupcoin when it is the groupcoin turn, and mine for bitcoin when it isn't.  When money is at stake, if a system can be gamed it will be gamed.  For groupcoin / devcoin to work, it has to be absolutely game proof.  You would not game the system; but for example, whoever is ddosing the pools would definitely game it if it was possible, and it only takes one person to ruin it for everyone.

That's why it is necessary to eventually find some way that each block can be divided, by sending to a receiver after generation or some other way.

[Unthinkingbit]

If you need me to generate some blocks on my GPU just point me to the repo I need to use to build the daemon so I can connect a GPU miner to that.

I have a slowish CPU, though, and I don't mind that this is only for testing.

Thanks for the offer.  Indeed the speed of the miner is not important at this stage, we only need people to keep the net up.  Mining isn't even necessary, just having more nodes so that it is easier for people to connect is all that is necessary.

I currently don't have a node on the system, you'd have to read Mark's posts to see how to run a node.

[Unthinkingbit]

I still haven't seen any donations as I thought we had already agreed appear
..

You never stated you agreed to any of the bounty offers, so I didn't send any.

The current bounty offer for you is:

For sacarlson, I believe 2 BTC of the 5 BTC for the genesis block plus 1 BTC for maintaining the net = 3 BTC is fair.  Please confirm that you accept this.

If you agree to that bounty I will send it.

Earlier, after you said you were making a groupcoin block chain, I stated that you qualified for the '10 BTC for making valid block with the generation address displayed on your screen' bounty.  However after rereading your post I realized that you were not using groupcoin, and that the generation address was not constant, so I withdrew that bounty.

Because I assumed that you made a valid genesis block for the groupcoin client I still stated you qualified for the '5 BTC to make the new genesis block.' bounty.  However, after I tried your settings for the genesis block I got an assert error, so I withdrew that bounty.

When Mark made a valid genesis block for the groupcoin client, the genesis block bounty was released, and since you helped you got part of it, which is you current bounty offer.

You are doing excellent work on multicoin, more than enough to qualify for the bitcoin developer charity list, described here:
https://forum.bitcoin.org/index.php?topic=18498

You are not on that list because you never asked.  If you send me a message saying that you accept to being on that list, I'll add you.

The groupcoin bounties are specifically for the development of a groupcoin client with particular requirements.  They are not for developing alternate block chains.  An alternate block chain is a side effect of groupcoin development, it is not the reason for it.

[SeriousWorm]

Ok, so with the help of knotwork (markm), I have his fork of groupcoin up and running and have generated over 50ish blocks so far with my 300mhash/sec 6870 gpu. I'll generate for some time.

We are currently on block 3436 and counting.

So feel free to msg me if anyone needs any groupcoins.

[edit] helpful info:

I used https://github.com/knotwork/bitcoin-qt
Port is 51333 (you need to manually forward it in your router .. or make sure I'm online, I have it forwarded)
Make sure you have the relevant libboost-*-dev stuff (where * is system, filesystem, threads, etc.) .. if compile fails with the message about some part of libboost missing, just do apt-get install <whatever> (if using apt)
Also make sure you follow the instructions for building, so first do qmake, then make. Of course, get qt4-qmake and libqt4-dev before that.
You'll also need berkeleydb, it's libdb4.8-c++ or something similar.

After compilation succeeds, just run ./bitcoin-qt (it should be actually called groupcoin-qt). If you want to generate coins with a gpu, make sure to have a groupcoin.conf in ~/.groupcoin, the format is the same as for bitcoin.conf. If running under a VM, use rpcallowip=* and forward the specified port in your VM settings. Daemon should be set to 0 because it crashes on startup if ran as daemon (without a gui).

[Unthinkingbit]

Ok, so with the help of knotwork (markm), I have his fork of groupcoin up and running and have generated over 50ish blocks so far with my 300mhash/sec 6870 gpu. I'll generate for some time.
..
helpful info:
..

For mining with groupcoin you get 1 BTC for the first 5 groupcoin miners bounty.  For your helpful info you get 2 BTC from the general help bounty, for a total of 3 BTC.  Please post your donation address and I'll send them.

We are currently on block 3436 and counting.

I don't know why so much hash power is being used on the experimental groupcoin chain, which will be thrown away when the genesis block is reset.  The groupcoins in the current chain will not count towards anything, the first 5 miners will only get the 1 BTC bounty for keeping the network up.  If and when there is a real devcoin or groupcoin chain, it will be announced.  If anyone wants to put a lot of hash power to a good cause, please use it instead on the bitcoin developer charity pool:
http://charitycoin.coinncarry.com/

For groupcoin testing, a CPU miner suffices.  People could leave the CPU miner on groupcoin and point their GPU miner at the charity pool.

[SeriousWorm]

Ok, so with the help of knotwork (markm), I have his fork of groupcoin up and running and have generated over 50ish blocks so far with my 300mhash/sec 6870 gpu. I'll generate for some time.
..
helpful info:
..

For mining with groupcoin you get 1 BTC for the first 5 groupcoin miners bounty.  For your helpful info you get 2 BTC from the general help bounty, for a total of 3 BTC.  Please post your donation address and I'll send them.

183DMPnYWejo59A2P9SftbgfiQULjLHHry - thanks!

We are currently on block 3436 and counting.

I don't know why so much hash power is being used on the experimental groupcoin chain, which will be thrown away when the genesis block is reset.  The groupcoins in the current chain will not count towards anything, the first 5 miners will only get the 1 BTC bounty for keeping the network up.  If and when there is a real devcoin or groupcoin chain, it will be announced.  If anyone wants to put a lot of hash power to a good cause, please use it instead on the bitcoin developer charity pool:
http://charitycoin.coinncarry.com/

For groupcoin testing, a CPU miner suffices.  People could leave the CPU miner on groupcoin and point their GPU miner at the charity pool.

I only mined with my gpu for an hour or so, maybe two. It's not really much, I only gave my 300mhash/sec, and I wanted to help testing this project. I'm not mining currently but again, if any of the developers wants me to, I'll point my gpu to groupcoin.
I can also compile anything you want, and can forward any needed ports.

[markm]

Someone pointed out that CPU mining is actually rather wasteful of energy, the same amount of mining can be done with less energy by GPUs so even if only a small amount of hashing is wanted it is still more ecological to do it with a GPU than a CPU if you have a GPU anyway.

I think we will retain interest, and open ports, and miners ready to start on the new chain once the features for it have been coded and tested, by meanwhile continuing to mine GRouPcoin while working on the new features that DEVcoin can start from scratch with. By the time we are ready to start up DEVcoin we should have several seed IPs and DNS seeds already in place, we should try to have at least eight probably not just five,

The current GRouPcoin has a testnet associated with it too, however there is apparently a new standard emerging whereby some information about the type of a chain will be encoded into its ADDRESSVERSION so we should check whether using 244 for the test chain and 245 for the main chain fits that system. I think it was determined that 245 is right for the main one but not sure about 244 for the test one.

We should also check whether we can simply move on to 246 for test devcoin and 247 for main devcoin or if some other numbers should be used for those.

All of the variants I have created for various groups in the past have been relying upon simply not releasing their specs, port numbers, IP addresses and so on, operating from behind bots of various kinds in various venues and of course over and under the counter person to person trades. Now that there is a variant that is out in the open they all want to use it as an easier to aquire public-blockchain currency than BTC and NMC that they hope to aquire quite a bit of to add to their "reserves" and to hopefully provide another gateway in and out of their own currently still private-blockchain currencies. I am adding GRP to the portfolio of currencies my bots support, to facilitate its use among these other alternates.

-MarkM-

[Shattienator]

Another "permanent" node is up and running at 50.19.210.139:51333 24/7/365 (I hope  ).
It have pretty fast internet connection and provides full groupcoin blockchain in a fraction of a second.

It is configured for a long-term run (for at least 1 year) and later can easily serve as seeding node for Groupcoin and Devcoin (and much more).

[Unthinkingbit]

183DMPnYWejo59A2P9SftbgfiQULjLHHry - thanks!

I sent 3 BTC to that address, please confirm receipt.

Another "permanent" node is up and running at 50.19.210.139:51333 24/7/365 (I hope  ).
..

Thanks for setting up the node.  Please post your donation address and I'll send you the 1 BTC miner bounty.

[Unthinkingbit]

Devcoin bounties, 50 BTC total

1) 10 BTC for sending coins to a hard coded address when mining a block.

2) 10 BTC for sending coins to the receiver on the list updated from the web by calling the receiver update script:
https://github.com/Unthinkingbit/charity/blob/master/receiver.py

3) 10 BTC to validate the sending transaction to a hard coded address.

4) 10 BTC to validate the sending transaction to the receiver on the list updated from the web by calling an update script.

5) 10 BTC for general help.


Note, for bounties 1 and 2 there is no need to create a devcoin, you could complete those tasks by altering groupcoin.

For the sending coins to a hard coded address, you could try the following code at the very beginning of the CreateNewBlock function in main.cpp.  The 'payTo' address is just an example, you should change it to one of your own receive addresses.  If you try it out and post the result, even if the code does not work, you will get part of the general help bounty.  The better the attempt and the more detailed result you post, the greater the bounty:

Add the include at the top of main.cpp:

Code:

#include <QApplication>

Add the following code in main.cpp, at the beginning of the "CBlock* CreateNewBlock(CReserveKey& reservekey)" function:

Code:

    qint64 payAmount = 2000000;
    QString payTo = QString("17vec4jQGCzMEsTnivizHPaowE715tu2CB");
    uint160 hash160 = 0;

    if(!AddressToHash160(payTo.toUtf8().constData(), hash160))
    {
        return NULL;
    }

    CRITICAL_BLOCK(cs_main)
    {
        // Send to bitcoin address
        CWalletTx wtx;
        CScript scriptPubKey;
        scriptPubKey << OP_DUP << OP_HASH160 << hash160 << OP_EQUALVERIFY << OP_CHECKSIG;

        std::string strError = pwalletMain->SendMoney(scriptPubKey, payAmount, wtx, true);
        if (strError == "")
        {
            // OK
        }
        else if (strError == "ABORTED")
        {
            return NULL;
        }
        else
        {
            return NULL;
        }
    }

[markm]

I get an error:

QMetaMethod::invoke: Unable to handle unregistered datatype 'bool*'

I actually do not know C++, but I do know that in C you cannot compare strings the way your code above tries to. So, I googled "C++ std::string compare", which seemed to indicate we might have more luck with something more like

Code:

        if (strError.compare("") == 0)
        {
            // OK
        }
        else if (strError.compare("ABORTED") == 0)

I still get the QMetaMethod::invoke: Unable to handle unregistered datatype 'bool*' though.

I read someplace that google took me that things created momentarily by the Qt toolkit can vanish after the statement thus that it might be wise to do something like

const char* payToStr = payTo.toUtf8().constData();

to make sure the value didn't vanish by the time we use it, but that too failed to eliminate the bool* complaint.

I think I have pretty much exhausted my guesses as to what the heck is using a bool* or leading Qt to imagine it is a bool*

But wait, I think the string compare returns 0 for true, weirdly enough, so I need == 0 in the code above, which I'll now edit above and then try...

...segfault, lovely. Well maybe you can figure out what makes Qt think you have a bool* somewhere in there...

-MarkM-

[Unthinkingbit]

I get an error:

QMetaMethod::invoke: Unable to handle unregistered datatype 'bool*'

I don't think it's the string that's giving you the error, because you'll see the same type of comparison code in ProcessMessage also in main.cpp, like:
if (strCommand == "version")

So whatever headers are required to make the comparison work are in main.cpp.

After you posted your error, I realized the payAmount was an integer in satoshis, rather than being a float, so please change the payAmount line to:

    qint64 payAmount = 2000000;

and try again.

I've found that usually if there is a Qt error, it's a problem of missing includes.  I looked through the headers in walletmodel.cpp where the SendMoney call is copied from and walletmodel.h, the only thing I thought could be missing would be:
#include <QObject>

if that doesn't do it, you could try adding all the includes in walletmodel.cpp.

Good luck:)

[markm]

I try this with two instances using -connect to connect them to each other and to no-one else.

One of them creates the transaction you want, but the other still segfaults.

So even adding all the headers from walletmodel.cpp it still isn't quite right.

-MarkM-

[Unthinkingbit]

I try this with two instances using -connect to connect them to each other and to no-one else.

One of them creates the transaction you want, but the other still segfaults.

So even adding all the headers from walletmodel.cpp it still isn't quite right.

Could you please try modifying only one instance and leaving the other instance as it was.  Then trying it again to isolate the error a bit.  Also, you could try to sending to an address that you do not own, like one of the addresses on the contributor list:
https://raw.github.com/Unthinkingbit/charity/master/bitcoindonationinformation.html

[markm]

The Qt stuff, and maybe the Qthreads even, are giving me a hard time.

Miners don't use a GUI anyway, they use the daemon version.

This seems to work in groupcoind:

Code:

    uint64 payAmount = 2000000;
    std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";
    uint160 hash160 = 0;

    if(!AddressToHash160(payTo, hash160))
    {
     	return NULL;
    }

    CRITICAL_BLOCK(cs_main)
    {
        // Send to bitcoin address
     	CWalletTx wtx;
        CScript scriptPubKey;
        scriptPubKey << OP_DUP << OP_HASH160 << hash160 << OP_EQUALVERIFY << OP_CHECKSIG;

        std::string strError = SendMoney(scriptPubKey, payAmount, wtx, true);
        if (strError == "")
        {
            // OK
       	}
        else if (strError == "ABORTED")
        {
            return NULL;
        }
        else
        {
            return NULL;
        }
    }

Mind you, it seems to happen a lot more than just when a block is created. Hmm...

-MarkM-

[SeriousWorm]

183DMPnYWejo59A2P9SftbgfiQULjLHHry - thanks!

I sent 3 BTC to that address, please confirm receipt.

Confirmed - thanks!

[Shattienator]

Another "permanent" node is up and running at 50.19.210.139:51333 24/7/365 (I hope  ).
..

Thanks for setting up the node.  Please post your donation address and I'll send you the 1 BTC miner bounty.

1PtPbUJnjeCsD2dvTeKQLSttLg75G2k9Vb

[Unthinkingbit]

..
This seems to work in groupcoind:
..
Mind you, it seems to happen a lot more than just when a block is created. Hmm...

I believe that's because the CreateBlock function is called on every attempt to mine.  Even if the attempt is unsuccessful, the send transaction will still be made.  There might even be a set of send transactions per thread.

So to only make a send transaction in the mined block itself, I've copied over part of the SendMoney code, without the CommitTransaction part.  In theory, if this block is not mined, it shouldn't show up as a transaction.  The code follows:

Code:

    uint64 payAmount = 2000000;
    std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";
    uint160 hash160 = 0;

    if(!AddressToHash160(payTo, hash160))
    {
     	return NULL;
    }

    CRITICAL_BLOCK(cs_main)
    {
        // Send to bitcoin address
     	CWalletTx wtx;
        CScript scriptPubKey;
        scriptPubKey << OP_DUP << OP_HASH160 << hash160 << OP_EQUALVERIFY << OP_CHECKSIG;


        // std::string strError = SendMoney(scriptPubKey, payAmount, wtx, true);
        // ..
        // is replaced by:
        CReserveKey reservekey(pwalletMain);
        int64 nFeeRequired;
        pwalletMain->CreateTransaction(scriptPubKey, payAmount, wtx, reservekey, nFeeRequired);
    }

A potential problem is that the "reservekey(pwalletMain)" part, because you didn't call the SendMoney function will a wallet.  If "reservekey(pwalletMain)" doesn't work, you could try:
reservekey.GetReservedKey();

[markm]

THe pwallet thing doesn't exist in groupcoind, it is part of the Qt GUI I guess.

Here is what I tried in groupcoind, might as well first get something working there before dealing with all the extra complicAtion of a GUI.

Code:

    int64 payAmount = 2000000;
    std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";
    uint160 hash160 = 0;

    if(!AddressToHash160(payTo, hash160))
    {
        return NULL;
    }

    CRITICAL_BLOCK(cs_main)
    {
     	// Send to bitcoin address
        CWalletTx wtx;
        CScript scriptPubKey;
        scriptPubKey << OP_DUP << OP_HASH160 << hash160 << OP_EQUALVERIFY << OP_CHECKSIG;

        int64 nFeeRequired;
        if (CreateTransaction(scriptPubKey, payAmount, wtx, reservekey, nFeeRequired))
        {
            // OK
        }
	else
	{
            return NULL;
        }
    }

I mined a block, no sign of a transaction. I am letting it mine one more block in case maybe the transaction doesn't get to be in the block we were working when we initiated its creation... No, no luck. No sign of the transaction.

-MarkM-

[Unthinkingbit]

I mined a block, no sign of a transaction. I am letting it mine one more block in case maybe the transaction doesn't get to be in the block we were working when we initiated its creation... No, no luck. No sign of the transaction.

Could you try adding the CommitTransaction right before CheckWork is called in the miner.

Code:

    if (!CommitTransaction(wtx, reservekey))
        return _("Error: The transaction was rejected.  This might happen if some of the coins in your wallet were already spent..");

Because you would need wtx in the CommitTransaction scope, you'd have to move the create money code block:

Code:

    int64 payAmount = 2000000;
..
        if (CreateTransaction(scriptPubKey, payAmount, wtx, reservekey, nFeeRequired))
..

out of CreateBlock to just before it in the miner function.

Hopefully, the create money block would add the transaction to the block, then if the miner succeeds, the entire block would be committed to memory and relayed to the other nodes.  That's the hope anyways;)

[markm]

Since the list of beneficiaries is to be centralised anyway, you might as well just send all the coins to one central account. Include in the block some inidcation of who mined it so the central clearing-house can send them their cut.

That gets rid of all the complication of distributing the list, having to have the list avilable at the time you mine a block and so on.

If the checking of coinbase transactions would work even if all miners did like Satoshi and included arbtrary strings in their coinbase transaction there would be plenty of room to indentify themselves heck they could even list a few next of kin or somply like Satoshi make some commentary on day to day affairs.

If the normal coinbase checks don't in fact allow extra data like in the genesis block then some kind of transaction could be put in the block at some easy to find spot, such as the first transaction, showing in some way who the miner was.

We have to rely on the administrator of the list anyway, at least this way we not have to rely on the list to be online, just that some day the admin will run a batch job that will send us our cut of the coins we mined.

-MarkM-

[Unthinkingbit]

I just thought of why there was no sign of a transaction, and how to complete the transaction.  You could add right after:

    pblock->vtx.push_back(txNew);

the wallet transaction

    pblock->vtx.push_back(wtx);

Code:

CBlock* CreateNewBlock(CReserveKey& reservekey)
{
    int64 payAmount = 2000000;
    std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";
    uint160 hash160 = 0;

    if(!AddressToHash160(payTo, hash160))
    {
        return NULL;
    }

    // Send to bitcoin address
    CWalletTx wtx;
    CRITICAL_BLOCK(cs_main)
    {
        CScript scriptPubKey;
        scriptPubKey << OP_DUP << OP_HASH160 << hash160 << OP_EQUALVERIFY << OP_CHECKSIG;

        int64 nFeeRequired;
        if (CreateTransaction(scriptPubKey, payAmount, wtx, reservekey, nFeeRequired))
        {
            // OK
        }
	else
	{
            return NULL;
        }
    }

..

    // Add our coinbase tx as first transaction
    pblock->vtx.push_back(txNew);

    // Add created but not committed wallet transaction
    pblock->vtx.push_back(wtx);

If this works, later the wallet transaction could be moved out of scope and CommitTransaction could use the same wallet transaction, 'wtx'.  With only the above code, the receiver should see the transaction, which is enough to test the code.  Later CommitTransaction would be added so the miner wallet would balance.

Since the list of beneficiaries is to be centralised anyway, you might as well just send all the coins to one central account. Include in the block some inidcation of who mined it so the central clearing-house can send them their cut.
..

It's best to decentralize it as much as possible to avoid a single point of failure.

That gets rid of all the complication of distributing the list, having to have the list avilable at the time you mine a block and so on.

That code is already done.  The list would eventually be on many sites, so it would be resistant to ddos attacks.

We are probably close to finding some way to have part of mined blocks automatically go to a receiver.  If we can't find a way, then something like the original groupcoin would be used instead.

[Unthinkingbit]

Hi Mark,

Thanks for the work on sending transaction, I sent you 6 bitcoins from the devcoin general help bounty.

1PtPbUJnjeCsD2dvTeKQLSttLg75G2k9Vb

Thanks for setting up the node, I sent one BTC to that address, please confirm receipt.

[Shattienator]

1PtPbUJnjeCsD2dvTeKQLSttLg75G2k9Vb

Thanks for setting up the node, I sent one BTC to that address, please confirm receipt.

receipt confirmed

[markm]

I received the 6 BTC, thanks.

wtx was out of scope for the push so I had to move it outside of the critical block loop, whereupon it seems this method does work, in groupcoind. So at least we know it seems to work. Not sure what exactly we have to do in the -qt version to make it work there.

Code:

    // Prepare to pay a beneficiary
    int64 payAmount = 2000000;
    std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";
    uint160 hash160 = 0;

    if(!AddressToHash160(payTo, hash160))
    {
     	return NULL;
    }

    CWalletTx wtx;
    CRITICAL_BLOCK(cs_main)
    {
     	// Send to bitcoin address
        CScript scriptPubKey;
        scriptPubKey << OP_DUP << OP_HASH160 << hash160 << OP_EQUALVERIFY << OP_CHECKSIG;

        int64 nFeeRequired;
        if (CreateTransaction(scriptPubKey, payAmount, wtx, reservekey, nFeeRequired))
        {
            // OK
        }
	else
        {
            return NULL;
        }
    }
    // Beneficiary's transaction prepared, will push after coinbase...

    CBlockIndex* pindexPrev = pindexBest;

    // Create new block
    auto_ptr<CBlock> pblock(new CBlock());
    if (!pblock.get())
        return NULL;

    // Create coinbase tx
    CTransaction txNew;
    txNew.vin.resize(1);
    txNew.vin[0].prevout.SetNull();
    txNew.vout.resize(1);
    txNew.vout[0].scriptPubKey << reservekey.GetReservedKey() << OP_CHECKSIG;

    // Add our coinbase tx as first transaction
    pblock->vtx.push_back(txNew);

    // Add created but not committed beneficiary transaction
    pblock->vtx.push_back(wtx);

-MarkM-

[Unthinkingbit]

wtx was out of scope for the push so I had to move it outside of the critical block loop, whereupon it seems this method does work, in groupcoind.

Does the miner now send only when it successfully mines a block and not when it tries to generate but fails?  Do the 0.02 groupcoins show up in the receiver's account?

So at least we know it seems to work. Not sure what exactly we have to do in the -qt version to make it work there.

While it would be nice if it worked in the -qt version, it's not necessary for the bounty or the devcoin beta.  As long as there is some way for miners to mine, that's all that's required.

If and when devcoin works, then a devcoin bounty would be offered from the devcoin generation to pay for -qt version development.

[markm]

When it was sending for every attempt to mine, a whole lot more transactons were being created because my tests were run using a four core machine talking to a two core machine so there were four mining threads on one and two on the other I think.

So it did look as if it were only sending when it actually mined a block.

The coins showed in the transactions list on the receiver's machine, I actually wasn't sure what the balance had been in the reciever's account before the test so couldn''t actually see if they were added to the balance.

EDIT: I ran (my, forked from bitcoin-qt) groupcoin-qt at one end and my test groupcoind at the other. The 0.02 showed up at the receiving end no problem. I then ran my groupcoin-qt instead of the test groupcoind on the sending end and it did show that it had sent the 0.02.

So it is looking good. I have let it out into the network in fact so all will see it.

-MarkM-

[smoothie]

When is this block chain/network tentatively going to be released for beta testing or actual start date?

[smoothie]

So a miner's coins get destroyed if they break their promise? Where do those coins go?

[smoothie]

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

It is whoever controls this page.

How many people have access to that page? One person? Two? What's to stop those people with the control of that page to collude with a select few others in the network to remove certain people from the whitelist?

Seems like a non-decentralized system if you ask me.

Retorts to my comments are very much welcome. Please show me what I am missing.

[markm]

It is decentralised transacting, but somewhat-centralised (limited to a group) mining.

You have too trust your miners, the more so the smaller you are, so one of them does'nt just buy a bunch of hashing from some vendor and overpower the network.

To help trust your miners, licensing who gets to mine is one approach that seems it might be worth trying.

You could of course issue all your coins in the genesis block so miners do not have the tempation of minted coins to entice them into trying to out-mine their peers, but that still leaves the fact they could soup up their hashing poer to more than 50% of the whole network and start corrupting the blockchain: double-spending or whatever.

There are many groups, possibly even including towns, who would like their own people to participate in processing blocks but are not eager for one reason or another to open that job to the whole wild west of web.

So we are working on features that might be of use or at least interest to such groups.

Currently a lot of small blockchains are simply keeping their connect info to themselves and operating behind IRC bots, in-game bots and so on; possibly the features we develop for devcoin will also be of use to them, allowing them to open their chain up to "thick clients" instead of having to have their unwashed public use only "thin clients".

-MarkM-

[markm]

I tried python  receiver.py -directory test -input receiver.csv -step 2000 -subsidy 50 -value 1995

It wanted a file test/receiver/randomnumber.txt so I echoed a few digits number to make such a file.

Now each time I repeat the command I get the exact same address, the top one on the list.

What are the step and the value about?

Maybe the value is meant to be the block number or something so I get same address because I am in effect asking about the same block each time?

The addresses are bitcoin addresses not groupcoin address by the way... we should either convert them () or find out these people's groupcoin addresses...

-MarkM-

[Unthinkingbit]

EDIT: I ran (my, forked from bitcoin-qt) groupcoin-qt at one end and my test groupcoind at the other. The 0.02 showed up at the receiving end no problem. I then ran my groupcoin-qt instead of the test groupcoind on the sending end and it did show that it had sent the 0.02.

So it is looking good. I have let it out into the network in fact so all will see it.

Wow that's great, that's the key to the whole thing.  So you win the 10 BTC for sending coins to a hard coded address when mining a block, which I've sent.

Later the CommitTransaction function, or parts of it, should be called so the sending wallet balances, but that can be done after devcoin is beta, funded with devcoin bounties.

Just as you wrote:

I tried python  receiver.py -directory test -input receiver.csv -step 2000 -subsidy 50 -value 1995
..

I finally finished the text below;)

So with real instructions, please try again.

For the next bounty, "send coins to the receiver on the list..", the following scripts and code blocks are needed.  First download the following files into the same folder as devcoin (right now groupcoin-qt):

https://github.com/Unthinkingbit/charity/blob/master/pluribusunum.py
https://github.com/Unthinkingbit/charity/blob/master/receiver.py
https://github.com/Unthinkingbit/charity/blob/master/receiver_0.csv

Then replace the addresses in receiver_0.csv with two of your test addresses:

Code:

Format,pluribusunum
Peer,https://raw.github.com/Unthinkingbit/charity/master/receiver.csv
Coin,2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M
Coin,<another address you control>

Then add the function to the file which the CreateNewBlock function you're using is:

Code:

std::string getPythonResult(const std::string& argumentString)
{
    FILE *filePointer;
    int pathLength = 8192;
    char path[pathLength];

    filePointer = popen((std::string("python ") + argumentString).c_str(), "r");

    while (fgets(path, pathLength, filePointer) != NULL)

    int status = pclose(filePointer);
    return std::string(path);
}

Finally, in CreateNewBlock replace the hard coded payTo line:

std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";

with:

Code:

    std::ostringstream heightStream;
    heightStream << pindexPrev->nHeight+1;
    std::string heightString = heightStream.str();
    std::string payTo = getPythonResult(std::string("receive.py") + heightString);

If everything compiles, connects and works, you'll be automatically sharing your mined blocks with addresses in the receive_0.csv list.

Good luck:)

The addresses are bitcoin addresses not groupcoin address by the way... we should either convert them () or find out these people's groupcoin addresses...

In theory, I believe people could export their keys from bitcoin and reimport them into devcoin.  Since they would be getting 1,000+ devcoins a week, it would be worth their time:)


EDIT: I uploaded the latest version of receive.py at about the same time I posted the instructions.  So download it again, the instructions only work with the latest version.

[markm]

It pastes the number onto the end of the filename:

python: can't open file 'receive.py5108': [Errno 2] No such file or directory
python: can't open file 'receive.py5108': [Errno 2] No such file or directory
python: can't open file 'receive.py5108': [Errno 2] No such file or directory

So I tried adding a space after the filename, also corrected name to receiver.py

Still got errors. The top of receiver.py claims it wants lots of arguments, so I ended up with this:

Code:

CBlock* CreateNewBlock(CReserveKey& reservekey)
{
    CBlockIndex* pindexPrev = pindexBest;

    // Create new block
    auto_ptr<CBlock> pblock(new CBlock());
    if (!pblock.get())
        return NULL;

    // Create coinbase tx
    CTransaction txNew;
    txNew.vin.resize(1);
    txNew.vin[0].prevout.SetNull();
    txNew.vout.resize(1);
    txNew.vout[0].scriptPubKey << reservekey.GetReservedKey() << OP_CHECKSIG;

    // Add our coinbase tx as first transaction
    pblock->vtx.push_back(txNew);

    // Prepare to pay a beneficiary
    int64 payAmount = 2000000;

//    std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";
    std::ostringstream heightStream;
    heightStream << pindexPrev->nHeight+1;
    std::string heightString = heightStream.str();
    std::string payTo = getPythonResult(std::string("receiver.py -directory ./ -input receiver.csv -step 2000 -subsidy 50 -value ") + heightString);

    uint160 hash160 = 0;

    if(!AddressToHash160(payTo, hash160))
    {
     	return NULL;
    }

    CWalletTx wtx;
    CRITICAL_BLOCK(cs_main)
    {
     	// Send to bitcoin address
        CScript scriptPubKey;
        scriptPubKey << OP_DUP << OP_HASH160 << hash160 << OP_EQUALVERIFY << OP_CHECKSIG;

        int64 nFeeRequired;
        if (CreateTransaction(scriptPubKey, payAmount, wtx, reservekey, nFeeRequired))
        {
            // OK
        }
	else
	{
            return NULL;
        }
    }
    // Add created but not committed beneficiary transaction
    pblock->vtx.push_back(wtx);

    // Collect memory pool transactions into the block

But that too gives errors:

Code:

  File "receiver.py", line 67, in <module>
    main()
  File "receiver.py", line 64, in main
    writeOutput(sys.argv)
  File "receiver.py", line 58, in writeOutput
    text = getOutput(directoryName, fileName, int(stepString), float(subsidyString), int(valueString))
  File "receiver.py", line 40, in getOutput
    modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
  File "receiver.py", line 67, in <module>
    main()
  File "receiver.py", line 64, in main
    writeOutput(sys.argv)
  File "receiver.py", line 58, in writeOutput
    text = getOutput(directoryName, fileName, int(stepString), float(subsidyString), int(valueString))
  File "receiver.py", line 40, in getOutput
    modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
  File "receiver.py", line 67, in <module>
    main()
  File "receiver.py", line 64, in main
    writeOutput(sys.argv)
  File "receiver.py", line 58, in writeOutput
    text = getOutput(directoryName, fileName, int(stepString), float(subsidyString), int(valueString))
  File "receiver.py", line 40, in getOutput
    modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
  File "receiver.py", line 67, in <module>
    main()
  File "receiver.py", line 64, in main
    writeOutput(sys.argv)
  File "receiver.py", line 58, in writeOutput
    text = getOutput(directoryName, fileName, int(stepString), float(subsidyString), int(valueString))
  File "receiver.py", line 40, in getOutput
    modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero

What are the various arguments about, and which one should the block number be plugged into?

-MarkM-

[Unthinkingbit]

It pastes the number onto the end of the filename:

python: can't open file 'receive.py5108': [Errno 2] No such file or directory
python: can't open file 'receive.py5108': [Errno 2] No such file or directory
python: can't open file 'receive.py5108': [Errno 2] No such file or directory

So I tried adding a space after the filename, also corrected name to receiver.py

Indeed, it should of been "receiver.py " rather than "receive.py".

Still got errors. The top of receiver.py claims it wants lots of arguments, so I ended up with this:
..

As I mentioned too late in the EDIT at the bottom of the post:

EDIT: I uploaded the latest version of receive.py at about the same time I posted the instructions.  So download it again, the instructions only work with the latest version.

Try the latest version.  It has code to accept just the height string without anything else.

What are the various arguments about, and which one should the block number be plugged into?

With the latest one, just the block number is enough.  So something like this:

python receiver.py 0

is valid for testing.  Over the next few hours I'll add documentation, but you should be able to test it now with just the block number (nHeight + 1).

EDIT: I just noticed that the block number is 5108, I thought it wouldn't be more than 2000 for a week.  So for testing, change the step to 100,000.  To do that replace:

"receiver.py "

with:

"receiver.py -step 100000 -height "

[markm]

EDIT: oops, I had generator_0.csv instead of receiver_0.csv !

Trying again...

Still got errors, plus it made few more receiver-#.csv files with bitcoin addresses instead of groupcoin addresses in them

Code:

 Traceback (most recent call last):
  File "receiver.py", line 76, in <module>
    main()
  File "receiver.py", line 73, in main
    writeOutput(sys.argv)
  File "receiver.py", line 67, in writeOutput
    text = getOutput(directoryName, fileName, int(heightString), float(shareString), int(stepString))
  File "receiver.py", line 44, in getOutput
    modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
  File "receiver.py", line 76, in <module>
    main()
  File "receiver.py", line 73, in main
    writeOutput(sys.argv)
  File "receiver.py", line 67, in writeOutput
    text = getOutput(directoryName, fileName, int(heightString), float(shareString), int(stepString))
  File "receiver.py", line 44, in getOutput
    modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
  File "receiver.py", line 76, in <module>
    main()
  File "receiver.py", line 73, in main
    writeOutput(sys.argv)
  File "receiver.py", line 67, in writeOutput
    text = getOutput(directoryName, fileName, int(heightString), float(shareString), int(stepString))
  File "receiver.py", line 44, in getOutput
    modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
  File "receiver.py", line 76, in <module>
    main()
  File "receiver.py", line 73, in main
    writeOutput(sys.argv)
  File "receiver.py", line 67, in writeOutput
    text = getOutput(directoryName, fileName, int(heightString), float(shareString), int(stepString))
  File "receiver.py", line 44, in getOutput
    modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero

-MarkM-

[Unthinkingbit]

By the way, just in case you didn't see the last edit:

EDIT: I just noticed that the block number is 5108, I thought it wouldn't be more than 2000 for a week.  So for testing, change the step to 100,000.  To do that replace:

"receiver.py "

with:

"receiver.py -step 100000 -height "

[Unthinkingbit]

EDIT: oops, I had generator_0.csv instead of receiver_0.csv !

Trying again...

Still got errors, plus it made few more receiver-#.csv files with bitcoin addresses instead of groupcoin addresses in them

Did you see the edit and try replacing:

"receiver.py "

with:

"receiver.py -step 100000 -height "

[markm]

Yes, that gives memory errors:

Code:

ThreadBitcoinMiner exiting, 3 threads remaining
Running BitcoinMiner with 2 transactions in block
Running BitcoinMiner with 2 transactions in block
Running BitcoinMiner with 2 transactions in block
received: verack (0 bytes)
received: getaddr (0 bytes)
received: getblocks (805 bytes)
getblocks -1 to 00000000000000000000 limit 500
sending: addr (6451 bytes) 
No valid UPnP IGDs found
07/14/11 04:04 hashmeter   3 CPUs   1373 khash/s
keypool reserve 1687
BitcoinMiner:
proof-of-work found  
  hash: 0000000010f5a34386a950f513f882e267a7b209a06d12b3c9a5c62b12230956  
target: 0000000014c1a700000000000000000000000000000000000000000000000000
CBlock(hash=0000000010f5a34386a9, ver=1, hashPrevBlock=00000000124e9fdb6c96, hashMerkleRoot=3e5d46afd4, nTime=1310616451, nBits=1c14c1a7, nNonce=3761439628, vtx=2)
  CTransaction(hash=2346014636, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, -1), coinbase 04a7c1141c0135)
    CTxOut(nValue=50.00000000, scriptPubKey=049bbea080bd5b23ae401f6d1763ba)
  CTransaction(hash=6d3e0083a2, ver=1, vin.size=1, vout.size=2, nLockTime=0)
    CTxIn(COutPoint(394bf27d17, 0), scriptSig=304502200e7ebd73e2375a9d)
    CTxOut(nValue=25.26880000, scriptPubKey=OP_DUP OP_HASH160 ce4a95fb61d2)
    CTxOut(nValue=0.02000000, scriptPubKey=OP_DUP OP_HASH160 d4d5b4cae13b)
  vMerkleTree: 2346014636 6d3e0083a2 3e5d46afd4 
07/14/11 04:07 generated 50.00
keypool keep 1687
WalletUpdateSpent found spent coin 25.2888bc 394bf27d17ed6799ef16f5f853ad79e3673997b4ae53a13812dc1d07402acdf8
AddToWallet 2346014636  new
AddToWallet 6d3e0083a2  new
SetBestChain: new best=0000000010f5a34386a9  height=5111  work=92566489266000
ProcessBlock: ACCEPTED
sending: inv (37 bytes) 
*** glibc detected *** /home/bitcoin/bitcoin/groupcoind-PRIVNET: malloc(): memory corruption: 0x00007f701409a010 ***
received: getdata (37 bytes)
received getdata for: block 0000000010f5a34386a9
sending: block (473 bytes) 
*** glibc detected *** /home/bitcoin/bitcoin/groupcoind-PRIVNET: malloc(): memory corruption: 0x00007f7014097010 ***
*** glibc detected *** /home/bitcoin/bitcoin/groupcoind-PRIVNET: malloc(): memory corruption: 0x00007f701409c010 ***
keypool reserve 1799
07/14/11 04:07:40 Flushing wallet.dat
^C

Notice also that for some reason one of my four CPU's threads was stopped right at the start.

(Maybe though that could be caused by the miner connecting, maybe it drops one of its CPU mining threads in favour of feeding getwork to the miner? Hmm not sure.)

On the bright side though, the other machine did receive the 0.02

EDIT: the string you are returning from your getPythonResult routine is allocated inside that routine, thus is a local variable of that routine. It would need to be copied into some larger-scope allocated memory to survive beyond the invocation of the routine. That might be the memory problem. Do std::string objects auto-allocate space for themselves or do you have to do that explicitly like in C ?

-MarkM-

[Unthinkingbit]

Yes, that gives memory errors:
..

On the bright side though, the other machine did receive the 0.02

Since there were no python errors posted and the other machine received coins, that probably means receiver.py is working correctly.

Code:

ThreadBitcoinMiner exiting, 3 threads remaining
..

Memory errors and a thread dying indicate it could be a popen thread problem.  Popen is apparently not thread safe:
http://lists.uclibc.org/pipermail/uclibc-cvs/2011-May/029585.html

So please try running the miner with only one thread.  If that fixes the error, then unfortunately, the only certain way I can see to fix the problem is to port all of receiver.py and pluribusunum to C++ in devcoin.  Otherwise, maybe there is some thread safe way of calling python code from a multithreaded C++ application.

[markm]

Threads might turn out to be a problem, but might it simply be that the memory you allocated for the result of your getPythonResult routine gets de-allocated when that routine ends, thus leaving the char* pointers referring to it pointing at de-allocated memory?

In other words did you see my edit above:

EDIT: the string you are returning from your getPythonResult routine is allocated inside that routine, thus is a local variable of that routine. It would need to be copied into some larger-scope allocated memory to survive beyond the invocation of the routine. That might be the memory problem. Do std::string objects auto-allocate space for themselves or do you have to do that explicitly like in C ?

EDIT AGAIN: I don't understand C++ scope, I tried moving the returned string's allocation to just above the function so it would exist outside the function, but then inside the function claimed it was not in scope! So I guess I have no idea how to use variables that exist outside a function from inside the function. Weird as surely lots of functions are using variables declared outside them, I just haven't figured out how they decide which ones they can use and which ones they will decide are "out of scope"...

-MarkM-

[Unthinkingbit]

EDIT: the string you are returning from your getPythonResult routine is allocated inside that routine, thus is a local variable of that routine. It would need to be copied into some larger-scope allocated memory to survive beyond the invocation of the routine. That might be the memory problem. Do std::string objects auto-allocate space for themselves or do you have to do that explicitly like in C ?

Well, it's worth a try.  Try using the code below.

Code:

    int pathLength = 8192;
    char path[pathLength];
    std::ostringstream heightStream;
    heightStream << pindexPrev->nHeight+1;
    std::string heightString = heightStream.str();
    getPythonResult(std::string("receiver.py -step 100000 -height ") + heightString, path, pathLength)
    std::string payTo = std::string(path);

Code:

void getPythonResult(const std::string& argumentString, char* path, int pathLength)
{
    FILE *filePointer;

    filePointer = popen((std::string("python ") + argumentString).c_str(), "r");

    while (fgets(path, pathLength, filePointer) != NULL)

    int status = pclose(filePointer);
}

EDIT AGAIN: I don't understand C++ scope..

I don't understand it either, I just keep playing around with a trivial test case till it works.

EDIT2:  I just updated the code. deleting the return variable.  Path is only passed through now, it is converted to a std:string outside.

[markm]

I moved the declarations of the crucial items to the very top of the file, just inside the critical block identifier:

//
// Global state
//

CCriticalSection cs_main;

    const int pyResultLength = 8192;
    char pyResult[pyResultLength];




and I changed the routine a little to accomodate that:

std::string getPythonResult(const std::string& argumentString)
{
    FILE *filePointer;

    filePointer = popen((std::string("python ") + argumentString).c_str(), "r");

    while (fgets(pyResult, pyResultLength, filePointer) != NULL)

    int status = pclose(filePointer);
    return std::string(pyResult);
}

This time all four threads ran. But I still got memory errors. I am not confident though that I am not still confusing pointers and arrays. I got compile errors trying to use &pyResult but am not sure just plain old pyResult is actually the same thing as &pyResult. Been a long time since I used C a lot. Gotta think hard on this.

Could be you are right though about it being a thread problem.

-MarkM-

[markm]

I tried it your way too. Still get memory corruption. Notice it happens 4 times. Maybe you are correct about it being the thread-safe problem.

Code:

Running BitcoinMiner with 2 transactions in block
Running BitcoinMiner with 2 transactions in block
Running BitcoinMiner with 2 transactions in block
Running BitcoinMiner with 2 transactions in block
07/14/11 05:15 hashmeter   4 CPUs   1343 khash/s
BitcoinMiner:
proof-of-work found  
  hash: 000000000d2655bd92fe0c45a1aa5176324ab7a07ae7b1fa60ac324e4a96a02b  
target: 0000000014c1a700000000000000000000000000000000000000000000000000
CBlock(hash=000000000d2655bd92fe, ver=1, hashPrevBlock=00000000140c7f022ff7, hashMerkleRoot=bcda71509c, nTime=1310620588, nBits=1c14c1a7, nNonce=411743883, vtx=2)
  CTransaction(hash=54eba8ca6e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, -1), coinbase 04a7c1141c0111)
    CTxOut(nValue=50.00000000, scriptPubKey=04ef6abceb89cf2c0bb444cb55157d)
  CTransaction(hash=b80248d783, ver=1, vin.size=1, vout.size=2, nLockTime=0)
    CTxIn(COutPoint(2b12e8a5e1, 0), scriptSig=3046022100fb67b8e49b74b5)
    CTxOut(nValue=25.23880000, scriptPubKey=OP_DUP OP_HASH160 e148bc3e1d31)
    CTxOut(nValue=0.02000000, scriptPubKey=OP_DUP OP_HASH160 59504bfa9821)
  vMerkleTree: 54eba8ca6e b80248d783 bcda71509c 
07/14/11 05:16 generated 50.00
keypool keep 1679
WalletUpdateSpent found spent coin 25.2688bc 2b12e8a5e165923c8ad80946f2538f940ae1a95339bb94296ee972e31e96476d
AddToWallet 54eba8ca6e  new
AddToWallet b80248d783  new
SetBestChain: new best=000000000d2655bd92fe  height=5112  work=92619461300770
ProcessBlock: ACCEPTED
sending: inv (37 bytes) 
*** glibc detected *** /home/bitcoin/bitcoin/groupcoind-PRIVNET: malloc(): memory corruption: 0x00007f5d0c56e010 ***
received: getdata (37 bytes)
received getdata for: block 000000000d2655bd92fe
sending: block (474 bytes) 
*** glibc detected *** /home/bitcoin/bitcoin/groupcoind-PRIVNET: malloc(): memory corruption: 0x00007f5d0c56b010 ***
*** glibc detected *** /home/bitcoin/bitcoin/groupcoind-PRIVNET: malloc(): memory corruption: 0x00007f5d0c571010 ***
*** glibc detected *** /home/bitcoin/bitcoin/groupcoind-PRIVNET: malloc(): memory corruption: 0x00007f5d0c569010 ***
keypool added key 1901, size=101
keypool reserve 1801
^C

I don't know if I can run only one thread on demand other than by running it on a single-CPU machine, both of which are 32 bit Fedora 14 not the 64 bit Fedora 15 I have been running these tests on so far. I will have to move the code to the 32-bit compiling-machine and try.

If the thing is not thread safe then maybe we can just do some kind of semaphore around it, that example you linked to seemed to be using some kind of bracketing of the endangered area with some kind of signal to keep the threads from trying to all use it at the same time by the look of it.

Using C++ instead of python is probably the least-hackish way to go though of course.

-MarkM-

[Unthinkingbit]

Using C++ instead of python is probably the least-hackish way to go though of course.

Eventually, we'd have to move to C++ for speed in any case.  I'm starting to port over receiver.py, but not all pluribusunum at first.  So at the beginning it would just read from a file on disk, later it would get internet files and so on.

It will take at least a day to get something useful.  In the meantime, as I make a function, I might post it, like the function below:

Code:

// Get the entire text of a file.
std::string getFileText(const std::string& fileName)
{
	std::ifstream fileStream(fileName.c_str());
	if (!fileStream.is_open())
	{
		return std::string();
	}
	std::string fileText;
	fileStream.seekg(0, std::ios::end);
	fileText.reserve(fileStream.tellg());
	fileStream.seekg(0, std::ios::beg);
	fileText.assign((std::istreambuf_iterator<char>(fileStream)), std::istreambuf_iterator<char>());
	return fileText;
}

[Unthinkingbit]

The basic file reading address code is now at:
https://raw.github.com/Unthinkingbit/charity/master/receiver.h

Please download it into the folder which includes the CreateBlock file.  Then, add the following include at the top of the CreateBlock file:

#include "receiver.h"

then in the CreateBlock function, replace:

std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";

with:

std::string payTo = getCoinAddressString(std::string("receiver.csv"), (int)pindexPrev->nHeight+1);


If all works, the miner should send to the receivers in your receiver_0.csv file.

[markm]

That seems to be working.

-MarkM-

[smoothie]

Approximate release date?

[smoothie]

Can someone post up a brief overview/summary of where the groupcoin project is currently and approx. when it will be available for use?

Thanks

[markm]

Currently we have I think about two to four people with clients online listening on port 51333 so that other clients have someone to connect to.

We have people lurking on the #groupcoin channel in Freenode IRC.

We have tested some of the feaures DEVcoin is to have; DEVcoin will be starting from scratch once we have deeloed and tested the code for the desired features.

I have now set the four byte hello sequences for GRouPcoin that wll prevent it fro mtalking to bitcoin, testnet, namecoin etc if it happens to stumble across such a client, best come to the IRC channel for co-ordination in switching to that system all at once to minimise time of not being able to connect.

I have been testing new code privately without affecting the real GRouPcoin blockchain, which should not need any "restart" unless for some reason we are unable to develop DEVcoin (on which development seems to be proceeding okay).

See you at #groupcoin ?

-MarkM-

[cunicula]

I have a fairly complex proposal for a new currency which addresses numerous flaws in bitcoin.
Is there an alternate venue to discuss crpytocurrencies which is not forum.bitcoin.org?

The forum is generally hostile to posts that point out problems with bitcoin and propose possible solutions.
A new discussion platform would be a good first step to generating a sustained flow of innovative ideas.
The new platform doesn't need to tied to any particular project, but it should not be focused on new projects rather than bitcoin.

Is there anything like this around yet?

In the meantime, I will work on a blog to introduce my own proposal in moderate detail (not done yet).

[markm]

Most variants are simply different, they exist not because bitcoin has flaws but because bitcoin works just fine thus they hope that variants will also work. Is it really necessary to take the position that bitcoin is flaws in order to "justify" a variant?

-MarkM-

[cunicula]

Most variants are simply different, they exist not because bitcoin has flaws but because bitcoin works just fine thus they hope that variants will also work. Is it really necessary to take the position that bitcoin is flaws in order to "justify" a variant?

-MarkM-

Yes, in my opinion. But we don't have to agree on that.

[patvarilly]

I have a fairly complex proposal for a new currency which addresses numerous flaws in bitcoin.
Is there an alternate venue to discuss crpytocurrencies which is not forum.bitcoin.org?

The forum is generally hostile to posts that point out problems with bitcoin and propose possible solutions.
A new discussion platform would be a good first step to generating a sustained flow of innovative ideas.
The new platform doesn't need to tied to any particular project, but it should not be focused on new projects rather than bitcoin.

Is there anything like this around yet?

In the meantime, I will work on a blog to introduce my own proposal in moderate detail (not done yet).

This sounds like a workable site to host such a thing: http://www.freeforums.org/.

[caston]

So can someone please write a quick guide on how to start mining on the groupcoin existing network or its testnet?

I have tried to work this out by going back and reading posts but I am a bit confused. I am using a Linux coin harddrive install and have compiled multicoin.

[Unthinkingbit]

Devcoin is ready for preliminary testing.  Which means devcoin has not had problems for several days, but if new problems develop it may still be necessary to reload the client and/or daemon and/or restart the blockchain.

Devcoin is an ethical currency where 90% of the generation goes to open source developers and 10% to the miners:
https://github.com/Unthinkingbit/charity/wiki/Devcoin-Description

Groupcoin was just a stepping stone to devcoin and a fallback in case devcoin didn't work.  Now that devcoin does work, groupcoin is no longer needed.

There were no posts about devcoin while it was being developed because if you post that there is a new blockchain, even if you repeatedly say that the alternate currency is only a prototype and it is likely you will have to restart the blockchain, some will mine the new blockchain anyways and complain if and when you must restart it.  At this point, devcoin has been running without problem for several days.  If there is a new problem, it may still have to restarted and/or people will have to reload a new version, however the chances of that are lower than they were last week when devcoin was a prototype.

The client is called devcoin-qt and the daemon is called devcoin.  They are at:
http://sourceforge.net/projects/galacticmilieu/files/

Pick the latest release of the program you want, then download it and unpack it.  Then follow the instructions in the INSTALL file, and post the results.

Of the 90% of the generation that goes to open source developers, part of that will go to bounties.  Here are the bounties for testing devcoin.

The first five people who download the devcoin-qt client and/or devcoin daemon and make a minimal post about getting it working will get one hundred thousand devcoins.  A minimal report looks like this:

"I got the devcoin <client and/or daemon> working on <my operating system>."

For example:

"I got the devcoin-qt client working on my Linux / Ubuntu system."

Beyond that, the first five people who download devcoin and make an informative post about getting it working will get an additional one hundred thousand devcoins.  There is no objective definition of an informative post, because some people will game a word count or other objective definition.  So I will reward the informative post bounties at my absolute discretion.  Below is an example of a post that would qualify for the award.

"I installed the QT libraries on my Ubuntu system.  Then I downloaded the latest devcoin-qt client release from:
http://sourceforge.net/projects/galacticmilieu/files/

then I unpacked the tar file, clicked on devcoin-qt.pro which brought up the Qt Creator program, then I clicked on the run triangle and after about ten minutes the program finished compiling and ran.  However, the client didn't connect to any peers, so I closed the client and ran it again two hours later, this time it did connect and the blockchain up to block 4,372 was downloaded."

The number of devcoins offered is large because the generation is fifty thousand per block, one thousand times the initial bitcoin generation rate.  The value of a devcoin will eventually be set by the market.  A devcoin market does not exist at the time of this post and because devcoin is a preliminary blockchain which may be restarted, devcoin is not ready for a market at the time of this post.  The value will vary and there is no way to predict with certainty what the value will be in the future.

The closest type of coin to devcoin is namecoin.  The value of namecoin when the namecoin market started was in the neighbourhood of 0.005 BTC, according to:
http://www.nmcwatch.com/index.php?c=bpx&tf=1d

Since devcoin generation is one thousand times greater than bitcoin or namecoin generation, the equivalent neighbourhood would be 0.000005 DVC/BTC, giving a reciprocal of 200,000 DVC/BTC.  This does no mean you can rely or even estimate that devcoin will have that value, this is just a reminder of how namecoin started.

[caston]

Thank you.

I am trying to compile devcoin and I get

Code:

make -f makefile.unix
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -DNOPCH -DFOURWAYSSE2 -DUSE_SSL -DUSE_UPNP=0 -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -DGUI -o obj/util.o util.cpp
In file included from headers.h:93:0,
                 from util.cpp:4:
util.h: In function 'void ExitThread(unsigned int)':
util.h:653:25: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
In file included from headers.h:99:0,
                 from util.cpp:4:
ui.h: At global scope:
ui.h:30:142: error: default argument for 'const wxString& caption' has type 'const char [8]'
ui.h: In function 'int MyMessageBox(const wxString&, const wxString&, int, wxWindow*, int, int)':
ui.h:36:56: error: no matching function for call to 'std::basic_string<char>::basic_string(const wxString&)'
ui.h:36:56: note: candidates are:
/usr/include/c++/4.6/bits/basic_string.h:528:36: note: template<class _InputIterator> std::basic_string::basic_string(_InputIterator, _InputIterator, const _Alloc&)
/usr/include/c++/4.6/bits/basic_string.tcc:221:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:221:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:214:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:214:5: note:   no known conversion for argument 1 from 'const wxString' to 'const char*'
/usr/include/c++/4.6/bits/basic_string.tcc:207:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:207:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:195:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:195:5: note:   candidate expects 4 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:185:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:185:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:171:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:171:5: note:   no known conversion for argument 1 from 'const wxString' to 'const std::basic_string<char>& {aka const std::basic_string<char>&}'
/usr/include/c++/4.6/bits/basic_string.tcc:179:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:179:5: note:   no known conversion for argument 1 from 'const wxString' to 'const std::allocator<char>&'
/usr/include/c++/4.6/bits/basic_string.h:432:7: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.h:432:7: note:   candidate expects 0 arguments, 1 provided
ui.h:36:86: error: no matching function for call to 'std::basic_string<char>::basic_string(const wxString&)'
ui.h:36:86: note: candidates are:
/usr/include/c++/4.6/bits/basic_string.h:528:36: note: template<class _InputIterator> std::basic_string::basic_string(_InputIterator, _InputIterator, const _Alloc&)
/usr/include/c++/4.6/bits/basic_string.tcc:221:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:221:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:214:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:214:5: note:   no known conversion for argument 1 from 'const wxString' to 'const char*'
/usr/include/c++/4.6/bits/basic_string.tcc:207:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:207:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:195:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:195:5: note:   candidate expects 4 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:185:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:185:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:171:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:171:5: note:   no known conversion for argument 1 from 'const wxString' to 'const std::basic_string<char>& {aka const std::basic_string<char>&}'
/usr/include/c++/4.6/bits/basic_string.tcc:179:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:179:5: note:   no known conversion for argument 1 from 'const wxString' to 'const std::allocator<char>&'
/usr/include/c++/4.6/bits/basic_string.h:432:7: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.h:432:7: note:   candidate expects 0 arguments, 1 provided
ui.h:37:52: error: no matching function for call to 'std::basic_string<char>::basic_string(const wxString&)'
ui.h:37:52: note: candidates are:
/usr/include/c++/4.6/bits/basic_string.h:528:36: note: template<class _InputIterator> std::basic_string::basic_string(_InputIterator, _InputIterator, const _Alloc&)
/usr/include/c++/4.6/bits/basic_string.tcc:221:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:221:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:214:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:214:5: note:   no known conversion for argument 1 from 'const wxString' to 'const char*'
/usr/include/c++/4.6/bits/basic_string.tcc:207:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:207:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:195:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:195:5: note:   candidate expects 4 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:185:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:185:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:171:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:171:5: note:   no known conversion for argument 1 from 'const wxString' to 'const std::basic_string<char>& {aka const std::basic_string<char>&}'
/usr/include/c++/4.6/bits/basic_string.tcc:179:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:179:5: note:   no known conversion for argument 1 from 'const wxString' to 'const std::allocator<char>&'
/usr/include/c++/4.6/bits/basic_string.h:432:7: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.h:432:7: note:   candidate expects 0 arguments, 1 provided
ui.h:37:82: error: no matching function for call to 'std::basic_string<char>::basic_string(const wxString&)'
ui.h:37:82: note: candidates are:
/usr/include/c++/4.6/bits/basic_string.h:528:36: note: template<class _InputIterator> std::basic_string::basic_string(_InputIterator, _InputIterator, const _Alloc&)
/usr/include/c++/4.6/bits/basic_string.tcc:221:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:221:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:214:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:214:5: note:   no known conversion for argument 1 from 'const wxString' to 'const char*'
/usr/include/c++/4.6/bits/basic_string.tcc:207:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:207:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:195:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:195:5: note:   candidate expects 4 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:185:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:185:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:171:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:171:5: note:   no known conversion for argument 1 from 'const wxString' to 'const std::basic_string<char>& {aka const std::basic_string<char>&}'
/usr/include/c++/4.6/bits/basic_string.tcc:179:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:179:5: note:   no known conversion for argument 1 from 'const wxString' to 'const std::allocator<char>&'
/usr/include/c++/4.6/bits/basic_string.h:432:7: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.h:432:7: note:   candidate expects 0 arguments, 1 provided
ui.h: At global scope:
ui.h:180:62: error: default argument for parameter of type 'const wxString&' has type 'const char [1]'
ui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const string&, const string&, const string&, const string&, const string&)':
ui.h:293:118: error: no matching function for call to 'CGetTextFromUserDialogBase::CGetTextFromUserDialogBase(wxWindow*&, <anonymous enum>, const string&)'
ui.h:293:118: note: candidates are:
uibase.h:416:3: note: CGetTextFromUserDialogBase::CGetTextFromUserDialogBase(wxWindow*, wxWindowID, const wxString&, const wxPoint&, const wxSize&, long int)
uibase.h:416:3: note:   no known conversion for argument 3 from 'const string {aka const std::basic_string<char>}' to 'const wxString&'
uibase.h:392:7: note: CGetTextFromUserDialogBase::CGetTextFromUserDialogBase(const CGetTextFromUserDialogBase&)
uibase.h:392:7: note:   candidate expects 1 argument, 3 provided
ui.h:297:51: error: no matching function for call to 'wxStaticText::SetLabel(const string&)'
ui.h:297:51: note: candidate is:
/usr/include/wx-2.8/wx/gtk/stattext.h:38:10: note: virtual void wxStaticText::SetLabel(const wxString&)
/usr/include/wx-2.8/wx/gtk/stattext.h:38:10: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'const wxString&'
ui.h:298:40: error: no matching function for call to 'wxTextCtrl::SetValue(const string&)'
ui.h:298:40: note: candidate is:
/usr/include/wx-2.8/wx/textctrl.h:303:18: note: virtual void wxTextCtrlBase::SetValue(const wxString&)
/usr/include/wx-2.8/wx/textctrl.h:303:18: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'const wxString&'
ui.h:299:34: error: no matching function for call to 'wxString::wxString(const string&)'
ui.h:299:34: note: candidates are:
/usr/include/wx-2.8/wx/string.h:1283:3: note: wxString::wxString(const void*, const void*)
/usr/include/wx-2.8/wx/string.h:1283:3: note:   candidate expects 2 arguments, 1 provided
/usr/include/wx-2.8/wx/string.h:1280:3: note: wxString::wxString(const wxString&, size_t, size_t)
/usr/include/wx-2.8/wx/string.h:1280:3: note:   candidate expects 3 arguments, 1 provided
/usr/include/wx-2.8/wx/string.h:722:3: note: wxString::wxString(const wxWCharBuffer&)
/usr/include/wx-2.8/wx/string.h:722:3: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'const wxWCharBuffer&'
/usr/include/wx-2.8/wx/string.h:720:3: note: wxString::wxString(const char*, const wxMBConv&, size_t)
/usr/include/wx-2.8/wx/string.h:720:3: note:   candidate expects 3 arguments, 1 provided
/usr/include/wx-2.8/wx/string.h:714:3: note: wxString::wxString(const wxStdString&)
/usr/include/wx-2.8/wx/string.h:714:3: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'const wxStdString& {aka const std::basic_string<wchar_t>&}'
/usr/include/wx-2.8/wx/string.h:702:3: note: wxString::wxString(const wxChar*, const wxMBConv&, size_t)
/usr/include/wx-2.8/wx/string.h:702:3: note:   candidate expects 3 arguments, 1 provided
/usr/include/wx-2.8/wx/string.h:700:3: note: wxString::wxString(const wxChar*, size_t)
/usr/include/wx-2.8/wx/string.h:700:3: note:   candidate expects 2 arguments, 1 provided
/usr/include/wx-2.8/wx/string.h:698:3: note: wxString::wxString(const wxChar*)
/usr/include/wx-2.8/wx/string.h:698:3: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'const wxChar* {aka const wchar_t*}'
/usr/include/wx-2.8/wx/string.h:694:3: note: wxString::wxString(size_t, wxChar)
/usr/include/wx-2.8/wx/string.h:694:3: note:   candidate expects 2 arguments, 1 provided
/usr/include/wx-2.8/wx/string.h:692:3: note: wxString::wxString(wxChar, size_t)
/usr/include/wx-2.8/wx/string.h:692:3: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'wxChar {aka wchar_t}'
/usr/include/wx-2.8/wx/string.h:690:3: note: wxString::wxString(const wxString&)
/usr/include/wx-2.8/wx/string.h:690:3: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'const wxString& {aka const wxString&}'
/usr/include/wx-2.8/wx/string.h:689:3: note: wxString::wxString(const wxStringBase&)
/usr/include/wx-2.8/wx/string.h:689:3: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'const wxStringBase& {aka const wxStringBase&}'
/usr/include/wx-2.8/wx/string.h:687:3: note: wxString::wxString()
/usr/include/wx-2.8/wx/string.h:687:3: note:   candidate expects 0 arguments, 1 provided
/usr/include/wx-2.8/wx/string.h:682:3: note: wxString::wxString(int)
/usr/include/wx-2.8/wx/string.h:682:3: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'int'
ui.h:303:55: error: no matching function for call to 'wxStaticText::SetLabel(const string&)'
ui.h:303:55: note: candidate is:
/usr/include/wx-2.8/wx/gtk/stattext.h:38:10: note: virtual void wxStaticText::SetLabel(const wxString&)
/usr/include/wx-2.8/wx/gtk/stattext.h:38:10: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'const wxString&'
ui.h:305:44: error: no matching function for call to 'wxTextCtrl::SetValue(const string&)'
ui.h:305:44: note: candidate is:
/usr/include/wx-2.8/wx/textctrl.h:303:18: note: virtual void wxTextCtrlBase::SetValue(const wxString&)
/usr/include/wx-2.8/wx/textctrl.h:303:18: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'const wxString&'
ui.h:306:43: error: no matching function for call to 'wxString::wxString(const string&)'
ui.h:306:43: note: candidates are:
/usr/include/wx-2.8/wx/string.h:1283:3: note: wxString::wxString(const void*, const void*)
/usr/include/wx-2.8/wx/string.h:1283:3: note:   candidate expects 2 arguments, 1 provided
/usr/include/wx-2.8/wx/string.h:1280:3: note: wxString::wxString(const wxString&, size_t, size_t)
/usr/include/wx-2.8/wx/string.h:1280:3: note:   candidate expects 3 arguments, 1 provided
/usr/include/wx-2.8/wx/string.h:722:3: note: wxString::wxString(const wxWCharBuffer&)
/usr/include/wx-2.8/wx/string.h:722:3: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'const wxWCharBuffer&'
/usr/include/wx-2.8/wx/string.h:720:3: note: wxString::wxString(const char*, const wxMBConv&, size_t)
/usr/include/wx-2.8/wx/string.h:720:3: note:   candidate expects 3 arguments, 1 provided
/usr/include/wx-2.8/wx/string.h:714:3: note: wxString::wxString(const wxStdString&)
/usr/include/wx-2.8/wx/string.h:714:3: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'const wxStdString& {aka const std::basic_string<wchar_t>&}'
/usr/include/wx-2.8/wx/string.h:702:3: note: wxString::wxString(const wxChar*, const wxMBConv&, size_t)
/usr/include/wx-2.8/wx/string.h:702:3: note:   candidate expects 3 arguments, 1 provided
/usr/include/wx-2.8/wx/string.h:700:3: note: wxString::wxString(const wxChar*, size_t)
/usr/include/wx-2.8/wx/string.h:700:3: note:   candidate expects 2 arguments, 1 provided
/usr/include/wx-2.8/wx/string.h:698:3: note: wxString::wxString(const wxChar*)
/usr/include/wx-2.8/wx/string.h:698:3: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'const wxChar* {aka const wchar_t*}'
/usr/include/wx-2.8/wx/string.h:694:3: note: wxString::wxString(size_t, wxChar)
/usr/include/wx-2.8/wx/string.h:694:3: note:   candidate expects 2 arguments, 1 provided
/usr/include/wx-2.8/wx/string.h:692:3: note: wxString::wxString(wxChar, size_t)
/usr/include/wx-2.8/wx/string.h:692:3: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'wxChar {aka wchar_t}'
/usr/include/wx-2.8/wx/string.h:690:3: note: wxString::wxString(const wxString&)
/usr/include/wx-2.8/wx/string.h:690:3: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'const wxString& {aka const wxString&}'
/usr/include/wx-2.8/wx/string.h:689:3: note: wxString::wxString(const wxStringBase&)
/usr/include/wx-2.8/wx/string.h:689:3: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'const wxStringBase& {aka const wxStringBase&}'
/usr/include/wx-2.8/wx/string.h:687:3: note: wxString::wxString()
/usr/include/wx-2.8/wx/string.h:687:3: note:   candidate expects 0 arguments, 1 provided
/usr/include/wx-2.8/wx/string.h:682:3: note: wxString::wxString(int)
/usr/include/wx-2.8/wx/string.h:682:3: note:   no known conversion for argument 1 from 'const string {aka const std::basic_string<char>}' to 'int'
ui.h: In member function 'std::string CGetTextFromUserDialog::GetValue()':
ui.h:316:73: error: no matching function for call to 'std::basic_string<char>::basic_string(wxString)'
ui.h:316:73: note: candidates are:
/usr/include/c++/4.6/bits/basic_string.h:528:36: note: template<class _InputIterator> std::basic_string::basic_string(_InputIterator, _InputIterator, const _Alloc&)
/usr/include/c++/4.6/bits/basic_string.tcc:221:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:221:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:214:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:214:5: note:   no known conversion for argument 1 from 'wxString' to 'const char*'
/usr/include/c++/4.6/bits/basic_string.tcc:207:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:207:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:195:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:195:5: note:   candidate expects 4 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:185:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:185:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:171:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:171:5: note:   no known conversion for argument 1 from 'wxString' to 'const std::basic_string<char>& {aka const std::basic_string<char>&}'
/usr/include/c++/4.6/bits/basic_string.tcc:179:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:179:5: note:   no known conversion for argument 1 from 'wxString' to 'const std::allocator<char>&'
/usr/include/c++/4.6/bits/basic_string.h:432:7: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.h:432:7: note:   candidate expects 0 arguments, 1 provided
ui.h: In member function 'std::string CGetTextFromUserDialog::GetValue1()':
ui.h:317:73: error: no matching function for call to 'std::basic_string<char>::basic_string(wxString)'
ui.h:317:73: note: candidates are:
/usr/include/c++/4.6/bits/basic_string.h:528:36: note: template<class _InputIterator> std::basic_string::basic_string(_InputIterator, _InputIterator, const _Alloc&)
/usr/include/c++/4.6/bits/basic_string.tcc:221:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:221:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:214:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:214:5: note:   no known conversion for argument 1 from 'wxString' to 'const char*'
/usr/include/c++/4.6/bits/basic_string.tcc:207:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:207:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:195:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:195:5: note:   candidate expects 4 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:185:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:185:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:171:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:171:5: note:   no known conversion for argument 1 from 'wxString' to 'const std::basic_string<char>& {aka const std::basic_string<char>&}'
/usr/include/c++/4.6/bits/basic_string.tcc:179:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:179:5: note:   no known conversion for argument 1 from 'wxString' to 'const std::allocator<char>&'
/usr/include/c++/4.6/bits/basic_string.h:432:7: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.h:432:7: note:   candidate expects 0 arguments, 1 provided
ui.h: In member function 'std::string CGetTextFromUserDialog::GetValue2()':
ui.h:318:73: error: no matching function for call to 'std::basic_string<char>::basic_string(wxString)'
ui.h:318:73: note: candidates are:
/usr/include/c++/4.6/bits/basic_string.h:528:36: note: template<class _InputIterator> std::basic_string::basic_string(_InputIterator, _InputIterator, const _Alloc&)
/usr/include/c++/4.6/bits/basic_string.tcc:221:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:221:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:214:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:214:5: note:   no known conversion for argument 1 from 'wxString' to 'const char*'
/usr/include/c++/4.6/bits/basic_string.tcc:207:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:207:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:195:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:195:5: note:   candidate expects 4 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:185:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]
/usr/include/c++/4.6/bits/basic_string.tcc:185:5: note:   candidate expects 3 arguments, 1 provided
/usr/include/c++/4.6/bits/basic_string.tcc:171:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:171:5: note:   no known conversion for argument 1 from 'wxString' to 'const std::basic_string<char>& {aka const std::basic_string<char>&}'
/usr/include/c++/4.6/bits/basic_string.tcc:179:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.tcc:179:5: note:   no known conversion for argument 1 from 'wxString' to 'const std::allocator<char>&'
/usr/include/c++/4.6/bits/basic_string.h:432:7: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.6/bits/basic_string.h:432:7: note:   candidate expects 0 arguments, 1 provided
util.cpp: In function 'void PrintException(std::exception*, const char*)':
util.cpp:579:64: error: conversion from 'char [10000]' to 'const wxString' is ambiguous
util.cpp:572:10: note: candidates are:
/usr/include/wx-2.8/wx/string.h:692:3: note: wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.8/wx/string.h:692:3: note:   no known conversion for argument 1 from 'char [10000]' to 'wxChar {aka wchar_t}'
/usr/include/wx-2.8/wx/string.h:682:3: note: wxString::wxString(int) <near match>
/usr/include/wx-2.8/wx/string.h:682:3: note:   no known conversion for argument 1 from 'char [10000]' to 'int'
ui.h:30:12: error:   initializing argument 1 of 'int MyMessageBox(const wxString&, const wxString&, int, wxWindow*, int, int)'
util.cpp: In function 'void AddTimeData(unsigned int, int64)':
util.cpp:867:41: error: conversion from 'const wxChar* {aka const wchar_t*}' to non-scalar type 'std::string {aka std::basic_string<char>}' requested
util.cpp: In function 'std::string FormatFullVersion()':
util.cpp:901:14: error: invalid conversion from 'const wxChar* {aka const wchar_t*}' to 'char' [-fpermissive]
/usr/include/c++/4.6/bits/basic_string.h:942:7: error:   initializing argument 1 of 'std::basic_string<_CharT, _Traits, _Alloc>& std::basic_string<_CharT, _Traits, _Alloc>::operator+=(_CharT) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>]' [-fpermissive]
make: *** [obj/util.o] Error 1

I'm just compiling version 2.9 of wxwidgets and after that will try again.

OK that's done but it looks like I have berkley db 4.8


dpkg -l | grep libdb
ii  libdb++-dev                        5.1.4                                    Berkeley Database Libraries for C++ [development]
ii  libdb4.8                           4.8.30-9                                 Berkeley v4.8 Database Libraries [runtime]
ii  libdb5.1                           5.1.25-11                                Berkeley v5.1 Database Libraries [runtime]
ii  libdb5.1++                         5.1.25-11                                Berkeley v5.1 Database Libraries for C++ [runtime]
ii  libdb5.1++-dev                     5.1.25-11                                Berkeley v5.1 Database Libraries for C++ [development]
ii  libdb5.1-dev                       5.1.25-11                                Berkeley v5.1 Database Libraries [development]
ii  libdbd-mysql-perl                  4.019-1                                  Perl5 database interface to the MySQL database
ii  libdbi-perl                        1.616-1+b1                               Perl Database Interface (DBI)
ii  libdbus-1-3                        1.4.12-2                                 simple interprocess messaging system (library)
ii  libdbus-glib-1-2                   0.94-2                                   simple interprocess messaging system (GLib-based shared library)

[markm]

The makefile defaults to making the wxwidgets GUI version.

To make the daemon try make -f makefile.unix bitcoind

Or to not use upnp, try make -f makefile.unix USE_UPNP= bitcoind

Or to not only include upnp but default it to being active, try

make -f makefile.unix USE_UPNP=1 bitcoind

-MarkM-

[caston]

The makefile defaults to making the wxwidgets GUI version.

To make the daemon try make -f makefile.unix bitcoind

Or to not use upnp, try make -f makefile.unix USE_UPNP= bitcoind

Or to not only include upnp but default it to being active, try

make -f makefile.unix USE_UPNP=1 bitcoind

-MarkM-

Thank you. I thought I had downloaded the headless version but I am trying that make option now.

OK I have it compiled now and I am getting:


./bitcoind getinfo
{
    "version" : 32400,
    "balance" : 0.00000000,
    "blocks" : 0,
    "connections" : 0,
    "proxy" : "",
    "generate" : false,
    "genproclimit" : -1,
    "difficulty" : 1.00000000,
    "hashespersec" : 0,
    "testnet" : false,
    "keypoololdest" : 1312339093,
    "paytxfee" : 0.00000000,
    "errors" : ""
}


I assume the port I should open is 52333 ?

I have opened that port as tcp but still no connections.

How can I get my first connection?

I finally have a connection now:



./bitcoind getinfo
{
    "version" : 32400,
    "balance" : 0.00000000,
    "blocks" : 4912,
    "connections" : 1,
    "proxy" : "",
    "generate" : false,
    "genproclimit" : -1,
    "difficulty" : 16.00000000,
    "hashespersec" : 0,
    "testnet" : false,
    "keypoololdest" : 1312339093,
    "paytxfee" : 0.00000000,
    "errors" : ""
}
user@linuxcoin:~/Downloads/devcoin/src$ ./bitcoind getnewaddress
19piwg8kyW5unDpLjYjbvE6GGvtAfghT8c

[Unthinkingbit]

user@linuxcoin:~/Downloads/devcoin/src$ ./bitcoind getnewaddress
19piwg8kyW5unDpLjYjbvE6GGvtAfghT8c

Good news, thanks for not giving up

I'm hoping and assuming you'll write a post tying together all that you went through.  When you do I'll send two hundred thousand devcoins to what I am assuming is the devcoin address you posted.  What you've written so far is good but since it's distributed over a few posts it doesn't qualify for the informative post bounty.

If you don't want to write anything else, then just state that and I'll send one hundred thousand.

[caston]

thank you I am now mining at 227 mhash.

I'll try to recap what I did:

I'm using Linux coin 0.2b that I have installed to my HD.

I previously installed multicoin and then group coin with help from knotworking on the irc channel #groupcoin

I went to http://sourceforge.net/projects/galacticmilieu/files/ in the Cromium web browser.
and downloaded devcoin-02-Aug-2011.tgz

I then open up a terminal and typed cd Downloads
I then typed gunzip devcoin-02-Aug-2011.tgz
after that I typed: tar -xf devcoin-02-Aug-2011.tar (using tab completion of course)

I then typed cd devcoin then cd doc
I then read the build build-unix.txt file and installed all the dependencies.

Some of these I could find using apt-cache search and some I had to find and download using google and then compile.

I then changed to /Downloads/devcoin/src and ran:
make -f makefile.unix bitcoind
to build it headless

You can cat the INSTALL for more information. You should also follow the other instructions "The files that must be in the current directory at runtime
are https.py and the receiver_*.csv files."

After that finished I changed to cd /home/user/.devcoin/ and created a devcoin.conf file with a username and password for rpc in the same format as a bitcoin.conf file

If you don't find this folder it will probably be created the first time you run the devcoin bitcoind daemon.

I then logged to the web interface for my router and set a virtual server and a IP address reservation for my mining rig to forward tcp port 52333 to it.

after that I started the client in /home/user/Downloads/devcoin/src/ using ./bitcoind
from a different terminal I checked the status in the same directory as above using ./bitcoind getinfo

It took a while to get my first connection but opening the #groupcoin channel seemed to help me get my first connection
I used sudo netstat -p | grep bitcoind to see if bitcoind was connected to irc server and if it was using the outgoing ports to make connections. I finally got my first connection and started mining using the username and password I specified in my devcoin.conf file.

./bitcoind getinfo (now says)
{
    "version" : 32400,
    "balance" : 200000.00000000,
    "blocks" : 4921,
    "connections" : 2,
    "proxy" : "",
    "generate" : false,
    "genproclimit" : -1,
    "difficulty" : 16.00000000,
    "hashespersec" : 0,
    "testnet" : false,
    "keypoololdest" : 1312339094,
    "paytxfee" : 0.00000000,
    "errors" : ""
}

I went to the toilet and when I came back I saw I had already mined 6 blocks!

Please let me know if you have anymore questions. I'm about to go to work but will leave devcoin mining while I am at work.

[markm]

Heh so it works without reading the INSTALL file and, as it instructs, putting the receiver_*.csv files into the directory that is the "current directory" (Present Working Directory) you are in when running devcoind? Cool.

-MarkM-

[caston]

Heh so it works without reading the INSTALL file and, as it instructs, putting the receiver_*.csv files into the directory that is the "current directory" (Present Working Directory) you are in when running devcoind? Cool.

-MarkM-

I seem to remember it downloading the .csv file soon after it connected to irc or got its first connection. Do you think I missed anything else? I am running it from it's directory and haven't yet made a /usr/sbin symbolic link or something like that.

Code:

ls
base58.h   irc.h		 makefile.mingw  rpc.cpp      ui.h
bignum.h   json			 makefile.osx	 rpc.h	      uint256.h
bitcoind   key.h		 makefile.unix	 script.cpp   util.cpp
cryptopp   keystore.cpp		 makefile.vc	 script.h     util.h
db.cpp	   keystore.h		 net.cpp	 serialize.h  wallet.cpp
db.h	   main.cpp		 net.h		 strlcpy.h    wallet.h
headers.h  main.h		 noui.h		 test	      xpm
init.cpp   makefile.fedora14	 obj		 uibase.cpp
init.h	   makefile.fedora15	 receiver_0.csv  uibase.h
irc.cpp    makefile.linux-mingw  receiver.h	 ui.cpp

[Unthinkingbit]

thank you I am now mining at 227 mhash.

I'll try to recap what I did:
..

Thanks for the great post, two hundred thousand devcoins are on their way.

..

I'm about to go to work but will leave devcoin mining while I am at work.

Thanks for leaving it on, the more nodes we have the better.

By the way, your work on Rejuvepedia qualifies you to be an active developer in the writer category.  Furthermore, from the beta devcoin bounty article:
https://github.com/Unthinkingbit/charity/wiki/Devcoin-Bounty

since you're one of the first five writers, you also get the one million devcoin inductee bounty.

It will be more complicated because you have a collaborative wiki and so your active developer share will have to be shared in turn with your collaborators.  It will take time to work that out so we can talk about it when you return from work.

[caston]

You've just made me very happy. Thank you!

[Unthinkingbit]

You've just made me very happy. Thank you!

You're welcome.  Devcoin is made to make developers happy 

[Unthinkingbit]

Hi Caston,

I sent you the million devcoins for your induction bounty.  You are now a devcoin receiving active developer.  In the next round of generation, which starts at block 8,000, you will begin receiving your share of the 90% of the generation that goes to developers.  You can see your devcoin address:
19piwg8kyW5unDpLjYjbvE6GGvtAfghT8c

at index 20 in the receiver_2.csv file at:
http://pastebin.com/raw.php?i=u51edxd0

Now that you are inducted, you can become an administrator, as described in:
https://github.com/Unthinkingbit/charity/wiki/Devcoin-Description

Please accept the invitation.  If you accept, devcoin would have three administrators so we could test the democratic download of the receiver file.  If that test succeeds, devcoin would be ready for the next set of bounties.

Below is your contributor file.  Please check it and update it if necessary.

Contributor: <a href='https://bitcointalk.org/index.php?action=profile;u=4480'>Caston</a>
Devcoin Address: 19piwg8kyW5unDpLjYjbvE6GGvtAfghT8c
Description: Founder of Rejuvepedia, the Wiki that aims to do for health what bitcoin does for wealth.
Project Homepage: <a href='http://www.rejuvepedia.org/index.php?title=Main_Page'>Rejuvepedia</a>
Project License: Creative Commons Attribution ShareAlike 3.0 Unported
Project Type: Wiki


The recommeded method to handle funds for collaborations is pasted below and described in:
https://github.com/Unthinkingbit/charity/wiki/Devcoin-Description

"Collaborative Developer

People who develop a collaborative project, like a wiki, get shares for their work according to how much they work.  An active developer who creates ten hours a week of good accomplishments gets a share.  A part time developer who contributes every month, but does not create ten hours a week of accomplishments gets half a share.  A contributor who occasionally writes articles gets 0.2 shares in the funding round that the article is submitted.  A contributor who occasionally edits the wiki gets 0.1 shares in the funding round of the edits.

The shares are added up and rounded, totals ending in .5 are rounded to the nearest even number. The result is the number of collaborative editors who get on the active developer list, and therefore get a direct share of the generation. They in turn send the collaborators who are not on the developer list their share of the devcoins at least every funding round (every 4,000 blocks, roughly once a month). If they do not give the collaborators their share they will be removed from the active developer list."

[caston]

Hi Caston,

I sent you the million devcoins for your induction bounty.  You are now a devcoin receiving active developer.  In the next round of generation, which starts at block 8,000, you will begin receiving your share of the 90% of the generation that goes to developers.  You can see your devcoin address:
19piwg8kyW5unDpLjYjbvE6GGvtAfghT8c

I just got home from work. I am tired but I will reply the best I can.

Thank you! You have made this one of the happiest days of my life and me a millionaire too

user@linuxcoin:~/Downloads/devcoin/src$ ./bitcoind getinfo
{
    "version" : 32400,
    "balance" : 1635000.00000000,
    "blocks" : 5202,
    "connections" : 3,
    "proxy" : "",
    "generate" : false,
    "genproclimit" : -1,
    "difficulty" : 16.00000000,
    "hashespersec" : 0,
    "testnet" : false,
    "keypoololdest" : 1312359717,
    "paytxfee" : 0.00000000,
    "errors" : ""
}

at index 20 in the receiver_2.csv file at:
http://pastebin.com/raw.php?i=u51edxd0

Now that you are inducted, you can become an administrator, as described in:
https://github.com/Unthinkingbit/charity/wiki/Devcoin-Description



Please accept the invitation.  If you accept, devcoin would have three administrators so we could test the democratic download of the receiver file.  If that test succeeds, devcoin would be ready for the next set of bounties.

My first answer yes, yes hell yes but I really should wait until I read this when I wake up tomorrow and am fresh.

Below is your contributor file.  Please check it and update it if necessary.

Contributor: <a href='https://bitcointalk.org/index.php?action=profile;u=4480'>Caston</a>
Devcoin Address: 19piwg8kyW5unDpLjYjbvE6GGvtAfghT8c
Description: Founder of Rejuvepedia, the Wiki that aims to do for health what bitcoin does for wealth.
Project Homepage: <a href='http://www.rejuvepedia.org/index.php?title=Main_Page'>Rejuvepedia</a>
Project License: Creative Commons Attribution ShareAlike 3.0 Unported
Project Type: Wiki


The recommeded method to handle funds for collaborations is pasted below and described in:
https://github.com/Unthinkingbit/charity/wiki/Devcoin-Description

"Collaborative Developer

People who develop a collaborative project, like a wiki, get shares for their work according to how much they work.  An active developer who creates ten hours a week of good accomplishments gets a share.  A part time developer who contributes every month, but does not create ten hours a week of accomplishments gets half a share.  A contributor who occasionally writes articles gets 0.2 shares in the funding round that the article is submitted.  A contributor who occasionally edits the wiki gets 0.1 shares in the funding round of the edits.

The shares are added up and rounded, totals ending in .5 are rounded to the nearest even number. The result is the number of collaborative editors who get on the active developer list, and therefore get a direct share of the generation. They in turn send the collaborators who are not on the developer list their share of the devcoins at least every funding round (every 4,000 blocks, roughly once a month). If they do not give the collaborators their share they will be removed from the active developer list."

I really wanted to ask if Rejuvepedia could be included in Devcoin and now I am really happy to find out that it can. As you can see I have already been experimenting with paying bloggers with namecoins. I hope
to use Devcoin to take the wiki to a much higher level and look forward to having more people work with me on this project. I would also like to help out with Devcoin.

Unfortunately I need to turn off my mining rig while I sleep tonight but I will bring it back up tomorrow with twice the hashing power and probably set my main machine to hash soon too.

[Unthinkingbit]

..

Please accept the invitation.  If you accept, devcoin would have three administrators so we could test the democratic download of the receiver file.  If that test succeeds, devcoin would be ready for the next set of bounties.

My first answer yes, yes hell yes but I really should wait until I read this when I wake up tomorrow and am fresh.

Now that we have three administrators we can assemble the devcoin majority download receiver tree, which is explained in the Technical section of:
https://github.com/Unthinkingbit/charity/wiki/Devcoin-Description

Because the algorithm in receiver.h is forward looking, we have to assemble the tree backwards so that no devcoin program ever sees an inconsistency.

So please upload the receiver_3.csv file:
https://raw.github.com/Unthinkingbit/charity/master/receiver_3.csv

to, ideally, an http site which lets you call it *receiver_3.csv, rather than forcing you to call it *<some random string>

The uploaded file must be in raw form, if the upload site adds any tags or whatever, the majority download receiver.h algorithm will not work because it expects identical files.

If you can't find an http site that lets you upload a raw file, then you can use an https site like github.  Https means the additional dependency of python for devcoin, but it's not a big problem because almost everyone who would use devcoin would have python.  Once you've uploaded the file, post the link to it.

Once there are three copies of receiver_3.csv, I'll create a receiver_2.csv file to upload, then a receiver_1.csv file to upload.

Assembling the tree is awkward, but once done devcoin will be able to keep working even if one receiver website is down and in future rounds administrators will just have to upload a single file.

[caston]

Unthinking bit:

I have a nearly free speech account. I have uploaded it to that for now.

http://www.perth-exchange.org/receiver_3.csv

Also I can probably upload to a site  khal (dot-bit forum site admin) has given me but I haven't used yet.

Does that look ok?

[Unthinkingbit]

Unthinking bit:

I have a nearly free speech account. I have uploaded it to that for now.

http://www.perth-exchange.org/receiver_3.csv

Also I can probably upload to a site  khal (dot-bit forum site admin) has given me but I haven't used yet.

Does that look ok?

It sure does.

Now upload the file at:
https://raw.github.com/Unthinkingbit/charity/master/receiver_2.csv

to:
http://www.perth-exchange.org/receiver_2.csv

[caston]

done and http://www.perth-exchange.org/receiver_1.csv

I'd also like to check that this is working as its supposed to e.g. 90% going to developers as my balance seems to be getting pretty high.

At the moment its 2175000.00000000

[Unthinkingbit]

done

and http://www.perth-exchange.org/receiver_1.csv

Actually, now that all the receiver_2.csv files have been updated, receiver_1.csv has been updated so please upload the latest version from:
https://raw.github.com/Unthinkingbit/charity/master/receiver_1.csv

[caston]

Hi Unthinkingbit,

Devcoin needs a community forum and knowledge portal. As a suggestion we could use simple machines with a mediawiki bridge.

[jackjack]

Hi everybody
I find this project quite interesting!

Moreover, all went fine:
I downloaded devcoin-qt-*, installed dependencies, compiled with qmake and make, and the qt client was ok and started downloading blocks immediately
I just downloaded devcoin-* too for bitcoind, I compiled it and it works ok
My miners can't connect to bitcoind though

I have two questions:
Is there a block explorer?
What help is needed?

[caston]

Hi everybody
I find this project quite interesting!

Moreover, all went fine:
I downloaded devcoin-qt-*, installed dependencies, compiled with qmake and make, and the qt client was ok and started downloading blocks immediately
I just downloaded devcoin-* too for bitcoind, I compiled it and it works ok
My miners can't connect to bitcoind though

You might not have any connections yet. I could give you my IP but I am going to bed soon and have to shutdown my mining rig.

I have two questions:
Is there a block explorer?

Not that I know of as yet but Abe could easily handle it.

http://abe.john-edwin-tobey.org/

https://github.com/jtobey/bitcoin-abe

What help is needed?

We need more people to mine for one.

[jackjack]

I checked that, I have 1 connections, it was even 2 when I posted my first message

I'll take a look at Abe, and I'll mine a bit if I can

[caston]

I checked that, I have 1 connections, it was even 2 when I posted my first message

I'll take a look at Abe, and I'll mine a bit if I can

It is definitely worth while mining.

What error message are you getting when you try to mine?

[jackjack]

Nothing for about 1 minute, then "failed to connect", with Phoenix
I even see the connection in netstat

[markm]

devcoin-qt has mining disabled deliberately because the file-getting code to get the receiver files, or maybe the file-reading code to read them, doesn't seem to play well with qt's threads. devcoind though only uses boost's threads, which seem to work okay so mining should work with devcoind.

You do have to catch up with the initial blocks though I think before mining will actually start.

-MarkM-

[Unthinkingbit]

Hi Unthinkingbit,

Devcoin needs a community forum and knowledge portal. As a suggestion we could use simple machines with a mediawiki bridge.

Good idea to have a forum and portal, vague bounties to that end are mentioned in:
https://github.com/Unthinkingbit/charity/wiki/Devcoin-Bounty

The forum bounties start two rounds of bounties from now.  As we get closer to those bounties they'll be more discussion about what kind of wiki, upload site, forums and portals would be useful for all open source developers.


By the way, thanks for updating receiver_1.csv, that was the last update for your site.

[jackjack]

I finally got Abe working
Currently it is hosted by a friend of mine: http://devcoinblockexplorer.tk/
I know, it's slow as hell

Still can't mine btw

[caston]

Hi Unthinkingbit,

Devcoin needs a community forum and knowledge portal. As a suggestion we could use simple machines with a mediawiki bridge.

Good idea to have a forum and portal, vague bounties to that end are mentioned in:
https://github.com/Unthinkingbit/charity/wiki/Devcoin-Bounty

The forum bounties start two rounds of bounties from now.  As we get closer to those bounties they'll be more discussion about what kind of wiki, upload site, forums and portals would be useful for all open source developers.


By the way, thanks for updating receiver_1.csv, that was the last update for your site.

You're welcome. BTW i'm very excited about the metal and micro fab bounties. Although this isn't my area the Perth rep rap hacker lab may be interested in this.

I will likely update my sig soon to reflect the ability to earn Devcoins through work on Rejuvepedia. In the mean time I would like to convert some of my bitcoins to devcoins. Is there anyone willing to trade?

[markm]

I will likely update my sig soon to reflect the ability to earn Devcoins through work on Rejuvepedia. In the mean time I would like to convert some of my bitcoins to devcoins. Is there anyone willing to trade?

Depends on the quantity and the price you're willing to pay.

(I certainly don't plan to throw devcoin away at some insanely low rate like "200,000 per bitcoin"!)

-MarkM- (Hmm, bitcoin 50 per block, devcoin 50000 per block. 50:50000 = ? )

P.S. Oh waitasec, isn't bitcoin crashing right now and devcoin rallying?

[caston]

I will likely update my sig soon to reflect the ability to earn Devcoins through work on Rejuvepedia. In the mean time I would like to convert some of my bitcoins to devcoins. Is there anyone willing to trade?

Depends on the quantity and the price you're willing to pay.

(I certainly don't plan to throw devcoin away at some insanely low rate like "200,000 per bitcoin"!)

-MarkM- (Hmm, bitcoin 50 per block, devcoin 50000 per block. 50:50000 = ? )

P.S. Oh waitasec, isn't bitcoin crashing right now and devcoin rallying?

I intend to buy more bitcoins to trade for devcoins but I won't be able to do that for at least another 3-4 days. In the mean time I have 60 BTC that I would like to trade. Any offers?

I will be factoring the difficulty of course.

[Unthinkingbit]

I finally got Abe working
Currently it is hosted by a friend of mine: http://devcoinblockexplorer.tk/
I know, it's slow as hell

Still can't mine btw

That's great.  Although I didn't officially announce it yet, I did write up at:
https://github.com/Unthinkingbit/charity/wiki/Devcoin-Bounty

"Finally, there will be a five million devcoin bounty for an open source devcoin block explorer."

I made the bounty so high because we need the devcoin block explorer and I thought it might be difficult.

So you lucked out and got five million devcoins.

Once you get devcoin running and post a receive address I'll send you the coins.  I suggest you split it with your friend who is hosting it.


Caston wrote:

You're welcome. BTW i'm very excited about the metal and micro fab bounties. Although this isn't my area the Perth rep rap hacker lab may be interested in this.

They're the last links in the matter compiler chain.  Once we have those, we can have open source anything.

I will likely update my sig soon to reflect the ability to earn Devcoins through work on Rejuvepedia.

You are in the next generation round:
https://raw.github.com/Unthinkingbit/charity/master/receiver_2.csv

once the block number reaches 8,000 you'll get plenty of devcoins.  So you can start handing out your million plus devcoins now, knowing that you'll get a lot more soon.

By the way you, Mark and I and pursers:
https://github.com/Unthinkingbit/charity/wiki/Devcoin-Description

which means we disburse money for bounties and stuff that comes up.  So of the five receive slots that you see there, one is your Rejuvepedia share, 32 * 10% (administration share) / 3 (3 administrators) = 1.0666.. is your administration share, which gives a total of 2.0666.. shares for you.  The remaining 2.933.. shares are your purser shares, which are to be disbursed.

I made you and Mark pursers because I assumed you would both want that and I was in a hurry to write the receiver_2.csv file.  If either of you don't want to be pursers and/or almoners, please message me and your purser slots won't be in the next receiver file.  Edit: Of course, you would still have your active developer slot and administrator vote and receiver maintainer sub share slot.

Note, receiver_3.csv is just a placeholder in case we get an unexpected huge amount of generation which blows past the receiver_2 round.  We'll discuss what slots to put in receiver_3.csv by block 9,000.

In the mean time I would like to convert some of my bitcoins to devcoins. Is there anyone willing to trade?

I'm asking people not to trade until devcoin is fully tested with many people on different platforms, and we've coordinated at least one more receiver file update.

As long as people haven't traded, if worst comes to worst and we must restart, we can resend the shares and bounties.  However, once coins are traded, people who bought devcoins would be out of luck.  I don't want anyone to feel cheated or lose money they can't afford.

As far as the devcoin price concerned, I pointed at the namecoin starting price as a guide, but in my personal extremely biased speculative opinion, since devcoin pays for its own development, it will grow quickly and so I plan on buying a lot of them if and when a devcoin exchange opens.

[markm]

The block explorer might not be quite as simple as it appears at first glance, because even if the generic explorer doesn't actually "break" on anything in devcoin's blockchain it is possible or maybe even likely (? not sure ?) that some small amount of customising might be worthwhile regarding the things we do differently.

sacarlson apparently ran into some gotchas in applying it to BEER and WEEDS, but maybe those have by now been genericised or were due to things he does that we don't do.

The hosting is a factor too of course; the reason I didn't slap up ABE on my own hosting is one needs the daemon too and my current hosting would not permit that (I'd have to upgrade it).

Still, I expect what you already see running is mostly all there and mostly just needs its hosting upgraded somewhat, which should start being feasible once devcoin exchanges start coming online.

-MarkM-

[caston]

Has anyone tried connecting another miner using the -o option in poclbm. I have added the rcpallow line and connected ok but getting about 10 or so
 "warning: job finished, miner is idle between each block"

I used
sudo ./poclbm.py -o 192.168.x.x -d 0 --u=x --pass=x -v -w 128

[markm]

Has anyone tried connecting another miner using the -o option in poclbm. I have added the rcpallow line and connected ok but getting about 10 or so
 "warning: job finished, miner is idle between each block"

I used
sudo ./poclbm.py -o 192.168.x.x -d 0 --u=x --pass=x -v -w 128

I don't see a port number there, what port number would poclbm.py default to?

And what port did you set devcoind to use for RPC ?

(It might itself have a default, if so probably 52323 or 52332, whatever the normal variation is between networking port and RPC port.)

-MarkM-

[caston]

Has anyone tried connecting another miner using the -o option in poclbm. I have added the rcpallow line and connected ok but getting about 10 or so
 "warning: job finished, miner is idle between each block"

I used
sudo ./poclbm.py -o 192.168.x.x -d 0 --u=x --pass=x -v -w 128

I don't see a port number there, what port number would poclbm.py default to?

And what port did you set devcoind to use for RPC ?

(It might itself have a default, if so probably 52323 or 52332, whatever the normal variation is between networking port and RPC port.)

-MarkM-

I didn't set any port but I tried connecting poclbm with 52333 and that got an rpc error. You see I did do one block though which makes me think my command line was ok. Maybe I need more connections to get enough work to keep two miners going? I am already running two instances of poclbm on my mining rig which has 2 6870s. The other one is booted into linux coin because I seem to get faster hash rates with it than I did when I setup opencl stuff myself. I do remember getting very similar problems when mining in pools but not as bad. I'm keen to get the other machine working as it has a 6950 but alas I have to get ready for work again soon ):

[markm]

52333 is the client to client p2p networking port.

It should not even be possible to assign that as RPC port as it should already be open automatically for the p2p networking.

Aha, 8332 is hard-coded multiple times as default RPC port. So if you aren't telling devcoin any different it will be on 8332 and if you aren't telling the miner program different likely it too uses 8332 so did connect.

Is your disk access particularly slow compared to your mining speed? Every time it starts trying to construct a block, in each thread it is doing that in, it looks up who to contribute to. It would probably be a lot better for it to load the entire receiver_*.csv into a cache in memory if it doesn't do so already. (I didn't look what receiver.h actually does, I just made calls from main.cpp that naively look as if they might well be being satisfied by means of going to disk over and over and over again. (Oh wait, also going to disk was not threadsafe in Qt too so I'd see four errors when four threads tried to mine, so at least back then it sure did not seem as if receiver.h was using a cache...)

-MarkM-

[caston]

52333 is the client to client p2p networking port.

It should not even be possible to assign that as RPC port as it should already be open automatically for the p2p networking.

Aha, 8332 is hard-coded multiple times as default RPC port. So if you aren't telling devcoin any different it will be on 8332 and if you aren't telling the miner program different likely it too uses 8332 so did connect.

Is your disk access particularly slow compared to your mining speed? Every time it starts trying to construct a block, in each thread it is doing that in, it looks up who to contribute to. It would probably be a lot better for it to load the entire receiver_*.csv into a cache in memory if it doesn't do so already. (I didn't look what receiver.h actually does, I just made calls from main.cpp that naively look as if they might well be being satisfied by means of going to disk over and over and over again. (Oh wait, also going to disk was not threadsafe in Qt too so I'd see four errors when four threads tried to mine, so at least back then it sure did not seem as if receiver.h was using a cache...)

-MarkM-

Yeah i'm not really sure. Would I have less issues if I installed groupcoind locally? I'm going to need to look at this tomorrow because I have to get ready for work now.

Otherwise would running nmap help? when I try it only checks the first 1000 points and that syntax for checking higher ranges seems to escape me.

[markm]

I actually only run miners against daemons running on the same machine as the miner, and referring to it as being at 127.0.0.1 (which corresponds to "localhost").

Early on I did try to have my GPU machines mine against the daemons on other machines, or even simply on each other's daemons, and it didn't work and i did not pursue why it did not work.

My Fedora Linux firewalls on the machines themselves are turned off completely so it should not be a firewall thing.

I have each of my other machines specified in -rpcallowip command-line arguments in each machine's daemon-startup scripts.

I basically shrugged and used 127.0.0.1 and didn't worry about it further.

I still have no aha moment as to "wft" could be the problem and for me using 127.0.0.1 obviates the problem, so until an aha moment strikes out of the blue it is likely that even if I feel I really really need lots of mined coins on one of my no-GPU boxes I'll just do wallet to wallet manipulation or moving of wallets to accomplish it until that aha moment comes along.

-MarkM-

[caston]

I might have some spare time tonight to hit a few more bounties. I hope to get more miners on or make hardware share and co-lo deals with others because the cost of electricity in my state is high.

[markm]

I might have some spare time tonight to hit a few more bounties. I hope to get more miners on or make hardware share and co-lo deals with others because the cost of electricity in my state is high.

I started mining because winters here are cold and I hoped to be able to live in my country house for the winter, which would involve electrically heating it at least until I can afford to re-do the whole wood-heat situation out there.

So although electricity isn't super cheap at least until I can use enough of it to get industrial rates, I was thinking of it as free electrical heating rather than as a mining expense.

The FPGA hardware project however seems to be coming along well enough that I am dubious of the utility of investing in many GPUs other than as electrical heat, and the amount of hashes one could get by heating with FPGAs this winter planning to heat with ASICs next winter might yet turn out to be a better way to go. Maybew along with picking up cheap "obsolete" REadeon electrical heaters from people who don't want to heat their houses electrically maybe.

Maybe we can work something out, possibly even involving GMC (General Mining Corp) which is currently mobilising to obtain groupcoins and devcoins for its treasury with which to back its "GMC" blockchain coinage...

I also just pulled out one of my 5870s that seems to maybe have burned out so what to do as next hardware step has suddenly become more urgent than I had hoped it would be.

-MarkM-

[Unthinkingbit]

The next devcoin thread "[800,000 DVC remaining bounty] for Devcoin preliminary testing" has been made:
https://bitcointalk.org/index.php?topic=34586.0

to get more visibility to get a few more testers and to have a proper Devcoin thread rather than being in the groupcoin thread.

Please make your next posts in the new Devcoin thread.

[cinnamon_carter]

sorry to post to an old thread however Groupcoin is actually still alive and the current thread for it is here

https://bitcointalk.org/index.php?topic=67991.200;topicseen

Now with a windows wallet based on 8.x btc source and holding up pretty well with difficulty over 15 million (last I checked)