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

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-

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-

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.


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.


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.

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-

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-

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


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.


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.

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.

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.


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

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


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.


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


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

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.

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-

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-

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.

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-

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?

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.

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?

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.

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.


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.


Yup.


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.


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.


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.


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.


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.


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.


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.

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