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-

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-

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-

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-

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-

Remember webspider or spider, the free open source webserver?

They changed to spinner because someone else took the name spider? And then to Roxen because someone else took the name spinner? Then to Caudium because Roxen Internet Services turned it toward proprietary and took the name Roxen with them?

http://www.caudium.net/server/history.rxml

The only reason someone hasn't hijacked "Linux" is because Linus trademarked it.

-MarkM- (I am not a lawyer. I don't think Linus is either.)

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-

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-

Pricing in different commodities/currencies doesn't count as freedom in degree terms?

-MarkM-

This discussion is very biassed. Even if all fiat currencies are experiencing a rally in terms of bitcoins why be negative about it? So the fiats are rallying, so what? How about RAM and MHz and MHash, are they rallying or crashing, in terms of, uh, whatever... bubblegum? Each other? Bandwidth? Etc.

Provided no-one breaks the "fact" that a BiTCoin address you have the private key for is "yours" in any clone/fork (other than ones that break this convenience, which some people seem to be plotting planning or at least laying the groundwork for), you can easily be automatically sent some other currency to whatever address you sent from. So an exchange can be simply a bot that, for example, watches for BiTCoin coming in at its "BTC to MBC" address and for each BTC address that sends BTC to that address in the BTC network it sends the corresponding/exchanged amount of Martian BotCoin on the Martian BotCoin network. And vice versa, and for all pairs of currencies using compatible addresses.

-MarkM-

BiTCoin is itself a central point of (I'm gonna say success... )

As you might be aware, MI-5 and MI-6 are fictional, which need not necessarily imply that Martial Intelligence is an oxymoron.

The Hacker, Martian, European and United Nations civilisations (among others) are, in mainline Freeciv software, listed as fictional.

Just so you know.

So. In the spirit of, uh, well lets say "hypotheticals"...

Let us imagine someone... we might as well call them Martians for now... had learned of the interesting mathematical cryptological computation network based currency used by an even more advanced civilisation whom we might as well refer to as Hackers.

For a number of reasons, perhaps not least among them some unfortunate effects contact with relatively advanced cultures sometimes has upon cultures, the Martians imagined there might be room in the universe for other currencies using basically the same technology as that used by the Hackers' currency. Accordingly, though by what precise means history might not entirely make clear, the Martians obtained sufficient knowledge of the relevant Hacker technology. Thus were born Martian BotCoins.

You don't have to believe this - not everyone does it seems, but Martian propaganda seems to like to at least pretend that it does - but the Martians are not as brutally aggressive and warlike as various "Mars is the god of war, Martial means relating to war" etc etc etc myths and legends might have led some to suspect or imagine. Thus it is that United Nations Scrip, referred to by some as United Nations Shares came into existence. Yes, the propaganda arm of the Martian Intelligence 5ervices  would have you believe the Martians would like lo the many nations of sentient beings to co-exist peacefully.

Of course the very concept of a United Nations might itself be seen as yet another threat of centralisation. If it is true that Hackers and Martians are fictional, even in the eyes of a United Nations itself purported or thought by some to be fictional, might it be that the United Nations invented the myths or legends of the existence of Hackers and Martians in order to appeal to some notion that the United Nations might not itself be the most advanced and powerful civilisation? (What is in a name? Oh wait, are we supposed to consult the NaMeCoin system about such questions?)

General Mining Corp (GMC) conducts mining operations of various kinds and purports thereby to provide some notion of value to its own offering, General Mining Corp scrip (or shares, as some sometimes call them). General Retirement Funds (GRF) uses its own scrip or shares in various joint ventures with GMC and, in general, in pursuit of advancing the cause of excellent retirement plans to fit its customers' various needs and desires.

A prototype Graphical User Interface (GUI) derived from bitcoin-qt and multicoin is is now on github at https://github.com/knotwork/bitcoin-qt

Github has it as a fork of bitcoin-qt but mostly because I did not know how to rename it something more related to GRouPcoin, because it is an initial test of the cloning or forking of variants and this first variant is a variant headed toward use with GRouPcoins.

I would like to fork more variants directly off of bitcoin-qt or possibly off of this fork of bitcoin-qt, however I have not yet learned how to do that. I had in mind bitNicKeLs for my next fork...

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

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-

Install "Battle for Wesnoth" version 1.8 and look for my campaigns in its add-ons system.

Grab the one called "Between the Worlds", and choose the "Time Lord" option when picking which character to play.

When you are well along in your Time Cadet training you should find clues to further studies, not all of which use the Battle for Wesnoth software as their client software. (Battle for Wesnoth is more a way of presenting past events than a tool for influencing events going forward...)

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

I would like to be able to have miners connect to a pool and not have to concern themselves at all about what the pool happens to be mining from moment to moment.

A whole bunch of different blockchains could thus avail themselves of mining power without the miners having to worry about whether any of those chains are ever going to amount to anything. The miners can simply do work for pay, being paid in whatever currency they like to be paid in, leaving the whole problem of which blockchain might or might be worth how much in terms of whatever currency the miner pays rent and groceries and electricity in to the pool operators. All the miner need care about is whether the pool is offering enough of the currency they want per unit of work they do.

Maybe pool isn't the best word for that business, but pool software or "load balancing software for miners" both seem like they are relatively close to the kinds of functions such a business would need.

-MarkM-

Being able to buy or sell a specific quantity can be a nice feature for those who want it, htough it can probably also be annoying for those who would prefer to be the one choosing the quantity.

For example suppose I am thinking I might like to buy a special deal on alpaca socks but would need no more and no less than 100 BTC to do that. Meanwhile I also am tempted by a collection of phonograph records someone wants no more and no less than 2000 USD for.

I would thus like to buy either 100 BTC or 2000 USD or both, but any less of either is useless (I might as well just use my GBP for whatever I normally use it for and forget about those socks and recordings.)

While it is nice for me to place an order for no more nor less than 100 BTC, I can see if being potentially irritating for other people who might wish they could sell me some smaller quantity.

-MarkM-

The username field was weirded out so that Firefox didn't automatically populate it and thus also could not have automatically plugged in my password even if it had been set to do so.

But having manually entered my username and password I am in no problem and all my bitcoins are still there waiting for me.

-MarkM- (Well actually, all the bitcoins I had there. My bitcoins elsewhere hadn't teleported there. )