v0.10.9.x Help test RC2 forking issues

Status
Not open for further replies.
Great suggestions both - honestly at this point I'm wondering if this is a weirdness with my Arch install. I've inserted that modified iptable (set it up for -j DROP), however still seeing the same thing. When running netstat locally I see the following:
Code: 
[root@localhost .darkcoin]# netstat -tulanp | grep 0:19999
tcp        0      0 0.0.0.0:19999           0.0.0.0:*               LISTEN      787/darkcoind
tcp        0      0 10.0.0.159:34075        54.80.186.130:19999     ESTABLISHED 787/darkcoind
tcp        0      0 10.0.0.159:34035        54.80.186.130:19999     TIME_WAIT   -

However, when I run nmap (against my testnet box public IP) on my EC2 box I get the following:
Code: 
Host is up (0.048s latency).
PORT      STATE  SERVICE
9999/tcp  closed abyss
19999/tcp open   unknown
 
Well, I've had no luck starting a remote masternode. I walked away from it last night and most of today. I finally tried again, first creating a new masternode key from the local wallet so that I could be certain that it is correct. After that, I again could only start my local masternode on my ip address:
2014-06-11 04:17:15 receive version message: /Satoshi:0.9.4.11/: version 70015, blocks=17301, us=54.193.124.32:19999, them=195.23.51.99:19333, peer=194.65.106.45:50751
2014-06-11 04:17:41 dsee - Got NEW masternode entry homeip:19999
2014-06-11 04:17:41 dsee - Accepted masternode entry -1 -1

My router has tcp/udp ingoing/outgoin opened port 19999 on the machine's ip address that the local wallet is running from.

My home IP address shows up on the list, and I can not find this string in my remote debug.log: CDarkSendPool::EnableHotColdMasterNode() - Enabled!

Is nobody else having this trouble?
 
Last edited by a moderator:
snogcel said:
Any thoughts on why the following firewall config is not allowing my MN to connect?

Code: 
# Generated by iptables-save v1.4.21 on Tue Jun 10 21:34:33 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [103:15380]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -s 10.0.0.167/32 -i wlp1s0 -p tcp -m tcp --dport 55221 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A TCP -p tcp --dport 19999 -j ACCEPT
-A TCP -p tcp --dport 19998 -j ACCEPT
-A TCP -p tcp --dport 9999 -j ACCEPT
-A TCP -p tcp --dport 9998 -j ACCEPT
COMMIT
# Completed on Tue Jun 10 21:34:33 2014

darkcoind seems to be speaking with the net no problems:

Code: 
{
    "version" : 100912,
    "protocolversion" : 70018,
    "walletversion" : 60000,
    "balance" : 2000.00000000,
    "blocks" : 17494,
    "timeoffset" : 1,
    "connections" : 8,
    "proxy" : "",
    "difficulty" : 0.29036717,
    "testnet" : true,
    "keypoololdest" : 1402447671,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "mininput" : 0.00001000,
    "errors" : ""
}

However, when I attempt to masternode start I get the following: inbound port is not open. Please open it and try again. (19999 for testnet and 9999 for mainnet)
Click to expand...

Try configuring the known address like this:

masternodeaddr=MYPUBLICIP:19999

Let me know if that works for you
 
TanteStefana said:
Well, I've had no luck starting a remote masternode. I walked away from it last night and most of today. I finally tried again, first creating a new masternode key from the local wallet so that I could be certain that it is correct. After that, I again could only start my local masternode on my ip address:
2014-06-11 04:17:15 receive version message: /Satoshi:0.9.4.11/: version 70015, blocks=17301, us=54.193.124.32:19999, them=195.23.51.99:19333, peer=194.65.106.45:50751
2014-06-11 04:17:41 dsee - Got NEW masternode entry homeip:19999
2014-06-11 04:17:41 dsee - Accepted masternode entry -1 -1

My router has tcp/udp ingoing/outgoin opened port 19999 on the machine's ip address that the local wallet is running from.

My home IP address shows up on the list, and I can not find this string in my debug.log: CDarkSendPool::EnableHotColdMasterNode() - Enabled!

Is nobody else having this trouble?
Click to expand...
I will make a guide but not soon.

I think if cold wallet is used, pork checking is not needed for cold wallet.
 
eduffield said:
Try configuring the known address like this:

masternodeaddr=MYPUBLICIP:19999

Let me know if that works for you
Click to expand...

Thanks for the idea - just gave that a try but still having no luck, I'm quite baffled here. Increasingly thinking this a problem with my install and I should just go back to Ubuntu?

