Devcoin

[btc_artist]

Sorry to keep harping on this, but I still can't get the block chain to download in devcoin-qt. Does anyone have any ideas of things I can check to try and get it working?

Okay I tried again, and I still can't get it working.  I created a brand new Ubuntu 11.10 installation in VirtualBox, then downloaded and compiled devcoin-qt.  It runs, but stays at synchronizing 0%, 0 blocks downloaded, 3 peers.  Any ideas at all?

[1714186763]

1714186763

[1714186763]

1714186763

[1714186763]

1714186763

[markm]

Sorry to keep harping on this, but I still can't get the block chain to download in devcoin-qt. Does anyone have any ideas of things I can check to try and get it working?

Okay I tried again, and I still can't get it working.  I created a brand new Ubuntu 11.10 installation in VirtualBox, then downloaded and compiled devcoin-qt.  It runs, but stays at synchronizing 0%, 0 blocks downloaded, 3 peers.  Any ideas at all?

Did you try adding the IPs of the three amazon-based nodes as my shell script does as I mentioned earlier?

Unthinkingbit had me add al lthe receiver files to the realse thinking that woudl fix some problem windows people were having but maybe that doesn't actually fix their problem... Oh wait, you tried Ubunto too. Hmm. I guess I should try starting from scratch under a different user than the one that normally runs the thing... Annoying having to use only one machine nowadays (landlord didn't like electric bill), I'll have to stop mining to try this.

Hmm, it got a bunch of orphan blocks then end connection.

Unthinkingbit, could it be that somehow the changes for various adaptations of difficulty and so on have somehow get it to the point where the early part of the blockchain is no longer able to compute as valid anymore or something like that?

-MarkM-

[btc_artist]

Sorry to keep harping on this, but I still can't get the block chain to download in devcoin-qt. Does anyone have any ideas of things I can check to try and get it working?

Okay I tried again, and I still can't get it working.  I created a brand new Ubuntu 11.10 installation in VirtualBox, then downloaded and compiled devcoin-qt.  It runs, but stays at synchronizing 0%, 0 blocks downloaded, 3 peers.  Any ideas at all?

Did you try adding the IPs of the three amazon-based nodes as my shell script does as I mentioned earlier?

Unthinkingbit had me add al lthe receiver files to the realse thinking that woudl fix some problem windows people were having but maybe that doesn't actually fix their problem... Oh wait, you tried Ubunto too. Hmm. I guess I should try starting from scratch under a different user than the one that normally runs the thing... Annoying having to use only one machine nowadays (landlord didn't like electric bill), I'll have to stop mining to try this.

-MarkM-

For some reason, I completely missed that reply.  Sorry about that.  I will try that now.  Thanks.

[btc_artist]

Okay, I tried adding those three IP addresses. Devcoin-qt now starts and reports that it has 4 connections, but no blocks have been downloaded. 

What port does devcoin use, so I can make sure it's open?  I searched this thread and couldn't find it.

[markm]

I just tried it. Didn't help.

I did a cat of the (very small) block data file, and it looked like it maybe even consists of only the genesis block.

Unthinkingbit, might it be that, as I long ago worried when initially making the genesis block then not mining constantly thereafter, some kind of check of how long has elapsed between blocks might be rejecting the very first block after the genesis block due to we waited too long to actually start adding blocks to it?

It didn't used to be a problem, it seemed you could create a genesis block then go weeks without mining, but maybe something in the time travel exploit fixes or something is nowadays a lot less forgiving of the whole chain having not been mined for too long or something?

I recall with groupcoin this was part of my argument why we should keep mining steadily; I was always concerned that it is a bit silly to have a genesis block claiming we started on a certain date then not actually start until days or even weeks later.

Could the delay between creating genesis block and actually starting to mine for real be biting us on the backside now?

-MarkM-

EDIT: It has got to be a bug in the -qt version, something not the same, probably in last change/update, as what I put into the devcoind, because if I simply change devcoin-qt to devcoind in same shell script and run it, presto I get good blocks, it starts getting the blockchain.

So I guess I need to go back into PMs to find the changes I was told to make for latest release and check I did them exactly the same way in the -qt as in the devcoind, which presumably/probably I did not. I must have missed something or typo'd something or somesuch. The -qt is broken, the devcoind is not.

[markm]

Last change was just to default fees, to defend against dust spam.

So it must have broken further back than that and we jsut don't have enough new people starting from scratch with the GUI to notice when it breaks.

Hopefully it is something in main.cpp, so I did a diff:

Code:

[root@megabox bitcoin]# diff devcoin/src/main.cpp devcoin-qt/src/main.cpp
20d19
< 
650d648
< 
737d734
< 
797d793
< 
993,994d988
< 
< 
1359a1354
>             return error("AcceptBlock() : rejected by checkpoint lockin at %d", nHeight);
1375c1370
<                 if (nBestHeight > (pnode->nStartingHeight != -1 ? pnode->nStartingHeight - 2000 : 134444))
---
>                 if (nBestHeight > (pnode->nStartingHeight != -1 ? pnode->nStartingHeight - 2000 : 118000))
1494c1489
<         ThreadSafeMessageBox(strMessage, "Bitcoin", wxOK | wxICON_EXCLAMATION);
---
>         ThreadSafeMessageBox(strMessage, "Devcoin", wxOK | wxICON_EXCLAMATION);
1546c1541
<         hashGenesisBlock = uint256("0x0000000062558fec003bcbf29e915cddfc34fa257dc87573f28e4520d1c7c11e");
---
>         hashGenesisBlock = uint256("0x0000000087a230b3a9d612d73dba267cb70135b76a923cae2c74852c2e5d7639");
1605,1607c1600,1603
<         printf("%s\n", block.GetHash().ToString().c_str());
<        	printf("%s\n", hashGenesisBlock.ToString().c_str());
<         printf("%s\n", block.hashMerkleRoot.ToString().c_str());
---
>         printf("hashMerkleRoot  : %s\n", block.hashMerkleRoot.ToString().c_str());
>         printf("hashGenesisBlock: %s\n", hashGenesisBlock.ToString().c_str());
>         printf("Actual blockhash: %s\n", block.GetHash().ToString().c_str());
> 
1610,1621c1606
<            // This will figure out a valid hash and Nonce if you're
<            // creating a different genesis block:
<            uint256 hashTarget = CBigNum().SetCompact(block.nBits).getuint256();
<            while (block.GetHash() > hashTarget)
<            {
<                ++block.nNonce;
<                if (block.nNonce == 0)
<                {
<                    printf("NONCE WRAPPED, incrementing time\n");
<                    ++block.nTime;
<                }
<            }
---
>            printf("You need to put correct hashMerkleRoot in these asserts to get past these asserts.\n");
1623,1630d1607
< 
<         //// debug print
<         printf("block.nTime = %u \n", block.nTime);
<         printf("block.nBits = %u \n", block.nBits);
<         printf("block.nNonce = %u \n", block.nNonce);
<         printf("%s\n", block.GetHash().ToString().c_str());
<         printf("%s\n", hashGenesisBlock.ToString().c_str());
<         printf("%s\n", block.hashMerkleRoot.ToString().c_str());
1648,1649c1625,1626
< 	}
< 	//// debug print
---
>         }
>         //// debug print
1653,1655c1630,1632
<         printf("%s\n", block.GetHash().ToString().c_str());
<         printf("%s\n", hashGenesisBlock.ToString().c_str());
<         printf("%s\n", block.hashMerkleRoot.ToString().c_str());
---
>         printf("hashMerkleRoot  : %s\n", block.hashMerkleRoot.ToString().c_str());
>         printf("hashGenesisBlock: %s\n", hashGenesisBlock.ToString().c_str());
>         printf("Actual blockhash: %s\n", block.GetHash().ToString().c_str());
2154d2130
<         unsigned int nBytes = 0;
2160c2136
<                 printf("  getblocks stopping at %d %s (%u bytes)\n", pindex->nHeight, pindex->GetBlockHash().ToString().substr(0,20).c_str(), nBytes);
---
>                 printf("  getblocks stopping at %d %s\n", pindex->nHeight, pindex->GetBlockHash().ToString().substr(0,20).c_str());
2164,2167c2140
<             CBlock block;
<             block.ReadFromDisk(pindex, true);
<             nBytes += block.GetSerializeSize(SER_NETWORK);
<             if (--nLimit <= 0 || nBytes >= SendBufferSize()/2)
---
>             if (--nLimit <= 0)
2171c2144
<                 printf("  getblocks stopping at limit %d %s (%u bytes)\n", pindex->nHeight, pindex->GetBlockHash().ToString().substr(0,20).c_str(), nBytes);
---
>                 printf("  getblocks stopping at limit %d %s\n", pindex->nHeight, pindex->GetBlockHash().ToString().substr(0,20).c_str());
2836,2838d2808
<     // Add our coinbase tx as first transaction
<     pblock->vtx.push_back(txNew);
< 
2841d2810
<     //int64 nFees = 0;
3038c3007
<     printf("BitcoinMiner:\n");
---
>     printf("DevcoinMiner:\n");
3048c3017
<             return error("BitcoinMiner : generated block is stale");
---
>             return error("DevcoinMiner : generated block is stale");
3059c3028
<             return error("BitcoinMiner : ProcessBlock, block not accepted");
---
>             return error("DevcoinMiner : ProcessBlock, block not accepted");
3070c3039
<     printf("BitcoinMiner started\n");
---
>     printf("DevcoinMiner started\n");
3105c3074
<         printf("Running BitcoinMiner with %d transactions in block\n", pblock->vtx.size());
---
>         printf("Running DevcoinMiner with %d transactions in block\n", pblock->vtx.size());
3252c3221
<         printf("Starting %d BitcoinMiner threads\n", nAddThreads);
---
>         printf("Starting %d DevcoinMiner threads\n", nAddThreads);
[root@megabox bitcoin]# 

