v0.10.9.x Help test RC2 forking issues

Status
Not open for further replies.
0.10.9.11 keeps crashing on my machine after a couple minutes. Neither reindexing nor completely purging the testnet3 folder help. Tried everything at least twice. The last log line is always of the "CheckBlock() : pindexPrev->GetBlockHash()" kind.
 
daaarkcoins said:
0.10.9.11 keeps crashing on my machine after a couple minutes. Neither reindexing nor completely purging the testnet3 folder help. Tried everything at least twice. The last log line is always of the "CheckBlock() : pindexPrev->GetBlockHash()" kind.
Click to expand...

Evan, does the client take into account that there are at least 2 valid payment ratios (10% and 20%) when rescanning the whole blockchain? Or do the payment checks start at block 17275+ on testnet?
 
Code: 
   "height" : 17276,
    "votes" : [
        "7c430000000000001976a9146724d59ce01e66a0dee6019f697116c0ebfa184f88ac01000000"
    ],
    "payee" : "",
    "masternode_payments" : false
 
daaarkcoins said:
0.10.9.11 keeps crashing on my machine after a couple minutes. Neither reindexing nor completely purging the testnet3 folder help. Tried everything at least twice. The last log line is always of the "CheckBlock() : pindexPrev->GetBlockHash()" kind.
Click to expand...

Try downloading the binary again. Masternode payments haven't started yet, so you shouldn't be seeing this: "CheckBlock() : pindexPrev->GetBlockHash()" .
 
flare said:
Let me check if dead/blocked IPs received payments/votes first - if we ensure that payments only get paid when client is connectable on port 9999/19999 real proof of service may be pushed to RC4 for sure.
Click to expand...

Evan, i did some digging in chaeplins stats and found indeed addresses/IP which got paid while blocking port 19999. I don't think that is the idea of proof of service :grin:

Example#1
Code: 
54.227.104.145:19999 1 201372494a05b71984ee84f68bc42b06d5a29fa91e7caa98aec93677070ab696 msMrvVzPQtXNCZBuMdQEkaAHxVGbKp4Ltj 1000.0
[...]
pinging 54.227.104.145 -->seq 0: no response (timeout)
[...]
      4 msMrvVzPQtXNCZBuMdQEkaAHxVGbKp4Ltj
[...]
http://23.23.186.131:1234/address/msMrvVzPQtXNCZBuMdQEkaAHxVGbKp4Ltj


Example#2
Code: 
54.234.251.170:19999 1 f432ffdf0242b30283d89e00eaf8821f6597978693063353c0ed0b621b7076dc n1HRzCV9RBxVJoC5noKVNBCx4gAbTZPyPZ 1000.0
[...]
pinging 54.234.251.170 -->seq 0: no response (timeout)
[...]
      3 n1HRzCV9RBxVJoC5noKVNBCx4gAbTZPyPZ
[...]
http://23.23.186.131:1234/address/n1HRzCV9RBxVJoC5noKVNBCx4gAbTZPyPZ

eduffield said:
Currently if a client can't connect it just skips them and moves onto the next, so it's not a huge deal.
Click to expand...

Could you please review the code in the masternode which is checking wether MNs are connectable on port 9999/19999 if it is really moving forward? As far as i can see normal client/miner does not care wether a node is connectable or not - it is just retrieving a winner from the masternode list and pushes the pubkey to the voting list.

https://github.com/darkcoinproject/...d5d4713b1c1b07f095e515ec0a/src/main.cpp#L5746
https://github.com/darkcoinproject/...d5d4713b1c1b07f095e515ec0a/src/main.cpp#L5789

The enabled property of CMasterNode is always set to 1 and the Check() method is not implemented in client/miner.

https://github.com/darkcoinproject/...7fd5d4713b1c1b07f095e515ec0a/src/main.h#L2437

EDIT: Meanwhile the masternode count is back to 14 and only 2 have tcpping timeout - i wonder when/if the 50 zombies will return :grin:

Code: 
pinging 184.73.179.148 --> seq 0: tcp response from ec2-184-73-179-148.compute-1.amazonaws.com (184.73.179.148) [closed]  3.371 ms
pinging 184.73.179.187 --> seq 0: tcp response from ec2-184-73-179-187.compute-1.amazonaws.com (184.73.179.187) [closed]  1.461 ms
pinging 188.226.243.116 --> seq 0: tcp response from 188.226.243.116 [closed]  87.879 ms
pinging 37.187.47.129 --> seq 0: tcp response from 129.ip-37-187-47.eu (37.187.47.129) [open]  80.518 ms
pinging 54.203.217.224 --> seq 0: no response (timeout)
pinging 93.188.161.89 --> seq 0: tcp response from 93.188.161.89 [closed]  17.269 ms
pinging 54.76.47.232 --> seq 0: tcp response from ec2-54-76-47-232.eu-west-1.compute.amazonaws.com (54.76.47.232) [closed]  97.727 ms
pinging 54.86.103.191 --> seq 0: tcp response from ec2-54-86-103-191.compute-1.amazonaws.com (54.86.103.191) [closed]  2.757 ms
pinging 84.25.161.117 --> seq 0: tcp response from 5419A175.cm-5-2c.dynamic.ziggo.nl (84.25.161.117) [closed]  101.059 ms
pinging 54.255.159.230 --> seq 0: no response (timeout)
pinging 23.242.106.27 --> seq 0: tcp response from cpe-23-242-106-27.socal.res.rr.com (23.242.106.27) [closed]  104.185 ms
pinging 188.226.248.36 --> seq 0: tcp response from 188.226.248.36 [open]  92.434 ms
pinging 107.170.200.102 --> seq 0: tcp response from drk01.cryptomix.net (107.170.200.102) [closed]  78.664 ms
pinging 184.73.179.196 --> seq 0: tcp response from ec2-184-73-179-196.compute-1.amazonaws.com (184.73.179.196) [closed]  1.497 ms
 