Code: 
[jon@localhost .darkcoin]$ darkcoind -masternodeaddr=xx.xxx.xxx.xx:19999
DarkCoin server starting
[jon@localhost .darkcoin]$ darkcoind masternode start
inbound port is not open. Please open it and try again. (19999 for testnet and 9999 for mainnet)
 
eduffield said:
Try configuring the known address like this:

masternodeaddr=MYPUBLICIP:19999

Let me know if that works for you
Click to expand...
It doesn't for me, and I don't have a firewall, just in case you're interested, LOL. Glad to see someone else is having trouble , not just me.
 
TanteStefana said:
It doesn't for me, and I don't have a firewall, just in case you're interested, LOL. Glad to see someone else is having trouble , not just me.
Click to expand...
I think it's part of port checking.
1) stand alone : port should be opened
2) local + remote : remote - start anyway, local - check if remote port is opened.
 
eduffield said:
***** MASTERNODES PLEASE UPDATE TO 10.9.12 ******

Added local port checking to make sure it's open :grin:
Click to expand...

Hi Evan,

good news: I had another round of my tcpping script on masternodes and the changes to include port checking vastly improved masternode network stability and reliability!

There are currently 70 masternodes registered in the masternode list. tcpping is delivering the following results:

Code: 
 23.20.78.184 -->seq 0: tcp response from ec2-23-20-78-184.compute-1.amazonaws.com (23.20.78.184) [open]  1.743 ms