Maybe someone can see something in there that explains why devcoind gets new blockchain seemingly okay but the -qt thinks everything after the genesis block is an orphan?

Hmm, like WTF is that totally different genesis block hash part about? I hmmm WFT happened / is happening...

-MarkM-

EDIT: the -qt is obsolete anyway, since the base/mainline bitcoin now uses qt instead of wxwidgets. SO we should just forget about the qt and update the devcoin aka devcoind release to the latest bitcoin, thus no longer needing two separate releases as the GUI will use the exact same actual engine code as the daemon, no more trying to make same fixes to two different packages.

It seems quite possible that I *did* regenerate the genesis block after a restart so as to not have long gap in time between date of genesis block and date of next block, but didn't put the new hash into the -qt and that never got noticed as it only checks that when getting new blockchain.

I do not understand though why the -qt didn't simply claim the genesis hash was wrong and die, instead asking for more blocks and listing them as orphans.

If someone can discover a way to tell github to make a fork under a new name, I would like to make a fork of the latest bitcoin but name it devcoin, so we can start trying to turn current bitcoin into an up to date devcoin...

[btc_artist]

Okay, I tried adding those three IP addresses. Devcoin-qt now starts and reports that it has 4 connections, but no blocks have been downloaded. 

Is there anything in the debug.log file?