Last edited by a moderator:
flare said:
Evan, i did some digging in chaeplins stats and found indeed addresses/IP which got paid while blocking port 19999. I don't think that is the idea of proof of service :grin:

Example#1
Code: 
54.227.104.145:19999 1 201372494a05b71984ee84f68bc42b06d5a29fa91e7caa98aec93677070ab696 msMrvVzPQtXNCZBuMdQEkaAHxVGbKp4Ltj 1000.0
[...]
pinging 54.227.104.145 -->seq 0: no response (timeout)
[...]
      4 msMrvVzPQtXNCZBuMdQEkaAHxVGbKp4Ltj
[...]
http://23.23.186.131:1234/address/msMrvVzPQtXNCZBuMdQEkaAHxVGbKp4Ltj


Example#2
Code: 
54.234.251.170:19999 1 f432ffdf0242b30283d89e00eaf8821f6597978693063353c0ed0b621b7076dc n1HRzCV9RBxVJoC5noKVNBCx4gAbTZPyPZ 1000.0
[...]
pinging 54.234.251.170 -->seq 0: no response (timeout)
[...]
      3 n1HRzCV9RBxVJoC5noKVNBCx4gAbTZPyPZ
[...]
http://23.23.186.131:1234/address/n1HRzCV9RBxVJoC5noKVNBCx4gAbTZPyPZ



Could you please review the code in the masternode which is checking wether MNs are connectable on port 9999/19999 if it is really moving forward? As far as i can see normal client/miner does not care wether a node is connectable or not - it is just retrieving a winner from the masternode list and pushes the pubkey to the voting list.

https://github.com/darkcoinproject/...d5d4713b1c1b07f095e515ec0a/src/main.cpp#L5746
https://github.com/darkcoinproject/...d5d4713b1c1b07f095e515ec0a/src/main.cpp#L5789

The enabled property of CMasterNode is always set to 1 and the Check() method is not implemented in client/miner.

https://github.com/darkcoinproject/...7fd5d4713b1c1b07f095e515ec0a/src/main.h#L2437

EDIT: Meanwhile the masternode count is back to 14 and only 2 have tcpping timeout - i wonder when/if the 50 zombies will return :grin:

Code: 
pinging 184.73.179.148 --> seq 0: tcp response from ec2-184-73-179-148.compute-1.amazonaws.com (184.73.179.148) [closed]  3.371 ms
pinging 184.73.179.187 --> seq 0: tcp response from ec2-184-73-179-187.compute-1.amazonaws.com (184.73.179.187) [closed]  1.461 ms
pinging 188.226.243.116 --> seq 0: tcp response from 188.226.243.116 [closed]  87.879 ms
pinging 37.187.47.129 --> seq 0: tcp response from 129.ip-37-187-47.eu (37.187.47.129) [open]  80.518 ms
pinging 54.203.217.224 --> seq 0: no response (timeout)
pinging 93.188.161.89 --> seq 0: tcp response from 93.188.161.89 [closed]  17.269 ms
pinging 54.76.47.232 --> seq 0: tcp response from ec2-54-76-47-232.eu-west-1.compute.amazonaws.com (54.76.47.232) [closed]  97.727 ms
pinging 54.86.103.191 --> seq 0: tcp response from ec2-54-86-103-191.compute-1.amazonaws.com (54.86.103.191) [closed]  2.757 ms
pinging 84.25.161.117 --> seq 0: tcp response from 5419A175.cm-5-2c.dynamic.ziggo.nl (84.25.161.117) [closed]  101.059 ms
pinging 54.255.159.230 --> seq 0: no response (timeout)
pinging 23.242.106.27 --> seq 0: tcp response from cpe-23-242-106-27.socal.res.rr.com (23.242.106.27) [closed]  104.185 ms
pinging 188.226.248.36 --> seq 0: tcp response from 188.226.248.36 [open]  92.434 ms
pinging 107.170.200.102 --> seq 0: tcp response from drk01.cryptomix.net (107.170.200.102) [closed]  78.664 ms
pinging 184.73.179.196 --> seq 0: tcp response from ec2-184-73-179-196.compute-1.amazonaws.com (184.73.179.196) [closed]  1.497 ms
Click to expand...