23.22.13.31 -->seq 0: tcp response from ec2-23-22-13-31.compute-1.amazonaws.com (23.22.13.31) [open]  1.569 ms
23.23.55.5 -->seq 0: tcp response from ec2-23-23-55-5.compute-1.amazonaws.com (23.23.55.5) [open]  1.599 ms
23.242.106.27 -->seq 0: tcp response from cpe-23-242-106-27.socal.res.rr.com (23.242.106.27) [open]  93.144 ms
37.187.216.11 -->seq 0: tcp response from 11.ip-37-187-216.eu (37.187.216.11) [open]  89.159 ms
50.16.10.185 -->seq 0: tcp response from ec2-50-16-10-185.compute-1.amazonaws.com (50.16.10.185) [open]  1.716 ms
50.16.13.19 -->seq 0: tcp response from ec2-50-16-13-19.compute-1.amazonaws.com (50.16.13.19) [open]  1.728 ms
50.16.50.164 -->seq 0: tcp response from ec2-50-16-50-164.compute-1.amazonaws.com (50.16.50.164) [open]  2.091 ms
50.16.159.173 -->seq 0: tcp response from ec2-50-16-159-173.compute-1.amazonaws.com (50.16.159.173) [open]  1.816 ms
50.17.9.225 -->seq 0: tcp response from ec2-50-17-9-225.compute-1.amazonaws.com (50.17.9.225) [open]  1.994 ms
50.17.56.71 -->seq 0: tcp response from ec2-50-17-56-71.compute-1.amazonaws.com (50.17.56.71) [open]  1.991 ms
50.17.76.216 -->seq 0: tcp response from ec2-50-17-76-216.compute-1.amazonaws.com (50.17.76.216) [open]  1.633 ms
50.19.54.118 -->seq 0: tcp response from ec2-50-19-54-118.compute-1.amazonaws.com (50.19.54.118) [open]  2.716 ms
54.76.47.232 -->seq 0: no response (timeout)
54.80.118.25 -->seq 0: tcp response from ec2-54-80-118-25.compute-1.amazonaws.com (54.80.118.25) [open]  1.786 ms
54.80.186.130 -->seq 0: tcp response from ec2-54-80-186-130.compute-1.amazonaws.com (54.80.186.130) [open]  1.520 ms
54.80.217.163 -->seq 0: tcp response from ec2-54-80-217-163.compute-1.amazonaws.com (54.80.217.163) [open]  1.684 ms
54.80.221.149 -->seq 0: tcp response from ec2-54-80-221-149.compute-1.amazonaws.com (54.80.221.149) [open]  1.729 ms
54.80.248.174 -->seq 0: tcp response from ec2-54-80-248-174.compute-1.amazonaws.com (54.80.248.174) [open]  1.694 ms
54.81.150.16 -->seq 0: tcp response from ec2-54-81-150-16.compute-1.amazonaws.com (54.81.150.16) [open]  1.941 ms
54.81.244.239 -->seq 0: tcp response from ec2-54-81-244-239.compute-1.amazonaws.com (54.81.244.239) [open]  2.170 ms
54.82.237.183 -->seq 0: tcp response from ec2-54-82-237-183.compute-1.amazonaws.com (54.82.237.183) [open]  1.672 ms
54.83.143.1 -->seq 0: tcp response from ec2-54-83-143-1.compute-1.amazonaws.com (54.83.143.1) [open]  2.558 ms
54.83.151.118 -->seq 0: tcp response from ec2-54-83-151-118.compute-1.amazonaws.com (54.83.151.118) [open]  1.565 ms
54.86.103.191 -->seq 0: tcp response from ec2-54-86-103-191.compute-1.amazonaws.com (54.86.103.191) [open]  1.233 ms
54.87.101.82 -->seq 0: tcp response from ec2-54-87-101-82.compute-1.amazonaws.com (54.87.101.82) [open]  2.065 ms
54.87.121.203 -->seq 0: tcp response from ec2-54-87-121-203.compute-1.amazonaws.com (54.87.121.203) [open]  1.876 ms
54.187.152.9 -->seq 0: tcp response from ec2-54-187-152-9.us-west-2.compute.amazonaws.com (54.187.152.9) [open]  78.089 ms
54.197.189.67 -->seq 0: tcp response from ec2-54-197-189-67.compute-1.amazonaws.com (54.197.189.67) [open]  1.702 ms
54.197.213.80 -->seq 0: tcp response from ec2-54-197-213-80.compute-1.amazonaws.com (54.197.213.80) [open]  1.682 ms
54.198.109.108 -->seq 0: tcp response from ec2-54-198-109-108.compute-1.amazonaws.com (54.198.109.108) [open]  1.556 ms
54.198.145.174 -->seq 0: tcp response from ec2-54-198-145-174.compute-1.amazonaws.com (54.198.145.174) [open]  1.557 ms
54.198.191.99 -->seq 0: tcp response from ec2-54-198-191-99.compute-1.amazonaws.com (54.198.191.99) [open]  1.561 ms
54.198.252.150 -->seq 0: tcp response from ec2-54-198-252-150.compute-1.amazonaws.com (54.198.252.150) [open]  1.608 ms
54.203.217.224 -->seq 0: no response (timeout)
54.211.202.218 -->seq 0: tcp response from ec2-54-211-202-218.compute-1.amazonaws.com (54.211.202.218) [open]  1.708 ms
54.224.28.113 -->seq 0: tcp response from ec2-54-224-28-113.compute-1.amazonaws.com (54.224.28.113) [open]  1.668 ms
54.224.75.195 -->seq 0: tcp response from ec2-54-224-75-195.compute-1.amazonaws.com (54.224.75.195) [open]  1.815 ms
54.224.75.199 -->seq 0: tcp response from ec2-54-224-75-199.compute-1.amazonaws.com (54.224.75.199) [open]  1.784 ms
54.225.6.1 -->seq 0: tcp response from ec2-54-225-6-1.compute-1.amazonaws.com (54.225.6.1) [open]  1.882 ms
54.226.159.60 -->seq 0: tcp response from ec2-54-226-159-60.compute-1.amazonaws.com (54.226.159.60) [open]  1.760 ms
54.227.104.145 -->seq 0: tcp response from ec2-54-227-104-145.compute-1.amazonaws.com (54.227.104.145) [open]  1.618 ms
54.227.119.61 -->seq 0: tcp response from ec2-54-227-119-61.compute-1.amazonaws.com (54.227.119.61) [open]  1.851 ms
54.234.251.170 -->seq 0: tcp response from ec2-54-234-251-170.compute-1.amazonaws.com (54.234.251.170) [open]  1.530 ms
54.237.191.208 -->seq 0: tcp response from ec2-54-237-191-208.compute-1.amazonaws.com (54.237.191.208) [open]  2.034 ms
54.242.110.149 -->seq 0: tcp response from ec2-54-242-110-149.compute-1.amazonaws.com (54.242.110.149) [open]  2.060 ms
54.242.139.236 -->seq 0: tcp response from ec2-54-242-139-236.compute-1.amazonaws.com (54.242.139.236) [open]  1.451 ms
54.242.152.165 -->seq 0: tcp response from ec2-54-242-152-165.compute-1.amazonaws.com (54.242.152.165) [open]  1.574 ms
54.255.159.230 -->seq 0: no response (timeout)
84.25.161.117 -->seq 0: tcp response from 5419A175.cm-5-2c.dynamic.ziggo.nl (84.25.161.117) [open]  93.978 ms
87.230.94.57 -->seq 0: tcp response from lvps87-230-94-57.dedicated.hosteurope.de (87.230.94.57) [open]  100.838 ms
93.188.161.89 -->seq 0: tcp response from 93.188.161.89 [open]  22.621 ms
104.33.210.231 -->seq 0: tcp response from cpe-104-33-210-231.socal.res.rr.com (104.33.210.231) [open]  85.684 ms
107.20.4.185 -->seq 0: tcp response from ec2-107-20-4-185.compute-1.amazonaws.com (107.20.4.185) [open]  1.771 ms
107.20.28.12 -->seq 0: tcp response from ec2-107-20-28-12.compute-1.amazonaws.com (107.20.28.12) [open]  1.918 ms
107.20.38.255 -->seq 0: tcp response from ec2-107-20-38-255.compute-1.amazonaws.com (107.20.38.255) [open]  1.707 ms
107.20.122.204 -->seq 0: tcp response from ec2-107-20-122-204.compute-1.amazonaws.com (107.20.122.204) [open]  1.577 ms
107.21.138.152 -->seq 0: tcp response from ec2-107-21-138-152.compute-1.amazonaws.com (107.21.138.152) [open]  1.648 ms
107.22.42.148 -->seq 0: tcp response from ec2-107-22-42-148.compute-1.amazonaws.com (107.22.42.148) [open]  1.486 ms
107.170.200.102 -->seq 0: tcp response from drk01.cryptomix.net (107.170.200.102) [open]  80.827 ms
108.61.199.47 -->seq 0: tcp response from 108.61.199.47.vultr.com (108.61.199.47) [open]  84.254 ms
184.73.34.180 -->seq 0: tcp response from ec2-184-73-34-180.compute-1.amazonaws.com (184.73.34.180) [open]  1.879 ms
184.73.48.127 -->seq 0: tcp response from ec2-184-73-48-127.compute-1.amazonaws.com (184.73.48.127) [open]  1.942 ms
184.73.114.32 -->seq 0: tcp response from ec2-184-73-114-32.compute-1.amazonaws.com (184.73.114.32) [open]  1.765 ms
184.73.179.148 -->seq 0: tcp response from ec2-184-73-179-148.compute-1.amazonaws.com (184.73.179.148) [open]  1.090 ms
184.73.179.187 -->seq 0: tcp response from ec2-184-73-179-187.compute-1.amazonaws.com (184.73.179.187) [open]  1.226 ms
184.73.179.196 -->seq 0: tcp response from ec2-184-73-179-196.compute-1.amazonaws.com (184.73.179.196) [open]  0.948 ms
188.226.243.116 -->seq 0: tcp response from 188.226.243.116 [open]  87.661 ms
188.226.248.36 -->seq 0: tcp response from 188.226.248.36 [open]  92.768 ms
204.236.211.102 -->seq 0: tcp response from ec2-204-236-211-102.compute-1.amazonaws.com (204.236.211.102) [open]  1.776 ms

