Author

Topic: Private testnet between PC and VM (Read 2591 times)

sr. member
Activity: 411
Merit: 252
June 01, 2015, 04:14:29 PM
#20
I'm back with a question ;-)

I didn't run my testnet for several weeks while looking into other things, such as getting Bitpay's Insight to work with X11.
Tonight, I wanted to check something on my private testnet and when I launched the wallet, it crashed with that assertion fault many altcoins have at launch and where they told you to delete the whole shebang except for wallet.dat:

Code:
Wallets/xyzcoin/xyzcoin-qt -conf=home/akira/.xyzcoin/xyzcoinTestnet.conf -datadir=/home/akira/.xyzcoin/testnet-1/ -testnet=1 -irc=0 -dnsseed=0
xyzcoin-qt: src/kernel.cpp:372: unsigned int GetStakeModifierChecksum(const CBlockIndex*): Assertion `pindex->pprev || pindex->GetBlockHash() == (!fTestNet ? hashGenesisBlock : hashGenesisBlockTestNet)' failed.
Aborted

I could salvage it by running this command instead of deleting everything:
Code:
Wallets/xyzcoin/xyzcoin-qt -conf=home/akira/.xyzcoin/xyzcoinTestnet.conf -datadir=/home/akira/.xyzcoin/testnet-1/ -testnet=1 -irc=0 -dnsseed=0 -loadblock=/home/akira/.xyzcoin/testnet-1/blk0001.dat 
The wallet load the blocks, then closes without my intervention. After relaunching it with the first command, everything is up & running.

What would cause GetStakeModifierChecksum to fail? The hash on May 1 is still the same on June 1, so it should be able to process that assert command correctly?

Is there an altcoin that actually solved it? From what I could find, the crash is something first introduced by Peercoin, which is a serious crypto.
sr. member
Activity: 411
Merit: 252
May 01, 2015, 04:46:49 AM
#19
well i must confess i couldnt derive any information from this testnest forum thank you a more simplified version would do
In what way would you want to see this simplified? I don't think it can be simplified? I dived into the code and try to figure out things by tinkering with it.
@Yarkol: I found out for the alerts on my testnet Smiley
It's not the client version but effectively the protocol version as mentionned in Bitcoin's alert_test.
newbie
Activity: 14
Merit: 0
April 18, 2015, 06:20:54 AM
#18
well i must confess i couldnt derive any information from this testnest forum thank you a more simplified version would do
sr. member
Activity: 411
Merit: 252
April 17, 2015, 02:30:14 PM
#17
Thanks you for explaining Smiley
If I understand it correctly, it means that I have to make the sum of

static const int CLIENT_VERSION =
                           1000000 * CLIENT_VERSION_MAJOR
                         +   10000 * CLIENT_VERSION_MINOR
                         +     100 * CLIENT_VERSION_REVISION
                         +       1 * CLIENT_VERSION_BUILD;


Which for clients v1.0.0.0 up to v1.1.0.0 would mean that the values of these variables are 1000000 and 10100000?
I created a new keypair for the testnet to try it out. I'm sure that part of the equation is correct.
legendary
Activity: 996
Merit: 1013
April 17, 2015, 09:47:32 AM
#16
The min-max-versions are for client version. Protocol version
is attached automatically. Just by typing sendalert gives
you info about the variables.

Testnet and mainnet use different keypairs.
sr. member
Activity: 411
Merit: 252
April 17, 2015, 08:00:54 AM
#15
Today I took a look at the alert system and wanted to try it on my local tesnet.
For this exercise I generated a new key pair and took a look at the sendalert command. I struggled with minversion and maxversion first, not realizing it needs an interger value instead of string.

I finally figured it out and issued this command:

Code:
sendalert "Alert Message Test" "3082011302010104202ae345b4eb41db61fcb7aa8684a75e77386ca8c0861e4dde2dc200664017fb89a081a53081a2020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010704410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a144034200041b7d83afec586c91ac96a7a43aea2e1c7803bd6506c50f0658611908053a4198d8e1bc5278a57cc2866e0a2dad24feab40bb9efe8c986dc51ecec67f7e104c69" 60000 60000 1 1

Which returned the following:
Code:
{
"strStatusBar" : "Alert Message Test",
"nVersion" : 60013,
"nMinVer" : 60000,
"nMaxVer" : 60000,
"nPriority" : 1,
"nID" : 1
}

That looks okay, except for the nVersion being higher than nMaxVer:-X
And unfortunately for me, I don't see the message being propagated on the testnet. It's not bound to a block. I should be able to see the alert were it the that I used a higher nMaxVer, right? In the status bar of the QT client it's not visible and when issuing getinfo in the debug console, I can't see it either.

My guess is that I indeed made a mistake with nMinVer and nMaxVer.
What version does this value actually corresponds to? The protocol version or client version?

in version.h I can find different versions:
Code:
//
// client versioning
//

static const int CLIENT_VERSION =
                           1000000 * CLIENT_VERSION_MAJOR
                         +   10000 * CLIENT_VERSION_MINOR
                         +     100 * CLIENT_VERSION_REVISION
                         +       1 * CLIENT_VERSION_BUILD;

//
// network protocol versioning
//

static const int PROTOCOL_VERSION = 60013;

// earlier versions not supported as of Feb 2012, and are disconnected
static const int MIN_PROTO_VERSION = 209;

// nTime field added to CAddress, starting with this version;
// if possible, avoid requesting addresses nodes older than this
static const int CADDR_TIME_VERSION = 31402;

// only request blocks from nodes outside this range of versions
static const int NOBLKS_VERSION_START = 60002;
static const int NOBLKS_VERSION_END = 60006;

// BIP 0031, pong message, is enabled for all versions AFTER this one
static const int BIP0031_VERSION = 60000;

// "mempool" command, enhanced "getdata" behavior starts with this version:
static const int MEMPOOL_GD_VERSION = 60002;

My first though was to retry the command, but raising nMaxVer to 60013.
Instead of issuing an alert, it gives me and error:

Code:
sendalert "ALERT ALERT" 
"3082011302010104202ae345b4eb41db61fcb7aa8684a75e77386ca8c0861e4dde2dc200664017fb89a081a53081a2020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010704410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a144034200041b7d83afec586c91ac96a7a43aea2e1c7803bd6506c50f0658611908053a4198d8e1bc5278a57cc2866e0a2dad24feab40bb9efe8c986dc51ecec67f7e104c69"
60000 60013 10 2 1

Failed to process alert.
(code -1)

I'm a little confused here. Am I overseeing something?
sr. member
Activity: 411
Merit: 252
April 15, 2015, 02:46:34 PM
#14
I think "timestamp too early" problem is PoS problem. So Bitcoin won't be affected due to this.

[...]

NB: I am a newb to these things.

I'm no expert either. This is like the first code I see since more than 8 years. I completely wasted my degree in computer science for other interests that didn't turn out to be career boosters at all, but that's another story Wink

I'm getting very curious about how things work and I try to get some understanding. Even if it's far above my own level of comprehension, I give it a try :p
That being said, the link you gave me is an interesting post about this. I did look further and found out that this is not only a test run on POS coins. Bitcoin also has this check around lines 2559-2562 in main.cpp:

Code:
   // Check timestamp against prev
    if (block.GetBlockTime() <= pindexPrev->GetMedianTimePast())
        return state.Invalid(error("%s: block's timestamp is too early", __func__),
                             REJECT_INVALID, "time-too-old");

I've also found coins, such as Nimbus, where for some reason they decided to comment out this check for POW and POS. This is apparently not a very good idea. Even bitcoin has newer blocks with earlier timestamps, which goes in against the logic. The protocol is designed to reject them.

I found this example on stackexchange:
Block #180966 with timestamp "2012-05-20 23:02:53" >> http://blockchain.info/block-height/180966
Block #180967 with timestamp "2012-05-20 23:02:13" >> http://blockchain.info/block-height/180967

This here ("Timejacking & Bitcoin") is an interesting article about timestamps and possible exploits if
not being taken care of correctly. Thus, removing the check is a no-go. Did nimbus ever block chain problems by ignoring the timestamp check? That's a coin I didn't bother mining last year.

Stackexchange user Chris Moore summarized it as
No, but X11 implementation requires an external miner.
Okay. That explains why it didn't work ^^"
legendary
Activity: 996
Merit: 1013
April 15, 2015, 11:59:21 AM
#13

I've finally managed to get it going. The miner in the wallet itself didn't do anything with gen=1.
I believe that at some point, cpu mining with the wallet was disabled in bitcoin core, right? Thus any altcoin forking altcoins based on a bitcoin core release after disabling the miner will of course not mine at all.

No, but X11 implementation requires an external miner.
hero member
Activity: 560
Merit: 509
I prefer Zakir over Muhammed when mentioning me!
April 15, 2015, 11:56:13 AM
#12
I think "timestamp too early" problem is PoS problem. So Bitcoin won't be affected due to this.

From https://github.com/Earlz/coinreviews/blob/master/miraclecoin.txt:

Code:
-    double nCorTried = sqrt(nTried) * (100.0 - nUnkBias);
-    double nCorNew = sqrt(nNew) * nUnkBias;
+    double nCorTried = sqrt(static_cast(nTried)) * (100.0 - nUnkBias);
+    double nCorNew = sqrt(static_cast(nNew)) * nUnkBias;

-    loop
+    INFINITE_LOOP


this is unusual
+unsigned int nStakeMinAge = 0;
+unsigned int nStakeMaxAge = 60 * 60 * 24 * 90; //90d

...wat. Why are the names commented out like that. Sure, it's legal C++ and all.. but why!?
int64 CTransaction::GetMinFee(unsigned int /*nBlockSize*/, bool /*fAllowFree*/,
                              enum GetMinFee_mode mode, unsigned int /*nBytes*/) const


looks safe but weird that things are moved around. This is probably from being cloned from CLOAK which modified this stuff
@@ -2006,10 +1958,6 @@ bool CBlock::CheckBlock(bool fCheckPOW, bool fCheckMerkleRoot) const
     if (fCheckPOW && IsProofOfWork() && !CheckProofOfWork(GetHash(), nBits))
         return DoS(50, error("CheckBlock() : proof of work failed"));
 
-    // Check timestamp
-    if (GetBlockTime() > GetAdjustedTime() + nMaxClockDrift)
-        return error("CheckBlock() : block timestamp too far in the future");
-
     // First transaction must be coinbase, the rest must not be
     if (vtx.empty() || !vtx[0].IsCoinBase())
         return DoS(100, error("CheckBlock() : first tx is not coinbase"));
@@ -2026,14 +1974,6 @@ bool CBlock::CheckBlock(bool fCheckPOW, bool fCheckMerkleRoot) const
     if (IsProofOfStake() && (vtx[0].vout.size() != 1 || !vtx[0].vout[0].IsEmpty()))
         return error("CheckBlock() : coinbase output not empty for proof-of-stake block");
 
-    // Check coinbase timestamp
-    if (GetBlockTime() > (int64)vtx[0].nTime + nMaxClockDrift)
-        return DoS(50, error("CheckBlock() : coinbase timestamp is too early"));
-
-    // Check coinstake timestamp
-    if (IsProofOfStake() && !CheckCoinStakeTimestamp(GetBlockTime(), (int64)vtx[1].nTime))
-        return DoS(50, error("CheckBlock() : coinstake timestamp violation nTimeBlock=%"PRI64d" nTimeTx=%u", GetBlockTime(), vtx[1].nTime));
-

...
-    // Check timestamp against prev
-    if (GetBlockTime() <= pindexPrev->GetMedianTimePast() || GetBlockTime() + nMaxClockDrift < pindexPrev->GetBlockTime())
-        return error("AcceptBlock() : block's timestamp is too early");
+    // Check timestamp
+    if (GetBlockTime() > GetAdjustedTime() + GetMaxClockDrift(nHeight))
+        return error("AcceptBlock() : block timestamp too far in the future");
+
+    // Check coinbase timestamp
+    if (GetBlockTime() > (int64)vtx[0].nTime + GetMaxClockDrift(nHeight))
+        return DoS(50, error("AcceptBlock() : coinbase timestamp is too early"));


This maybe different from yours but this might help you:

Think that 15 min stake time tolerance might be breaking it (guess you changed the FutureDrift for this - can't verify because the source code does not reflect the most recent change yet).
So with regards to new testers, we might have to include a temporary condition to skip this check for blocks older than a certain threshold. I can play around with this tomorrow when I've got a fresh head and time on my hands.

---

Yep, thats a good catch, I changed the future drift and past drift back to the original 15 mins, when I thought that the kernal coinstake calculation was either empty or invalid, and also the drift seems to affect the mins left to next stake.  So that ended up breaking clients who already accepted drifted blocks.  Im going to add the grandfather up to 5000 first before I ask everyone to reset the chain and we'll see how this goes...
I did erase my local chain and choked on the same block.... Testing...

NB: I am a newb to these things.
sr. member
Activity: 411
Merit: 252
April 15, 2015, 11:23:00 AM
#11
Hmmm... I noticed something odd with the testnet.

I let the clients on both nodes run, but shut down cpuminer while I was away. In the meantime no new block was created (last POW block is past 20k)
When I got back, I restarted the miner and instead of nicely finding new blocks, every candidate got rejected:

Code:
[2015-04-15 17:38:28] 2 miner threads started, using 'x11' algorithm.
[2015-04-15 17:38:29] Current block is 131
[2015-04-15 17:38:29] Switching to getwork, gbt version 6
[2015-04-15 17:38:39] CPU #1: 25.31 kH/s
[2015-04-15 17:38:41] CPU #0: 25.85 kH/s
[2015-04-15 17:38:41] accepted: 0/1 (0.00%), 51.16 kH/s nooooo
[2015-04-15 17:38:45] CPU #0: 21.33 kH/s
[2015-04-15 17:38:45] CPU #1: 26.15 kH/s
[2015-04-15 17:38:47] accepted: 0/2 (0.00%), 47.48 kH/s nooooo
[2015-04-15 17:38:48] CPU #0: 22.56 kH/s
[2015-04-15 17:38:48] CPU #1: 26.76 kH/s
[2015-04-15 17:38:49] accepted: 0/3 (0.00%), 49.31 kH/s nooooo
[2015-04-15 17:38:55] CPU #0: 25.41 kH/s

And debug.log shows a CheckWork() ERROR: CheckBlock() : coinbase timestamp is too early

Code:
CheckWork() : new proof-of-work block found  
  hash: 0000224bd0ee0e7dab97efe9499ebabd32dadc388879b694a7d0d70a479305e5  
target: 000027d434000000000000000000000000000000000000000000000000000000
CBlock(hash=0000224bd0ee0e7dab97efe9499ebabd32dadc388879b694a7d0d70a479305e5, ver=6, hashPrevBlock=00001eef81c1db86583a139ced70a6863676f577a3448001dccc05d3fb35ee77, hashMerkleRoot=c9ba970b28c5784b28e29180afaa99d76de33d37854e293b895c6ab0e3e56c07, nTime=1429113207, nBits=1e27d434, nNonce=1746469248, vtx=1, vchBlockSig=)
  Coinbase(hash=c9ba970b28, nTime=1429106569, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, 4294967295), coinbase 028300028400)
    CTxOut(nValue=1500.00, scriptPubKey=OP_DUP OP_HASH160 09bed4b06f7b5ec59a025415d0268ee5ec9af74c OP_EQUALVERIFY OP_CHECKSIG)
  vMerkleTree: c9ba970b28
generated 1500.00
Blocktime: 1429113207 --- vtx[0].nTime: 1429110169
ERROR: CheckBlock() : coinbase timestamp is too early
ERROR: ProcessBlock() : CheckBlock FAILED
ERROR: CheckWork() : ProcessBlock, block not accepted


date -d@1429113207 (Blocktime)
Wed Apr 15 17:53:27 CEST 2015
date -d@1429110169 (vtx[0].nTime)
Wed Apr 15 17:02:49 CEST 2015

When I couldn't generate the genesis block at first, I got this coinbase timestamp is too early error too. When stuyding the source code, I saw that it checked ntime against ntime + past/future drift, constants set to +10 minutes and -10 minutes. I changed it to 1 hour:

Code:
inline int64_t PastDrift(int64_t nTime)   { return nTime - 1 * 60 * 60; } // up to 1 hour from the past
inline int64_t FutureDrift(int64_t nTime) { return nTime + 1 * 60 * 60; } // up to 1 hour from the future

After realising that the block.nTime was somewhere in 2014, there was no way it would ever create a genesis bloc for the testnet, hence creating a new pszTimestamp for it.

Anyway, now the miner can't find new blocks, because me shutting it down for 2 hours is double the pastDrift I specified.
Before deleting the testnet to restart, I shut down the two clients and restarted them. Tadaaa! Mining resumed and blocks are created.

What are real life implications of such behaviour? If the hypothesis that no one would mine a crypto currency for a while its main net, does this automatically mean that this crypto currency is dead and every single coin ever mined becomes useless as in no transactions possible, nor mining being ever possible again?

I can't imagine that if such thing would happen to Bitcoin, that no new bitcoins could be mined again, ever? I don't believe it's feasible to make every person or device running a wallet shut down, just to "reboot" it for mining. This can't be the meaning of it all? Or is it intentional and a safeguard intended to shutdown a block chain that becomes inactive?
sr. member
Activity: 411
Merit: 252
April 15, 2015, 08:07:05 AM
#10

Glad to hear it is conmecting now.

How does it proceed now? Does one of the clients have to "mine" the genesis block to get the testnet blockchain started? Without this, there won't be a new block on the network right?

It lookse like you have both PoS ans PoW. AFAIK to go further, you will have to make a transaction and that's how new block is found and new coins are minted. I am not very familar with PoS but I think keeping the wallet open after sending transaction can mint nee coins or you can mine with your CPU/GPU.

Let's say it works like above, what happens when I shut down both clients? Does that block chain simply dies or does it "resume" as soon as 1 or more clients are connected to each other?

Will resume AFAIK.

IMHO you could announce in altcoins amd tell them this is for educational purpose. You may get more miners and peers.

Thank you for your reply Muhammed Zakir.

I've finally managed to get it going. The miner in the wallet itself didn't do anything with gen=1.
I believe that at some point, cpu mining with the wallet was disabled in bitcoin core, right? Thus any altcoin forking altcoins based on a bitcoin core release after disabling the miner will of course not mine at all.

I tried Tanguy Pruvot's cpuminer-multi and Tadaaaaa! It started mining testnet blocks. I'll let it run for a while to see when they mature & get confirmed.

Stopping the mining stop the block generation.
Shutdown & relaunch the clients resumes the operations once cpuminer start crunching the number. It's a very interesting concept to witness from close-by.

Code:
{
    "version" : "v1.1.0.0",
    "protocolversion" : 60013,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "newmint" : 17.00000000,
    "stake" : 0.00000000,
    "blocks" : 17,
    "timeoffset" : 0,
    "moneysupply" : 17.00000000,
    "connections" : 1,
    "proxy" : "",
    "ip" : "0.0.0.0",
    "difficulty" : {
        "proof-of-work" : 0.00004356,
        "proof-of-stake" : 0.00001526
    },
    "testnet" : true,
    "keypoololdest" : 1429042310,
    "keypoolsize" : 101,
    "paytxfee" : 0.00001000,
    "mininput" : 0.00000000,
    "errors" : ""
}

Code:
./cpuminer -a x11 -o http://127.0.0.1:33551 -u FirstInstance -p FirstInstancePassword --coinbase-addr=n1YYCSN2Y6qE9oxKvDj3ZU8u7Na42WJMDR
** cpuminer-multi 1.1-git by Tanguy Pruvot (tpruvot@github) **
BTC donation address: 1FhDPLPpw18X4srecguG3MxJYe4a1JsZnd

[2015-04-15 15:05:01] 2 miner threads started, using 'x11' algorithm.
[2015-04-15 15:05:02] Current block is 18
[2015-04-15 15:05:02] Switching to getwork, gbt version 6
[2015-04-15 15:05:06] CPU #0: 25.58 kH/s
[2015-04-15 15:05:08] CPU #0: 25.92 kH/s
[2015-04-15 15:05:08] accepted: 1/1 (100.00%), 25.92 kH/s yes!
[2015-04-15 15:05:09] CPU #0: 23.79 kH/s
[2015-04-15 15:05:11] x11 block 19, diff 0.00
[2015-04-15 15:05:11] CPU #1: 25.57 kH/s
[2015-04-15 15:05:14] CPU #0: 23.53 kH/s
[2015-04-15 15:05:16] CPU #0: 25.09 kH/s
[2015-04-15 15:05:16] CPU #1: 26.27 kH/s
[2015-04-15 15:05:17] accepted: 2/2 (100.00%), 51.36 kH/s yes!
[2015-04-15 15:05:20] x11 block 20, diff 0.00
[2015-04-15 15:05:20] CPU #1: 25.45 kH/s
[2015-04-15 15:05:21] CPU #1: 23.13 kH/s
[2015-04-15 15:05:21] CPU #0: 23.84 kH/s

Is there any program besides Rational Rose (don't have it) that can generate class diagrams, activity and sequence diagrams for bitcoin's code? Many people don't like diagrams, and I could find any yet, but I think they can be of value to understand how things work and are related to each other. The source code for bitcoin core (altcoins) are least to say... daunting if you need to gain understanding of how things work <("^_^)
hero member
Activity: 560
Merit: 509
I prefer Zakir over Muhammed when mentioning me!
April 15, 2015, 07:22:58 AM
#9
Ouch >_<
I messed up. Looks like the firewall is enabled by default. I opened port 33550 on both ends with

Code:
sudo /usr/sbin/iptables -I INPUT -p tcp -m tcp --dport 33550 -j ACCEPT

And got them to see each other:

Code:
{
    "version" : "v1.1.0.0",
    "protocolversion" : 60013,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "newmint" : 0.00000000,
    "stake" : 0.00000000,
    "blocks" : 0,
    "timeoffset" : 0,
    "moneysupply" : 0.00000000,
    "connections" : 1,
    "proxy" : "",
    "ip" : "0.0.0.0",
    "difficulty" : {
        "proof-of-work" : 0.00001526,
        "proof-of-stake" : 0.00001526
    },
    "testnet" : true,
    "keypoololdest" : 1429042310,
    "keypoolsize" : 101,
    "paytxfee" : 0.00001000,
    "mininput" : 0.00000000,
    "errors" : ""
}

Glad to hear it is conmecting now.

How does it proceed now? Does one of the clients have to "mine" the genesis block to get the testnet blockchain started? Without this, there won't be a new block on the network right?

It lookse like you have both PoS ans PoW. AFAIK to go further, you will have to make a transaction and that's how new block is found and new coins are minted. I am not very familar with PoS but I think keeping the wallet open after sending transaction can mint nee coins or you can mine with your CPU/GPU.

Let's say it works like above, what happens when I shut down both clients? Does that block chain simply dies or does it "resume" as soon as 1 or more clients are connected to each other?

Will resume AFAIK.

IMHO you could announce in altcoins amd tell them this is for educational purpose. You may get more miners and peers.
legendary
Activity: 3248
Merit: 1070
April 15, 2015, 07:21:53 AM
#8
Ouch >_<
I messed up. Looks like the firewall is enabled by default. I opened port 33550 on both ends with

Code:
sudo /usr/sbin/iptables -I INPUT -p tcp -m tcp --dport 33550 -j ACCEPT

And got them to see each other:

Code:
{
    "version" : "v1.1.0.0",
    "protocolversion" : 60013,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "newmint" : 0.00000000,
    "stake" : 0.00000000,
    "blocks" : 0,
    "timeoffset" : 0,
    "moneysupply" : 0.00000000,
    "connections" : 1,
    "proxy" : "",
    "ip" : "0.0.0.0",
    "difficulty" : {
        "proof-of-work" : 0.00001526,
        "proof-of-stake" : 0.00001526
    },
    "testnet" : true,
    "keypoololdest" : 1429042310,
    "keypoolsize" : 101,
    "paytxfee" : 0.00001000,
    "mininput" : 0.00000000,
    "errors" : ""
}

How does it proceed now? Does one of the clients have to "mine" the genesis block to get the testnet blockchain started? Without this, there won't be a new block on the network right? Let's say it works like above, what happens when I shut down both clients? Does that block chain simply dies or does it "resume" as soon as 1 or more clients are connected to each other?

so it was the firewall at the end?

it's correct you need the genesis block first to start the chain, and if you shut down the client it should re-synch until the genesis block, to be sure you could try it, i don't think something bad will happen anyway
sr. member
Activity: 411
Merit: 252
April 15, 2015, 06:57:44 AM
#7
Ouch >_<
I messed up. Looks like the firewall is enabled by default. I opened port 33550 on both ends with

Code:
sudo /usr/sbin/iptables -I INPUT -p tcp -m tcp --dport 33550 -j ACCEPT

And got them to see each other:

Code:
{
    "version" : "v1.1.0.0",
    "protocolversion" : 60013,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "newmint" : 0.00000000,
    "stake" : 0.00000000,
    "blocks" : 0,
    "timeoffset" : 0,
    "moneysupply" : 0.00000000,
    "connections" : 1,
    "proxy" : "",
    "ip" : "0.0.0.0",
    "difficulty" : {
        "proof-of-work" : 0.00001526,
        "proof-of-stake" : 0.00001526
    },
    "testnet" : true,
    "keypoololdest" : 1429042310,
    "keypoolsize" : 101,
    "paytxfee" : 0.00001000,
    "mininput" : 0.00000000,
    "errors" : ""
}

How does it proceed now? Does one of the clients have to "mine" the genesis block to get the testnet blockchain started? Without this, there won't be a new block on the network right? Let's say it works like above, what happens when I shut down both clients? Does that block chain simply dies or does it "resume" as soon as 1 or more clients are connected to each other?
hero member
Activity: 560
Merit: 509
I prefer Zakir over Muhammed when mentioning me!
April 15, 2015, 06:17:21 AM
#6
Yes, I also tried running the client in the VM on 33552 instead of 33550. Same result.

Try 18333. You have enable port forwarding?

The rpcuser and rpcpassword shouldn't matter. They should connect to each other via peer-to-peer 192.168.0.163:33550<->192.168.0.206:33550 for example, and not via rpc.

You are right. I messed up.
sr. member
Activity: 411
Merit: 252
April 15, 2015, 06:03:19 AM
#5
Have you tried using another port?

P.S. Shouldn't both use same rpcusername and rpcpassword?
Yes, I also tried running the client in the VM on 33552 instead of 33550. Same result.
The rpcuser and rpcpassword shouldn't matter. They should connect to each other via peer-to-peer 192.168.0.163:33550<->192.168.0.206:33550 for example, and not via rpc.
hero member
Activity: 560
Merit: 509
I prefer Zakir over Muhammed when mentioning me!
April 15, 2015, 05:58:07 AM
#4
Have you tried using another port?

P.S. Shouldn't both use same rpcusername and rpcpassword?
sr. member
Activity: 411
Merit: 252
April 15, 2015, 05:55:30 AM
#3
Hello Amph. Both host and guest are Linux distributions. The host runs OpenSUSE 13.2 and the guest runs Mint 17.1. I built my VM with VMWare Workstation.
When I start a 2nd VM based on Ubuntu, which I used to play with bitcoin-abe, I have no problem accessing apache2 on port 80 from both the host and the two VMs.
Could it fail because the wallets detect my WAN IP?
legendary
Activity: 3248
Merit: 1070
April 15, 2015, 05:35:03 AM
#2
what virtual machine are you using? i think the problem is related to the firewall(i presume windows right?), you should allow the client in the VM firewall, as a public and private
sr. member
Activity: 411
Merit: 252
April 15, 2015, 05:09:13 AM
#1
Hello

First of all, don't worry. I don't intend to launch the 10000th scam coin or any coin in general. Instead, I would rather gain understanding of the inner workings of crypto currency.

I'm experimenting with an X11 POW/POS coin that so far had no testnet at all to start with. Reading through documentation to be found here and on Github, I've managed to apply the changes required to the source code. I successfully created a Genesis block and now I try to kick off the testnet between my PC running OpenSUSE 13.2 and a virtual machine running Mint 17.1.

The genesis block for the testnet looks like this
Code:
{
    "hash" : "00000d4d0549912423730a89e05b8f096591d32795b1612a0abd5c3541904ddf",
    "confirmations" : 1,
    "size" : 155,
    "height" : 0,
    "version" : 1,
    "merkleroot" : "a19abd6632650bde37a3feb35eef8ac6d1ffb70d5ce180b5e68b9eea13cb23ae",
    "mint" : 0.00000000,
    "time" : 1429024276,
    "nonce" : 203625,
    "bits" : "1f00ffff",
    "difficulty" : 0.00001526,
    "blocktrust" : "10001",
    "chaintrust" : "10001",
    "flags" : "proof-of-work stake-modifier",
    "proofhash" : "00000d4d0549912423730a89e05b8f096591d32795b1612a0abd5c3541904ddf",
    "entropybit" : 1,
    "modifier" : "0000000000000000",
    "modifierchecksum" : "0e00670b",
    "tx" : [
        "a19abd6632650bde37a3feb35eef8ac6d1ffb70d5ce180b5e68b9eea13cb23ae"
    ]
}

The genesis block on the actual mainnet looks this:
Code:
{
    "hash" : "00000c639b0fbf250ba63c6ef2952dbb44bb1051324a27383b8a56fb833d8137",
    "confirmations" : 1403349,
    "size" : 155,
    "height" : 0,
    "version" : 1,
    "merkleroot" : "18bf53ed0bbbc417c8e2d7993294dba71e1ba10697c9289c617ee02108bb197c",
    "mint" : 0.00000000,
    "time" : 1402346011,
    "nonce" : 1912748,
    "bits" : "1e0fffff",
    "difficulty" : 0.00024414,
    "blocktrust" : "100001",
    "chaintrust" : "100001",
    "nextblockhash" : "0000014e0a7c56f23135b52a5af015a9b89266c4899d66039d65b0f80cc969a8",
    "flags" : "proof-of-work stake-modifier",
    "proofhash" : "00000c639b0fbf250ba63c6ef2952dbb44bb1051324a27383b8a56fb833d8137",
    "entropybit" : 1,
    "modifier" : "0000000000000000",
    "modifierchecksum" : "0e00670b",
    "tx" : [
        "18bf53ed0bbbc417c8e2d7993294dba71e1ba10697c9289c617ee02108bb197c"
    ]
}
I'm confident this part for the testnet is alright.

The next step is "start" this testnet and actually create new blocks. To do so, I'm using my computer and a virtual machine.
On my computer with IP 192.168.0.163, I run the headless daemon of the wallet with the following configuration:

Code:
server=1
rpcallowip=192.168.0.*
listen=1
rpcuser=FirstInstance
rpcpassword=FirstInstancePassword
port=33550
rpcport=33551
gen=1
testnet=1
noirc=1

The virtual machine has access to my LAN using a bridge and received the IP 192.168.0.206. Both machines can see each other. This VM runs the QT wallet and is configured as
Code:
server=1
rpcallowip=192.168.0.*
rpcuser=SecondInstance
rpcpassword=SecondInstancePassword
port=33550
rpcport=33551
gen=1
testnet=1
noirc=1
connect=192.168.0.163:33550

I first start the daemon on the physical machine, followed by the QT client on the VM.

Unfortunately, the QT client (headless has the same effect) isn't able to connect to its peer on the physical machine and blocks stay on 0.
Code:
Opened LevelDB successfully
LoadBlockIndex(): hashBestChain=00000d4d054991242373  height=0  trust=65537  date=04/14/2015 15:11:16
LoadBlockIndex(): synchronized checkpoint 00000d4d0549912423730a89e05b8f096591d32795b1612a0abd5c3541904ddf
Verifying last 0 blocks at level 1
 block index               4ms
Loading wallet...
nFileVersion = 1010000
Keys: 101 plaintext, 0 encrypted, 101 w/ metadata, 101 total
 wallet                  266ms
Loading addresses...
Loaded 0 addresses from peers.dat  0ms
mapBlockIndex.size() = 1
nBestHeight = 0
setKeyPool.size() = 100
mapWallet.size() = 0
mapAddressBook.size() = 1
ThreadRPCServer started
DNS seeding disabled
Done loading
ThreadIRCSeed exited
refreshWallet
ThreadSocketHandler started
ThreadOpenAddedConnections started
ThreadOpenAddedConnections exited
ThreadOpenConnections started
trying connection 192.168.0.163:33550 lastseen=0,0hrs
ThreadMessageHandler started
ThreadStakeMiner started
Flushed 0 addresses to peers.dat  2ms
ipcThread started
connection timeout
trying connection 192.168.0.163:33550 lastseen=0,0hrs
connection timeout
trying connection 192.168.0.163:33550 lastseen=0,0hrs
connection timeout
trying connection 192.168.0.163:33550 lastseen=0,0hrs
connection timeout

On the physical machine, I return getinfo every 30 seconds (using "watch")
Code:
{
    "version" : "v1.1.0.0",
    "protocolversion" : 60013,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "newmint" : 0.00000000,
    "stake" : 0.00000000,
    "blocks" : 0,
    "timeoffset" : 0,
    "moneysupply" : 0.00000000,
    "connections" : 0,
    "proxy" : "",
    "ip" : "0.0.0.0",
    "difficulty" : {
        "proof-of-work" : 0.00001526,
        "proof-of-stake" : 0.00001526
    },
    "testnet" : true,
    "keypoololdest" : 1429042310,
    "keypoolsize" : 101,
    "paytxfee" : 0.00001000,
    "mininput" : 0.00000000,
    "errors" : ""
}

What am I overseeing to make this work? I'm don't think that I need to open any port with iptables on the physical machine or do portforwarding, since it's all on LAN.
Although, I'm concerned about "ip" : "0.0.0.0",. The same client on mainnet gives returns my public IP. Should I bind the client on the physical machine to a specific IP?
Jump to: