Title: Private testnet between PC and VM Post by: Hoshimaru on April 15, 2015, 10:09:13 AM 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: { The genesis block on the actual mainnet looks this: Code: { 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 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 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 On the physical machine, I return getinfo every 30 seconds (using "watch") Code: { 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? Title: Re: Private testnet between PC and VM Post by: Amph on April 15, 2015, 10:35:03 AM 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
Title: Re: Private testnet between PC and VM Post by: Hoshimaru on April 15, 2015, 10:55:30 AM 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? Title: Re: Private testnet between PC and VM Post by: Muhammed Zakir on April 15, 2015, 10:58:07 AM Have you tried using another port?
P.S. Shouldn't both use same rpcusername and rpcpassword? Title: Re: Private testnet between PC and VM Post by: Hoshimaru on April 15, 2015, 11:03:19 AM Have you tried using another port? Yes, I also tried running the client in the VM on 33552 instead of 33550. Same result.P.S. Shouldn't both use same rpcusername and rpcpassword? 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. Title: Re: Private testnet between PC and VM Post by: Muhammed Zakir on April 15, 2015, 11:17:21 AM 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. Title: Re: Private testnet between PC and VM Post by: Hoshimaru on April 15, 2015, 11:57:44 AM 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: { 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? Title: Re: Private testnet between PC and VM Post by: Amph on April 15, 2015, 12:21:53 PM 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: { 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 Title: Re: Private testnet between PC and VM Post by: Muhammed Zakir on April 15, 2015, 12:22:58 PM 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: { 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. Title: Re: Private testnet between PC and VM Post by: Hoshimaru on April 15, 2015, 01:07:05 PM 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 (https://github.com/tpruvot/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: { Code: ./cpuminer -a x11 -o http://127.0.0.1:33551 -u FirstInstance -p FirstInstancePassword --coinbase-addr=n1YYCSN2Y6qE9oxKvDj3ZU8u7Na42WJMDR 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 <("^_^) Title: Re: Private testnet between PC and VM Post by: Hoshimaru on April 15, 2015, 04:23:00 PM 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. And debug.log shows a CheckWork() ERROR: CheckBlock() : coinbase timestamp is too early Code: CheckWork() : new proof-of-work block found 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 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? Title: Re: Private testnet between PC and VM Post by: Muhammed Zakir on April 15, 2015, 04:56:13 PM 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); 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. Title: Re: Private testnet between PC and VM Post by: YarkoL on April 15, 2015, 04:59:21 PM 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. Title: Re: Private testnet between PC and VM Post by: Hoshimaru on April 15, 2015, 07:46:34 PM 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 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 (http://culubas.blogspot.ca/2011/05/timejacking-bitcoin_802.html) ("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 Quote 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 ^^"Title: Re: Private testnet between PC and VM Post by: Hoshimaru on April 17, 2015, 01:00:54 PM 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: { 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: // 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" I'm a little confused here. Am I overseeing something? Title: Re: Private testnet between PC and VM Post by: YarkoL on April 17, 2015, 02:47:32 PM 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. Title: Re: Private testnet between PC and VM Post by: Hoshimaru on April 17, 2015, 07:30:14 PM 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. Title: Re: Private testnet between PC and VM Post by: sikaxchange on April 18, 2015, 11:20:54 AM well i must confess i couldnt derive any information from this testnest forum thank you a more simplified version would do
Title: Re: Private testnet between PC and VM Post by: Hoshimaru on May 01, 2015, 09:46:49 AM 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. Title: Re: Private testnet between PC and VM Post by: Hoshimaru on June 01, 2015, 09:14:29 PM 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 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 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. |