As you can see only 3 out of 70 (4%) have timed out --> 96% of testnet masternodes are now operated with open port 19999. A overwhelming change since yesterday :grin:

To verify that the ports are not only open, but a masternode darkcoind offering service, i connected a testclient to most of them, and the vast majority (~90%) did a correct handshake on first connection attempt, revealing their version number:

Code: 
23.20.78.184 , /Satoshi:0.10.9.12/:
23.23.55.5 , /Satoshi:0.10.9.12/:
37.187.216.11 , /Satoshi:0.10.9.12/:
50.16.10.185 , /Satoshi:0.10.9.12/:
50.16.13.19 , /Satoshi:0.10.9.12/:
50.16.50.164 , /Satoshi:0.10.9.12/:
50.16.159.173 , /Satoshi:0.10.9.12/:
50.17.9.225 , /Satoshi:0.10.9.12/:
50.17.56.71 , /Satoshi:0.10.9.12/:
50.17.76.216 , /Satoshi:0.10.9.12/:
50.19.54.118 , /Satoshi:0.10.9.12/:
54.80.118.25 , /Satoshi:0.10.9.12/:
54.80.186.130 , /Satoshi:0.10.9.12/:
54.80.217.163 , /Satoshi:0.10.9.12/:
54.80.221.149 , /Satoshi:0.10.9.12/:
54.80.248.174 , /Satoshi:0.10.9.12/:
54.81.150.16 , /Satoshi:0.10.9.12/:
54.81.244.239 , /Satoshi:0.10.9.12/:
54.82.237.183 , /Satoshi:0.10.9.12/:
54.83.143.1 , /Satoshi:0.10.9.12/:
[...]

So the masternode network on testnet is not only listening and functional, its almost 100% up to date regarding client updates, which also mean that we have very dedicated masternode operators on testnet - thank you all for your effort.

So the basic implementation of proof of service in RC3 (aka "check for open port 19999/9999") is working as expected and the full implementation (aka "check if darksend is relayed") can be scheduled for RC4.