The current implement has a few requirements for being paid as a masternode:

1.) You have unspent 1000DRK. This is uniquely kept track of and can't be forged.
2.) You use "masternode start" to initiate the startup sequence
3.) Your client must ping the network every 30 minutes.

These checks are implemented here, in CMasterNode::Check:
https://github.com/darkcoinproject/...d5d4713b1c1b07f095e515ec0a/src/main.cpp#L5807

This does NOT currently include any checks to make sure the port is open, but I'll add this in to the startup sequence and error out if the client can't reach itself.

The "proof-of-service" part of this hasn't been implemented at all. So far we just have a solid foundation for communicating the list, the proof of 1000DRK and the pinging system (this stuff didn't even work before RC3).
 
eduffield said:
This does NOT currently include any checks to make sure the port is open, but I'll add this in to the startup sequence and error out if the client can't reach itself.

The "proof-of-service" part of this hasn't been implemented at all. So far we just have a solid foundation for communicating the list, the proof of 1000DRK and the pinging system (this stuff didn't even work before RC3).
Click to expand...

Good stuff! Keep in mind that the usual client is capable to reach itself through loopback - so a sucessful connection to itself does not implicitly mean it is reachable through public IP.

And sorry for being a PITA the last few days, but i think exactly this will improve the architecture of darkcoin :)

regards,
Holger
 
flare said:
Good stuff! Keep in mind that the usual client is capable to reach itself through loopback - so a sucessful connection to itself does not implicitly mean it is reachable through public IP.

And sorry for being a PITA the last few days, but i think exactly this will improve the architecture of darkcoin :)

regards,
Holger
Click to expand...
I think passive checking is more appropriate, by checking connection status of port
(if my port 9999/19999 was connected from outside) or by viewing peers.dat regularly.
 
chaeplin said:
I think passive checking is more appropriate, by checking connection status of port
(if my port 9999/19999 was connected from outside) or by viewing peers.dat regularly.
Click to expand...
Maybe a MN owner can tamper with the port check (if it's done locally).
 
chaeplin said:
I think passive checking is more appropriate, by checking connection status of port
(if my port 9999/19999 was connected from outside) or by viewing peers.dat regularly.
Click to expand...

Yes, good idea! The info if incoming port is reachable is already in peers.dat / getpeerinfo - Evan might use this :smile:
 
Kai said:
Maybe a MN owner can tamper with the port check (if it's done locally).
Click to expand...
Sure, but until we have full proof of service implemented in RC4 by - lets say - relaying a test darksend message we can start with this basic check.
 
  • Like
Reactions: Kai
flare said:
Good stuff! Keep in mind that the usual client is capable to reach itself through loopback - so a sucessful connection to itself does not implicitly mean it is reachable through public IP.

And sorry for being a PITA the last few days, but i think exactly this will improve the architecture of darkcoin :)

regards,
Holger
Click to expand...

As an investor and someone that doesn't have enough time to do much more than make posts complaining about X or Y :cool: -- I want to say thank you Flare for your time, effort, and hard work.

Also, @ Evan...
a lot of people really don't like when their baby is poked at, but your responsiveness to the issues that Flare and others have raised is refreshing and really instills confidence in me as an investor.

Keep it up guys. :smile:
 
flare said:
Sure, but until we have full proof of service implemented in RC4 by - lets say - relaying a test darksend message we can start with this basic check.
Click to expand...
Each masternode can check the others to create a common list of valid MN.
 
JGCMiner said:
As an investor and someone that doesn't have enough time to do much more than make posts complaining about X or Y :cool: -- I want to say thank you Flare for your time, effort, and hard work.
Click to expand...
Thanks, you are welcome :smile:

JGCMiner said:
Also, @ Evan...
a lot of people really don't like when their baby is poked at, but your responsiveness to the issues that Flare and others have raised is refreshing and really instills confidence in me as an investor
Click to expand...

I could not have said better! Evan is taking my QA bugging like a champion, its tough to get your work reviewed and audited like that. Others would say: "STFU!", but Evan is always coming back with a elaborated and polite answer/solution. I appreciate working with him on Darkcoinproject very much. :smile:
 
Hey guys,

I'd like to help out the testing process by running a testnet MasterNode - can anyone send 1000 drk to XqUeH6armeKnXyoykvEyWGWaoLaxFwoM2o ?
 
snogcel said:
Hey guys,

I'd like to help out the testing process by running a testnet MasterNode - can anyone send 1000 drk to XqUeH6armeKnXyoykvEyWGWaoLaxFwoM2o ?
Click to expand...

darktest@sv2:~> darkcoind validateaddress XqUeH6armeKnXyoykvEyWGWaoLaxFwoM2o

{

"isvalid" : false

}
 
chaeplin said:
darktest@sv2:~> darkcoind validateaddress XqUeH6armeKnXyoykvEyWGWaoLaxFwoM2o

{

"isvalid" : false

}
Click to expand...

Ooops, putting the daemon onto testnet would probably help :)

moSakqDHKv1BJwfTeJsEVJzVYTWeycHRaH
 
Status
Not open for further replies.
Back
Top