Topic: [50 BTC total bounty] for Groupcoin development and help - page 5. (Read 26269 times)

1PtPbUJnjeCsD2dvTeKQLSttLg75G2k9Vb

Confirmed - thanks!

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:


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

-MarkM-

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

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-

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

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

Good luck:)

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


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-

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:

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

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


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

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

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-

183DMPnYWejo59A2P9SftbgfiQULjLHHry - thanks!


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.

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.


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.

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

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

The current bounty offer for you is:


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.

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.

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


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.

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-

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

Five coins are on their way.


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.


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?