And now back to testing RC3 :smile:
 
Last edited by a moderator:
As part of the testing, maybe we should throw in some Masternodes on older versions from mainnet?

We don't know what older versions will do to the network and no doubt there will be some who do not upgrade.
 
FoldingTime said:
As part of the testing, maybe we should throw in some Masternodes on older versions from mainnet?

We don't know what older versions will do to the network and no doubt there will be some who do not upgrade.
Click to expand...
We have.
http://54.183.73.24:8080/subver.txt / nomp
http://tdrk.poolhash.org/blocks/subver.txt / tdrk

Code: 
2 "subver" : "/Satoshi:0.10.9.11/",
8 "subver" : "/Satoshi:0.10.9.12/",
3 "subver" : "/Satoshi:0.9.4.11/",
1 "subver" : "/Satoshi:0.9.5.8/",

1 "subver" : "/Satoshi:0.10.9.10/",
2 "subver" : "/Satoshi:0.10.9.11/",
9 "subver" : "/Satoshi:0.10.9.12/",
1 "subver" : "/Satoshi:0.10.9.9/",
4 "subver" : "/Satoshi:0.9.4.11/",
1 "subver" : "/Satoshi:0.9.5.8/",
 
FoldingTime said:
As part of the testing, maybe we should throw in some Masternodes on older versions from mainnet?

We don't know what older versions will do to the network and no doubt there will be some who do not upgrade.
Click to expand...

Yes, you can try connecting a RC2 masternode (v0.10.8.11) to testnet - it should not be able to connect since

a) protocol version changed and is incompatible
b) vote checking algorithm in v0.10.8.11 is broken if payment enabled (like in testnet) - so the client will not be able to receive/confirm new blocks from the testnet blockchain and is orphaning these blocks and getting stuck/forking. This is actually the root cause of the forks we saw in mainnet on RC2 rollout :wink:

But you never know what sideeffects we can have - so: go ahead and try to break testnet :grin:
 
Last edited by a moderator:
How cool do I feel.... :cool:
Dont know a line of code, but I actually found something useful to contribute to DRK !
Gentlemen, I didnt find a bug... I found a typo! :eek:
localdarknode@ubuntu:~/.darkcoin$ DarkCoin server starting
Error: You must specific a masternodeprivkey in the configuration. Please see documentation for help.
Click to expand...

I forgot to MN=0 haha.. :grin:
 
flare said:
Hi Evan,

good news: I had another round of my tcpping script on masternodes and the changes to include port checking vastly improved masternode network stability and reliability!

There are currently 70 masternodes registered in the masternode list. tcpping is delivering the following results:

Code: 
 23.20.78.184 -->seq 0: tcp response from ec2-23-20-78-184.compute-1.amazonaws.com (23.20.78.184) [open]  1.743 ms
