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

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:


I could salvage it by running this command instead of deleting everything:
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.

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.

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

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.

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.

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:


Which returned the following:

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:

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


I'm a little confused here. Am I overseeing something?

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:


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
Okay. That explains why it didn't work ^^"

No, but X11 implementation requires an external miner.

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:



This maybe different from yours but this might help you:


NB: I am a newb to these things.

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:


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



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:


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?

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.



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

Glad to hear it is conmecting now.


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.


Will resume AFAIK.

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

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

Ouch >_<
I messed up. Looks like the firewall is enabled by default. I opened port 33550 on both ends with


And got them to see each other:


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?

Try 18333. You have enable port forwarding?


You are right. I messed up.

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.

Have you tried using another port?

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

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?

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

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

The genesis block on the actual mainnet looks this:
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:


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

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.

On the physical machine, I return getinfo every 30 seconds (using "watch")

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?