Why is ASIC so slow to do? If the routing compiles and so on take a lot of hours aren't there ways to process such problems in parallel or something? Maybe we could all share the CPU power of our mining rigs to help speed up such computations?

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

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-

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.


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

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.


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-

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-

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

So is this actually happening? Or was it just noise? Or what?

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

As already stated, you can simply "back" bitcoins with gold yourself by offering to sell gold for bitcoins.

You don't need a whole separate blockchain for that.

Which is good because if miners are spending their money on gold instead of electricity and hashinh-hardware the blockchain might be quite vulnerable to attack by anyone who chooses to invest in computing gear instead of gold.

As to it not making sense to back a currency with a currency, well, maybe it doesn't need to make sense. What is a 'reserve currency' but backing in one currency for another?

There are a whole bunch of blockchain-based currencies looking at all these concepts precisely because they do want to "back" their currencies. Part of how they plan to do that is to each buy a whole bunch of each of the others, so that all of them have a decent amount of "float" to use to buy back their own using any of the others.

If you would like to "back" one or more of them by selling gold for them, instead of or as well as "backing" bitcoin by selling gold for bitcoin, I doubt they will object. Heck they might even "back" your gold by buying it with various currencies not only with goldcoin...

Come to think of it, United Kingdom Britcoin (UKB) might for traditional reasons like to be "backed" by silver, How much silver would you sell for one UKB?

-MarkM-

Facebook credits are pretty much useless because they cannot be traded.

If farmville real estate, objects, services tc also cannot be traded, farmville is also useless.

What we need are virtual / digital domains and/or games that can be traded.

As far as I know, Ogame, Zorg Empire, and Astro Empires, and maybe pretty much all similar games / universes, do not permit trade or are very restrictive of trade.

That is why I set up http://galaxies.mygamesonline.org/ ... To have a universe whose resources can be traded.

It is also why various nations in Freeciv's Galactic Milieu have commissioned blockchain-based currencies: they want to trade.

The galaxies game is particularly good for trade right now because it turns out calling it Beta was maybe a bit of an exaggeration. I would call it a little more like Alpha, because the combat system not only does not work but cannot ever have worked in the state it is in, It seems to have been started but then maybe been undermined by some database field name changes and some formats of certain fields and gosh knows what else. So you don't have to worry about being attacked, you can just build up your resource production.

I have one of those villages games too I was going to try, though it too might well turn out not to be nearly as finished as the box tries to make it seem. (Well not really box: more like SourceForge repository. )

I also have been adapting my IRC over-the-counter-trading bots back ends to create bots for Crossfire RPG.

If facebook wants to try to prohibit trade in its oppressive universes lets just build better universes... or at least free-er ones!

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

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-

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-

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-

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-

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-

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-