23.22.13.31 -->seq 0: tcp response from ec2-23-22-13-31.compute-1.amazonaws.com (23.22.13.31) [open]  1.569 ms
23.23.55.5 -->seq 0: tcp response from ec2-23-23-55-5.compute-1.amazonaws.com (23.23.55.5) [open]  1.599 ms
23.242.106.27 -->seq 0: tcp response from cpe-23-242-106-27.socal.res.rr.com (23.242.106.27) [open]  93.144 ms
37.187.216.11 -->seq 0: tcp response from 11.ip-37-187-216.eu (37.187.216.11) [open]  89.159 ms
50.16.10.185 -->seq 0: tcp response from ec2-50-16-10-185.compute-1.amazonaws.com (50.16.10.185) [open]  1.716 ms
50.16.13.19 -->seq 0: tcp response from ec2-50-16-13-19.compute-1.amazonaws.com (50.16.13.19) [open]  1.728 ms
50.16.50.164 -->seq 0: tcp response from ec2-50-16-50-164.compute-1.amazonaws.com (50.16.50.164) [open]  2.091 ms
50.16.159.173 -->seq 0: tcp response from ec2-50-16-159-173.compute-1.amazonaws.com (50.16.159.173) [open]  1.816 ms
50.17.9.225 -->seq 0: tcp response from ec2-50-17-9-225.compute-1.amazonaws.com (50.17.9.225) [open]  1.994 ms
50.17.56.71 -->seq 0: tcp response from ec2-50-17-56-71.compute-1.amazonaws.com (50.17.56.71) [open]  1.991 ms
50.17.76.216 -->seq 0: tcp response from ec2-50-17-76-216.compute-1.amazonaws.com (50.17.76.216) [open]  1.633 ms
50.19.54.118 -->seq 0: tcp response from ec2-50-19-54-118.compute-1.amazonaws.com (50.19.54.118) [open]  2.716 ms
54.76.47.232 -->seq 0: no response (timeout)
54.80.118.25 -->seq 0: tcp response from ec2-54-80-118-25.compute-1.amazonaws.com (54.80.118.25) [open]  1.786 ms
54.80.186.130 -->seq 0: tcp response from ec2-54-80-186-130.compute-1.amazonaws.com (54.80.186.130) [open]  1.520 ms
54.80.217.163 -->seq 0: tcp response from ec2-54-80-217-163.compute-1.amazonaws.com (54.80.217.163) [open]  1.684 ms
54.80.221.149 -->seq 0: tcp response from ec2-54-80-221-149.compute-1.amazonaws.com (54.80.221.149) [open]  1.729 ms
54.80.248.174 -->seq 0: tcp response from ec2-54-80-248-174.compute-1.amazonaws.com (54.80.248.174) [open]  1.694 ms
54.81.150.16 -->seq 0: tcp response from ec2-54-81-150-16.compute-1.amazonaws.com (54.81.150.16) [open]  1.941 ms
54.81.244.239 -->seq 0: tcp response from ec2-54-81-244-239.compute-1.amazonaws.com (54.81.244.239) [open]  2.170 ms
54.82.237.183 -->seq 0: tcp response from ec2-54-82-237-183.compute-1.amazonaws.com (54.82.237.183) [open]  1.672 ms
54.83.143.1 -->seq 0: tcp response from ec2-54-83-143-1.compute-1.amazonaws.com (54.83.143.1) [open]  2.558 ms
54.83.151.118 -->seq 0: tcp response from ec2-54-83-151-118.compute-1.amazonaws.com (54.83.151.118) [open]  1.565 ms
54.86.103.191 -->seq 0: tcp response from ec2-54-86-103-191.compute-1.amazonaws.com (54.86.103.191) [open]  1.233 ms
54.87.101.82 -->seq 0: tcp response from ec2-54-87-101-82.compute-1.amazonaws.com (54.87.101.82) [open]  2.065 ms
54.87.121.203 -->seq 0: tcp response from ec2-54-87-121-203.compute-1.amazonaws.com (54.87.121.203) [open]  1.876 ms
54.187.152.9 -->seq 0: tcp response from ec2-54-187-152-9.us-west-2.compute.amazonaws.com (54.187.152.9) [open]  78.089 ms
54.197.189.67 -->seq 0: tcp response from ec2-54-197-189-67.compute-1.amazonaws.com (54.197.189.67) [open]  1.702 ms
54.197.213.80 -->seq 0: tcp response from ec2-54-197-213-80.compute-1.amazonaws.com (54.197.213.80) [open]  1.682 ms
54.198.109.108 -->seq 0: tcp response from ec2-54-198-109-108.compute-1.amazonaws.com (54.198.109.108) [open]  1.556 ms
54.198.145.174 -->seq 0: tcp response from ec2-54-198-145-174.compute-1.amazonaws.com (54.198.145.174) [open]  1.557 ms
54.198.191.99 -->seq 0: tcp response from ec2-54-198-191-99.compute-1.amazonaws.com (54.198.191.99) [open]  1.561 ms
54.198.252.150 -->seq 0: tcp response from ec2-54-198-252-150.compute-1.amazonaws.com (54.198.252.150) [open]  1.608 ms
54.203.217.224 -->seq 0: no response (timeout)
54.211.202.218 -->seq 0: tcp response from ec2-54-211-202-218.compute-1.amazonaws.com (54.211.202.218) [open]  1.708 ms
54.224.28.113 -->seq 0: tcp response from ec2-54-224-28-113.compute-1.amazonaws.com (54.224.28.113) [open]  1.668 ms
54.224.75.195 -->seq 0: tcp response from ec2-54-224-75-195.compute-1.amazonaws.com (54.224.75.195) [open]  1.815 ms
54.224.75.199 -->seq 0: tcp response from ec2-54-224-75-199.compute-1.amazonaws.com (54.224.75.199) [open]  1.784 ms
54.225.6.1 -->seq 0: tcp response from ec2-54-225-6-1.compute-1.amazonaws.com (54.225.6.1) [open]  1.882 ms
54.226.159.60 -->seq 0: tcp response from ec2-54-226-159-60.compute-1.amazonaws.com (54.226.159.60) [open]  1.760 ms
54.227.104.145 -->seq 0: tcp response from ec2-54-227-104-145.compute-1.amazonaws.com (54.227.104.145) [open]  1.618 ms
54.227.119.61 -->seq 0: tcp response from ec2-54-227-119-61.compute-1.amazonaws.com (54.227.119.61) [open]  1.851 ms
54.234.251.170 -->seq 0: tcp response from ec2-54-234-251-170.compute-1.amazonaws.com (54.234.251.170) [open]  1.530 ms
54.237.191.208 -->seq 0: tcp response from ec2-54-237-191-208.compute-1.amazonaws.com (54.237.191.208) [open]  2.034 ms
54.242.110.149 -->seq 0: tcp response from ec2-54-242-110-149.compute-1.amazonaws.com (54.242.110.149) [open]  2.060 ms
54.242.139.236 -->seq 0: tcp response from ec2-54-242-139-236.compute-1.amazonaws.com (54.242.139.236) [open]  1.451 ms
54.242.152.165 -->seq 0: tcp response from ec2-54-242-152-165.compute-1.amazonaws.com (54.242.152.165) [open]  1.574 ms
54.255.159.230 -->seq 0: no response (timeout)
84.25.161.117 -->seq 0: tcp response from 5419A175.cm-5-2c.dynamic.ziggo.nl (84.25.161.117) [open]  93.978 ms
87.230.94.57 -->seq 0: tcp response from lvps87-230-94-57.dedicated.hosteurope.de (87.230.94.57) [open]  100.838 ms
93.188.161.89 -->seq 0: tcp response from 93.188.161.89 [open]  22.621 ms
104.33.210.231 -->seq 0: tcp response from cpe-104-33-210-231.socal.res.rr.com (104.33.210.231) [open]  85.684 ms
107.20.4.185 -->seq 0: tcp response from ec2-107-20-4-185.compute-1.amazonaws.com (107.20.4.185) [open]  1.771 ms
107.20.28.12 -->seq 0: tcp response from ec2-107-20-28-12.compute-1.amazonaws.com (107.20.28.12) [open]  1.918 ms
107.20.38.255 -->seq 0: tcp response from ec2-107-20-38-255.compute-1.amazonaws.com (107.20.38.255) [open]  1.707 ms
107.20.122.204 -->seq 0: tcp response from ec2-107-20-122-204.compute-1.amazonaws.com (107.20.122.204) [open]  1.577 ms
107.21.138.152 -->seq 0: tcp response from ec2-107-21-138-152.compute-1.amazonaws.com (107.21.138.152) [open]  1.648 ms
107.22.42.148 -->seq 0: tcp response from ec2-107-22-42-148.compute-1.amazonaws.com (107.22.42.148) [open]  1.486 ms
107.170.200.102 -->seq 0: tcp response from drk01.cryptomix.net (107.170.200.102) [open]  80.827 ms
108.61.199.47 -->seq 0: tcp response from 108.61.199.47.vultr.com (108.61.199.47) [open]  84.254 ms
184.73.34.180 -->seq 0: tcp response from ec2-184-73-34-180.compute-1.amazonaws.com (184.73.34.180) [open]  1.879 ms
184.73.48.127 -->seq 0: tcp response from ec2-184-73-48-127.compute-1.amazonaws.com (184.73.48.127) [open]  1.942 ms
184.73.114.32 -->seq 0: tcp response from ec2-184-73-114-32.compute-1.amazonaws.com (184.73.114.32) [open]  1.765 ms
184.73.179.148 -->seq 0: tcp response from ec2-184-73-179-148.compute-1.amazonaws.com (184.73.179.148) [open]  1.090 ms
184.73.179.187 -->seq 0: tcp response from ec2-184-73-179-187.compute-1.amazonaws.com (184.73.179.187) [open]  1.226 ms
184.73.179.196 -->seq 0: tcp response from ec2-184-73-179-196.compute-1.amazonaws.com (184.73.179.196) [open]  0.948 ms
188.226.243.116 -->seq 0: tcp response from 188.226.243.116 [open]  87.661 ms
188.226.248.36 -->seq 0: tcp response from 188.226.248.36 [open]  92.768 ms
204.236.211.102 -->seq 0: tcp response from ec2-204-236-211-102.compute-1.amazonaws.com (204.236.211.102) [open]  1.776 ms

As you can see only 3 out of 70 (4%) have timed out --> 96% of testnet masternodes are now operated with open port 19999. A overwhelming change since yesterday :grin:

To verify that the ports are not only open, but a masternode darkcoind offering service, i connected a testclient to most of them, and the vast majority (~90%) did a correct handshake on first connection attempt, revealing their version number:

Code: 
23.20.78.184 , /Satoshi:0.10.9.12/:
23.23.55.5 , /Satoshi:0.10.9.12/:
37.187.216.11 , /Satoshi:0.10.9.12/:
50.16.10.185 , /Satoshi:0.10.9.12/:
50.16.13.19 , /Satoshi:0.10.9.12/:
50.16.50.164 , /Satoshi:0.10.9.12/:
50.16.159.173 , /Satoshi:0.10.9.12/:
50.17.9.225 , /Satoshi:0.10.9.12/:
50.17.56.71 , /Satoshi:0.10.9.12/:
50.17.76.216 , /Satoshi:0.10.9.12/:
50.19.54.118 , /Satoshi:0.10.9.12/:
54.80.118.25 , /Satoshi:0.10.9.12/:
54.80.186.130 , /Satoshi:0.10.9.12/:
54.80.217.163 , /Satoshi:0.10.9.12/:
54.80.221.149 , /Satoshi:0.10.9.12/:
54.80.248.174 , /Satoshi:0.10.9.12/:
54.81.150.16 , /Satoshi:0.10.9.12/:
54.81.244.239 , /Satoshi:0.10.9.12/:
54.82.237.183 , /Satoshi:0.10.9.12/:
54.83.143.1 , /Satoshi:0.10.9.12/:
[...]