Here it is:  (and markm's analysis is probably right about orphan blocks)

http://pastebin.com/dNJEKhYZ

[markm]

I vaguely recall people had trouble in past getting initial blockchain with the -qt, and just ran the daemon instead.

However, after looking at that diff, I am not confident that the -qt will actually work even once the blockchain *is* downloaded, as it seems to have a different idea of at which block some fix or other is to kick in. (That is visible in the diff before the part where we see two different genesis block hashes.)

-MarkM-

[markm]

Thanks.

The different genesis hash is just the testnet one.

The different height thing is something to do with trying not to bother with old inventory until you have the blockchain, both versions numbers seem just inherited from bitcoin, probably should be a constant one can set someplace convenient, something like how big was blockchain last time we coded this.

The message about failing checkpoint though looks like it should have fired every time, as that line appears twice in the -qt, once as clause of if, but then immediately thereafter, from clumsy delete old and paste new obviously. The second occurrence should just unconditionally fire.

But that would make it do the return error thing, which I would have expected to cause the program to die. So it is still somewhat mysterious.

I am deleting the extra copy of that duplicated line and seeing if that fixes it.

EDIT: Yep, that was the culprit. Tarring up to put to sourceforge now...

EDIT2: Ok, done. devcoin-qt-8-Dec-2011.tgz (at https://sourceforge.net/projects/galacticmilieu/files/ as usual).

-MarkM-

[markm]

What port does devcoin use, so I can make sure it's open?  I searched this thread and couldn't find it.

It is set in net.h:

inline unsigned short GetDefaultPort() { return fTestNet ? 62333 : 52333; }

So 62333 for testnet (which the d and the -qt disagree currently as to correct hash for), 52333 for real net.

-MarkM-

[btc_artist]

That fixed it.  It's downloading the block chain now.  Thank you very much for your hard work markm.

[btc_artist]

Perhaps I spoke too soon.  It quickly got to 99% (18850 blocks downloaded) and stopped there.  It's been like that now for several minutes.

[markm]

Maybe block 18851 doesn't have the expected checkpointed hash,

 (nHeight == 18851 && hash != uint256("0x00000000005775d287176111b9d6fb1e1618ca13151b1f97f830b3d0fea4197d")))

or that hash is actually for the previous or next block.

I thought it was block 18851 because in the debug.log it said:

BitcoinMiner:
proof-of-work found
  hash: 00000000005775d287176111b9d6fb1e1618ca13151b1f97f830b3d0fea4197d
target: 000000000079d483000000000000000000000000000000000000000000000000
CBlock(hash=00000000005775d28717, ver=1, hashPrevBlock=00000000001afbb1ac53, hashMerkleRoot=9929a03757, nTime=1321878699, nBits=1b79d483, $
  CTransaction(hash=9929a03757, ver=1, vin.size=1, vout.size=2, nLockTime=0)
    CTxIn(COutPoint(0000000000, -1), coinbase 0483d4791b0130)
    CTxOut(nValue=5000.00000000, scriptPubKey=049c73dbd9a3389072f874670a677b)
    CTxOut(nValue=45000.00000000, scriptPubKey=OP_DUP OP_HASH160 2639637eb4cc)
  vMerkleTree: 9929a03757
11/21/11 12:31 generated 5000.00
keypool keep 7244
  nActualTimespan = 98958  before bounds
GetNextWorkRequired RETARGET
nTargetTimespan = 86400    nActualTimespan = 98958
Before: 1b78714c  000000000078714c000000000000000000000000000000000000000000000000
After:  1b79d483  000000000079d483c52bdd36d815119b92bdd36d815119b92bdd36d815119b92
AddToWallet 9929a03757  new
SetBestChain: new best=00000000005775d28717  height=18851  work=3040468427823054
ProcessBlock: ACCEPTED

which I was still able to find in the debug.log

Seems to me that in the past that height= number was the number matching the preceding hash number.

Maybe that is not the block 18851 you are being sent?

-MarkM-

[doublec]

Maybe that is not the block 18851 you are being sent?

Is there a block explorer for devcoin?

[markm]

Maybe that is not the block 18851 you are being sent?

Is there a block explorer for devcoin?

I saw a couple announced along the way, but any I actually tried to look at just kind of hung, either website too slow or back end too slow or site offline or something, not sure what, but I never actually got as far as actually seeing a page of output from any of them.

The checkpoint at 18851 was a very recent block, maybe it did turn out later to be an orphan. I am going back a bunch of blocks now to find a checkpoint to add, more recent, and remove that 18851 checkpoint. Maybe that will fix it.

I uploaded a new -qt to https://sourceforge.net/projects/galacticmilieu/files/ and will put a new devcoind there too shortly.

(SourceForge's web-based upload always craps out on devcoind, I have to go look up how to do it via sftp each time.)

-MarkM-

[markm]

If you have identified the original bitcoin that devcoin was made from, presumably with a context diff you can get the complete set of changes that constitute devcoin's difference from bitcoin.


Then maybe we can work through them trying to apply them all correctly to the latest stable release of bitcoin and maybe from there be poised to pull any more fixes that bitcoin comes up with?

If I have this right, that would involve forking from https://github.com/bitcoin/bitcoin and renaming my fork devcoin then start applying the patches.

As for adding merged mining, I do not understand how clients confirm the validity of blocks that claim to have their proof of work on some other chain that a given person running a client might not even have installed, and even if they do have it installed its blockchain is hopefully under some other username so that the various daemons cannot mess with each other's wallets.

What is actually involved at the client to check that a block is valid when it has been merged-mined, especially if the chain used as parent is some new one we never even heard of before? What info about how to find that chain, how to get info from it about proofs of work and so on does the client need, and where/how does it get it?

-MarkM-

[markm]

The -qt was unable to mine because the threads it used were not compatible with something, maybe with the going out to get the receiver files or something like that.

If those threads are now in use in the latest bitcoin, we might find that we cannot mine using the new version.

That would require finding some alternate means of getting the receiver files that is thread-safe with the newfangled threads.

-MarkM-

[markm]

So how do they check the hash is correct? It is a hash of some other chain's block isn't it, not the hash you get by hashing the block of the child chain you are actually the client for?

-MarkM-

[markm]

It looks as if the child chain client has to know in advance exactly which chain(s) are to be acceptable as parent chains, and how to get hold of specific blocks of those parent chains. So basically it is not a miner's decision hey I think I will mine with chain Y using chain X as parent; it is hard-coded into the clients of chain Y exactly which chain(s) can be used as parent and exactly how to tell which of those chains, if more than one possible parent is coded in, a particular merged-mined block did chose as its parent.

My confusion arose from seeing all kinds of posts all over the place that made it sound like a miner just decides one day hey it would be fun to use this one as parent for that one today...

Do the child chain clients contact the parent chain network as well as their own network, and keep their own copy of the parent chain blockchain on hand to check against? If not, how do they go about getting the referenced block of the parent chain to check a merge mined block against? Some hard coded block explorer URL they consult or what?

-MarkM-

[cablepair]

I would talk to Shads the devloper of PoolserverJ about this, I am sure he could give you some really good information

from my limited understanding I believe it creates a sort of virtual chain (bitcoin-mm) comprised of work from the parent and child chains at a user defined ratio - the proof of work is submitted to this "virtual" chain and thus both the parent and the child

as long as they are compatible with merged mining it does not matter which one is the parent and which one is the child