Author

Topic: Devcoin - page 163. (Read 412955 times)

hero member
Activity: 935
Merit: 1015
December 09, 2011, 06:17:44 PM
Kumala made a permanent node: 209.217.250.10

It is running the standard devcoind daemeon, so it should allow up to 125 connections (default). None of the ports are blocked, so the service should be available.

If anyone uses it, please post whether it works or not.

For making the node, Kumala gets 2/5 of a share.  For maintaining it, he gets 1/5 of a share as long as it is running.
full member
Activity: 154
Merit: 102
Bitcoin!
December 09, 2011, 09:33:23 AM
I uploaded a new -qt to https://sourceforge.net/projects/galacticmilieu/files/ and will put a new devcoind there too shortly.
Tried that and it seems to work correctly now.  All 21083 blocks have been downloaded.  Thank you very much!
legendary
Activity: 2940
Merit: 1090
December 09, 2011, 09:15:32 AM
Yeah but unless the client can actually go look at the parent chain, anyone could just pretend they have a chain someplace that they used as parent, and make up stuff about some fictional block on that fictional chain they supposedly did the merged mining with.

Unless you can actually go look at that parent to make sure it really does have your chain's merkle hash thing in it at the place described and at the difficulty described, what does having a parent chain accomplish?

EDIT: maybe we don't care if the purported other chain(s) exist so long as the hash is difficult enough? It'd be just as much work to make the entry for the rainbow table of fake merged mining proofs one per merkle our chain might have that it wants to see in the proof as it would be to do the real proof? (But having done the real one, what stops you saving it as an entry for rainbow table in case a collision ever occurs so that you get to present the same proof again? Just the sheer unlikeliness of collisions?)

-MarkM-
hero member
Activity: 896
Merit: 1000
Buy this account on March-2019. New Owner here!!
December 09, 2011, 08:40:47 AM
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
legendary
Activity: 2940
Merit: 1090
December 09, 2011, 08:19:05 AM
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-
legendary
Activity: 2940
Merit: 1090
December 09, 2011, 07:05:54 AM
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-
legendary
Activity: 2940
Merit: 1090
December 09, 2011, 06:41:55 AM
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-
legendary
Activity: 2940
Merit: 1090
December 09, 2011, 06:25:38 AM
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-

legendary
Activity: 2940
Merit: 1090
December 09, 2011, 05:26:46 AM
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-
legendary
Activity: 1078
Merit: 1005
December 09, 2011, 04:49:29 AM
Maybe that is not the block 18851 you are being sent?
Is there a block explorer for devcoin?
legendary
Activity: 2940
Merit: 1090
December 09, 2011, 04:09:56 AM
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-
full member
Activity: 154
Merit: 102
Bitcoin!
December 09, 2011, 12:28:41 AM
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.
full member
Activity: 154
Merit: 102
Bitcoin!
December 09, 2011, 12:18:13 AM
That fixed it.  It's downloading the block chain now.  Thank you very much for your hard work markm.
legendary
Activity: 2940
Merit: 1090
December 08, 2011, 07:11:05 PM
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-
legendary
Activity: 2940
Merit: 1090
December 08, 2011, 06:57:09 PM
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-
legendary
Activity: 2940
Merit: 1090
December 08, 2011, 05:34:08 PM
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-
full member
Activity: 154
Merit: 102
Bitcoin!
December 08, 2011, 05:30:24 PM
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
legendary
Activity: 2940
Merit: 1090
December 08, 2011, 05:05:04 PM
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...
legendary
Activity: 2940
Merit: 1090
December 08, 2011, 04:45:44 PM
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.
full member
Activity: 154
Merit: 102
Bitcoin!
December 08, 2011, 04:43:10 PM
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.
Jump to: