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

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-

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.


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 reason I'm using constant generation is so that there would always be reward for development.  Simplifying code is a nice bonus.


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.


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.

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 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 mineraddressvector(mineraddressstring.begin(), mineraddressstring.end());
//    std::vector 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-

Why would it need to wait for the coinbase transaction to mature?  Since they're in the same block, if the generate 50 coinbase transaction fails, wouldn't the send 25 coins transaction also fail?

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-

Thank you for the information.


Would it possible to make give a portion of a mined block even if your account has no money?  For example, if your account had zero coins, you mined a block worth fifty, then as the last transaction on the block the client added 'send 25 coins to a developer', would that transaction get through?


Thanks for that information.  When the actual block chain goes live, it will certainly be redone from stratch.  Hopefully the testing can be done without making too many block chains.

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-

If you can mine into a given key, that's great.  I first changed the generation key because I didn't know if you could mine into a public key whose private part you may not even have.

In theory, if you use a key from your receive list, you should see the transaction coming into your account.


The point of the devcoin is that part of the generation is directly sent by the miner to a receiver on the receive list accoding to the block number.  So given the list at:
https://raw.github.com/Unthinkingbit/charity/master/almoner.csv

when the modulo of the block number and the number of entries (17 at the time of this writing) is zero the developer portion would be sent to the zeroth entry on the list:
1JEnRbir5ceXZYH7HXyQZabM4LRQU7MRsx

when the modulo is one the developer portion would be sent to the count one entry on the list:
1FyMZskjC9fXSYATVXP3TH3NNeD9E1Pynp

and so on.

The first coinbase goes to the miner as usual, it uses the GetReservedKey() function as before.  The second coinbase would go to the modulo entry on the list, although for the test it is simply going to another GetReservedKey().  To test this I changed the validation code so that it only checks if there are more than two coinbase entries in the block:


The initial change is just to test if a block chain can be generated with two coinbases and if the wallets all add up.  Later the coinbase generation would be changed to send the coinbase to the correct receiver for that block number and the validation would be changed to see that the second coinbase is indeed being sent in the correct amount to the correct receiver for that block number.

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-

I have no idea how to fix that error.  Therefore, it is time for Plan B!

Groupcoin was intended as a stepping stone to the more sophisticated Devcoin, where every miner would automatically send to a receiver on a synchronized list, according to the block number.  I started with groupcoin because I figured it would be easier, but since it turns out there's a groupcoin problem with no known solution, the only way out is to go straight to devcoin.  There will be an equivalent 50 BTC total bounty for devcoin development, the details of which will be posted later.  I will end up paying a total of at least 100 BTC for the final devcoin.

The key issue with devcoin is how to send an extra transaction.  The first test will be by creating another coinbase.  In the new devcoin at:
https://github.com/Unthinkingbit/devcoin

two coinbases are created, and the validation has been changed so that it lets through the first two coinbases.

Please try this out and see if it works.  If it does work, the subsidy will be changed, a list of receivers will be used, the second coinbase will be checked, and development will proceed from there.  If there is an error, then we'll look for another way of sending a second transaction.

There is no need to make a long block chain.  Just a few blocks would be enough to know if the idea works or not.  Even if everything works fine, the chain would have to be restarted anyways because the subsidy would have to be changed.  This is only a test.

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-

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.

I haven't generated any blocks, I don't have a GPU and have never mined seriously.  All I did was run groupcoin and check to see that it passed the genesis block assert and displayed the generator key on screen.


I'm happy to use 0 or 111, so that's why I set it back in the latest version of groupcoin.  When I changed ADDRESSVERSION I did not know it would cause problems.  May as well restart with ADDRESSVERSION 0 or 111.

There is no need for a long string of blocks.  Only two generated blocks are needed to check that the generation code is working properly.

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-

The reason I changed the address version was because of sacarlson's post:

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_

Since this may be causing trouble, and we're on a different port than bitcoin so it's unlikely they'll be a conflict, I switched it back to 0 : 111 in:
https://github.com/Unthinkingbit/groupcoin


When groupcoin is first run, which it determines by checking to see if there is a default key, it creates a generation key.  If you ran groupcoin with the wallet already in existence created by another program which did not load the wallet with a generation key, it would see a default key so it would not make a generation key, which might lead eventually to calling a non existent key.

So please trash the groupcoin wallet, and try running groupcoin again and post the results.

There is also a really small chance that the Berkeley database version is different, as mentioned at the bottom of the bitcoin-qt readme:
https://github.com/laanwj/bitcoin-qt

However, I think that is unlikely because if you compiled both my groupcoin and your groupcoin on your machine, they would link to the same Berkeley libraries.

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-

Great work Mark!  I tried out those values and groupcoin worked.  I've updated groupcoin and groupcoin_unstable accordingly.

So I'll release the genesis block and miner bounties.  I believe 3 BTC of the 5 BTC for the genesis block plus 1 BTC for maintaining the net = 4 BTC for you is fair.  Please confirm that you accept this.

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.


Could you explain further what is happening?  The groupcoin GUI displays the generation address on the main screen; are the generation addresses different that the displayed address? Are the generation addresses all the same or are they different?