So the masternode network on testnet is not only listening and functional, its almost 100% up to date regarding client updates, which also mean that we have very dedicated masternode operators on testnet - thank you all for your effort.

So the basic implementation of proof of service in RC3 (aka "check for open port 19999/9999") is working as expected and the full implementation (aka "check if darksend is relayed") can be scheduled for RC4.

And now back to testing RC3 :smile:
Click to expand...

That's great news!
 
Fired up my second node for more testing local.cold/remote, and with assistance I will do my best to try and break testnet lool ... so if there is anything I can do, let me know.

Remote is still version v0.10.9.3-2-gbed3449-beta. Local updated to 10.9.12.

Had over 9k and sent 1k to address 0 local, which passed through really quick.

ubuntu@ip-172-31-23-208:~$ darkcoind getinfo
{
"version" : 100904,
"protocolversion" : 70015,
"walletversion" : 60000,
"balance" : 9256.50040000,
"blocks" : 17498,
"timeoffset" : -15,
"connections" : 8,
"proxy" : "",
"difficulty" : 0.00109485,
"testnet" : true,
"keypoololdest" : 1401955602,
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"mininput" : 0.00001000,
"errors" : ""
}
Click to expand...

Notice I'm way behind blockheight. Tried sending the rest so I could zero the VPS balance. It wont let me. Thought it would be fees, but its not. How come I can send the first time, but not the rest?

ubuntu@ip-172-31-23-208:~$ darkcoind sendtoaddress mrPbaoAeVVeaiuezEmqs7zQimHHcAtKAqq 1000
5a4f907ee8bbdee7687658894868f7fe3062d339926918c487f6c253f9f4588f
ubuntu@ip-172-31-23-208:~$ darkcoind getinfo
{
"version" : 100904,
"protocolversion" : 70015,
"walletversion" : 60000,
"balance" : 8256.50040000,
"blocks" : 17505,
"timeoffset" : -15,
"connections" : 8,
"proxy" : "",
"difficulty" : 0.00092393,
"testnet" : true,
"keypoololdest" : 1401955602,
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"mininput" : 0.00001000,
"errors" : ""
}
ubuntu@ip-172-31-23-208:~$ darkcoind sendtoaddress mgiPurigun7SdJvJhooDj5GUrXZkoBQCzG 8256.5004
error: {"code":-4,"message":"Insufficient funds"}
ubuntu@ip-172-31-23-208:~$ darkcoind sendtoaddress mgiPurigun7SdJvJhooDj5GUrXZkoBQCzG 8256
error: {"code":-4,"message":"Insufficient funds"}
ubuntu@ip-172-31-23-208:~$ darkcoind sendtoaddress mgiPurigun7SdJvJhooDj5GUrXZkoBQCzG 8255
error: {"code":-4,"message":"Insufficient funds"}
ubuntu@ip-172-31-23-208:~$ darkcoind sendtoaddress mgiPurigun7SdJvJhooDj5GUrXZkoBQCzG 8000
error: {"code":-4,"message":"Insufficient funds"}
Click to expand...

I also notice that blockheight since sending the 1k is going up really really reeeeally slow. Like 1 block per 1-2 minutes. I know I should have waited until reaching blockheight to send/receive funds, but I simply forgot.

I also tried masternode=0 ... still at a crawl... and now seems stuck at block 17513. Still going, but slow as a snail.
Anything I can do to test, let me know, otherwise I'll be updating after Evan´s morning compile session...
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top