Private testnet between PC and VM

[Hoshimaru]

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?

[Amph]

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

[Hoshimaru]

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?

[Muhammed Zakir]

Have you tried using another port?

P.S. Shouldn't both use same rpcusername and rpcpassword?

[Hoshimaru]

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.

[Muhammed Zakir]

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.

[Hoshimaru]

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?

[Amph]

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

[Muhammed Zakir]

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.

[Hoshimaru]

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 <("^_^)

[Hoshimaru]

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?

[Muhammed Zakir]

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<double>(nTried)) * (100.0 - nUnkBias);
+    double nCorNew = sqrt(static_cast<double>(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.

[YarkoL]

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.

[Hoshimaru]

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

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

The protocol rejects blocks with a timestamp earlier than the median of the timestamps from the previous 11 blocks or later than 2 hours after the current network time. Any other timestamp is acceptable. Note that 'network time' may differ from the actual time, since the bitcoin network attempts to correct for incorrect clock settings by taking the median of the time reported by all connected peers as the network time.

I think it makes sense. After this 2 hours, of not mining, the last block known by the two clients was indeed too old to be accepted. Restarting the clients, gave them the new and actual time, after which mining could be resumed as it met the time requirements again.
I did turn of mining for ~1 hour, and both cpuminers could proceed where they left of.

To confirm this time on the network requirement, I will stop mining again for 2 hours or more (time to watch a movie ;-) or go for an evening walk) and see if the blocks will be rejected again. If they do, I'll restart one of the two clients and see what happens. I think both miners will resume operation as soon as one of the clients refreshes its timestamp on the testnet network.

No, but X11 implementation requires an external miner.

Okay. That explains why it didn't work ^^"

[Hoshimaru]

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?

[YarkoL]

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.

[Hoshimaru]

Thanks you for explaining
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.

[sikaxchange]

well i must confess i couldnt derive any information from this testnest forum thank you a more simplified version would do

[Hoshimaru]

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
It's not the client version but effectively the protocol version as mentionned in Bitcoin's alert_test.

[Hoshimaru]

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.