[50 BTC total bounty] for Groupcoin development and help

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

[1714796655]

1714796655

[1714796655]

1714796655

[1714796655]

1714796655

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