Potential Oracles Network Issue - 10/23/2017


#1

Something funky is going on with Oracles Network ( and not the kind of funky that makes me want to get up and dance )

Here is snapshot of netstat @ 10/23/2017 @ 16:36 PDT

Anyone knows what’s going on? Care to share?


#2

We are trying to figure out. Btw, what is in your parity.log on your host, how many peers do you see?

On bootnode:

2017-10-24 02:06:03 UTC Imported #937251 ac1d…fe08 (0 txs, 0.00 Mgas, 1.01 ms, 0.57 KiB)
2017-10-24 02:06:05 UTC Imported #937252 ae0f…367f (0 txs, 0.00 Mgas, 0.52 ms, 0.57 KiB)
2017-10-24 02:06:11 UTC Imported #937253 d0ee…7cc1 (0 txs, 0.00 Mgas, 0.54 ms, 0.57 KiB)
2017-10-24 02:06:21 UTC    2/25 peers      6 MiB chain  193 KiB db  0 bytes queue   23 KiB sync  RPC:  0 conn,  6 req/s,  85 µs
2017-10-24 02:06:51 UTC    2/25 peers      6 MiB chain  193 KiB db  0 bytes queue   23 KiB sync  RPC:  0 conn,  4 req/s,  84 µs
2017-10-24 02:07:03 UTC Imported #937254 5e6f…8947 (0 txs, 0.00 Mgas, 17.49 ms, 0.57 KiB)
2017-10-24 02:07:06 UTC Imported #937255 5f10…0b11 (0 txs, 0.00 Mgas, 0.46 ms, 0.57 KiB)
2017-10-24 02:07:11 UTC Imported #937256 8432…4f24 (0 txs, 0.00 Mgas, 0.55 ms, 0.57 KiB)
2017-10-24 02:07:21 UTC    2/25 peers      6 MiB chain  193 KiB db  0 bytes queue   23 KiB sync  RPC:  0 conn,  5 req/s,  84 µs

#3

@jlegassic we have 100% on the boot node. The problem with CPU is solved in Parity 1.8 and we’ll have it in Sokol testnet. The current 1.7 testnet is not upgradable to 1.8. I suppose problem with CPU may cause peer disconnect.


#4

OK, what processes are consuming all the CPU?
In the screen shot for all processes shown the %CPU is 0.0?

This is what I see when I run:

jhltest@MyUbuntuVM:~$ top

Don’t see a bug on Parity/Kovan for CPU 100% issue.
Can you forward link to bug.

Looking at:

Want to start my parity instance on Azure with following flags:

-l discovery=trace,network=trace

So can see what may be happening on network during discovery.

Can someone advise how to stop my Azure parity instance and manually restart with above flags.

Additionally, shouldn’t have a single point of failure in distributed, fault tolerant network, here the boot node. Can’t imagine there is not another way for peers to discover each other.

Please advise.


#5

We have another network with turned down bootnodes and it works pretty well http://104.41.155.93:3000
nodes see and listen to each other. (based on Parity 1.7)
and a new one on Parity 1.8
http://40.71.90.152:3000/ also fine

Additionally, shouldn’t have a single point of failure in distributed, fault tolerant network, here the boot node. Can’t imagine there is not another way for peers to discover each other.

on the first one, there is no bootnode for days and they work well with each other

Want to start my parity instance on Azure with following flags:
-l discovery=trace,network=trace

You could SSH to your host and change parity config and after sudo systemctl restart oracles-parity
Please paste your logs here.

P.S. Nice meme


#6

Figured out how to change log levels by editing the node.toml file and restarting parity.

Looked at logs doesn’t make much sense to me … would need to look at discover protocol code.

Will post logs later.

It is nice to hear things are “better” but what is different about these (2) environments, compared to existing testnet?

1.7 Environment:

The boot nodes are offline so what is different? … the spec.json? … i.e. how do the authority nodes discover each other and further how do they know they are authority peers, i.e. authority nodes and not a PON ( plain old node )?

1.8 Environment:
I see boot nodes are online, why?

Also, in both of these environments Netstats is a node. Is it an authority node or plain old node?

Yea! Sokol makes fine better!

Gotta get me some of that Sokol : )


#7

Ha, just realized used wrong Sokol beer … the image I used is a Croatian beer not the Russion one … still looks pretty good to me


#8

Some peer history from my parity.log

This is point in time when my node started degrading in number of peers ( i.e. this is last entrance with 7/25 peers )

16734:2017-10-22 01:56:44 UTC 7/25 peers 6 MiB chain 51 MiB db 0 bytes queue 573 KiB sync RPC: 0 conn, 2 req/s, 97 µs
16739:2017-10-22 01:57:14 UTC 6/25 peers 6 MiB chain 51 MiB db 0 bytes queue 573 KiB sync RPC: 0 conn, 3 req/s, 98 µs

For a time bounce between 0 and 3 peers, then after this point:

32607:2017-10-23 07:22:44 UTC 4/25 peers 6 MiB chain 72 MiB db 0 bytes queue 573 KiB sync RPC: 0 conn, 3 req/s, 99 µs
32609:2017-10-23 07:23:14 UTC 0/25 peers 6 MiB chain 72 MiB db 0 bytes queue 573 KiB sync RPC: 0 conn, 2 req/s, 95 µs

Things become pathological with mostly 0 peers, occasionally 1 peer and rarely 2 peers.

Where there any config changes, deployments or anything else around these times that may explain why Network degraded?

Some logs:

jlegassic-peer-history.log

jlegassic-peer-history.log
( contains result of grep -n “/25 peers” parity-trace.log > jlegassic-peer-history.log )

parity-trace.log
( log file with -l “discovery=trace,network=trace” )


#9

Hey there, could you post a bit more on how you got to your log files. What was needed wrt editing of the node.toml file for example. Thanks in advance :slight_smile:


#10

Sure. Got from https://github.com/paritytech/parity/wiki/Configuring-Parity

I just added a line under [misc] just before log_file=""

logging=“discovery=trace,network=trace”

Here is contents of file below with edits:

Contents of ~/node.toml

AlphaTestTestNet branch

[parity]
chain = "spec.json"
base_path = “parity”
[network]
nat="extip:104.42.189.110"
bootnodes=[“enode://886bc3f5f6f6258a89febdf31c71514e27b3647151e96e16bd4bdf6328884b3e8d41bcfb64095496e3701142c4b1f0e6047781d353674b61a45b023845ea742a@40.117.197.50:30300”]
port = 30300
discovery=true
[rpc]
cors = "all"
interface = "all"
hosts = [“all”]
port = 8545
apis = [“web3”, “eth”, “net”, “personal”, “parity”, “parity_set”, “traces”, “rpc”, “parity_accounts”]
[misc]
logging="discovery=trace,network=trace"
log_file = “/home/jhltest/logs/parity.log”
[account]
password = [“node.pwd”]
unlock = [“0xa4A12D11046fbCB5fA8A93A958Cef68AC0856908”]
[mining]
force_sealing = true
engine_signer = "0xa4A12D11046fbCB5fA8A93A958Cef68AC0856908"
reseal_on_txs = “none”

#####################

Perhaps inelegant but then I did:

ps -eaf | grep parity
got the pid
kill -15 %pid%

Since parity running as service, my node was restarted with the logging specified in the node.toml

Hope that helps.

Also, would you mind sharing your public IP for you node with me, I want to try to hook our nodes up manually as per:

Section 5


#11

Calling all Validators!

Would one of you be kind enough to share your public IP of your authority node with me.

John H LeGassic node IP: 104.42.189.110

Thanks!


#12

All,

Igor shared his public IP: 40.117.197.50

I ran the parity_encode API:

jhltest@MyUbuntuVM:~$ curl --data ‘{“jsonrpc”:“2.0”,“method”:“parity_enode”,“params”:[],“id”:0}’ -H “Content-Type: application/json” -X POST 40.117.197.50:8545
{“jsonrpc”:“2.0”,“result”:“enode://886bc3f5f6f6258a89febdf31c71514e27b3647151e96e16bd4bdf6328884b3e8d41bcfb64095496e3701142c4b1f0e6047781d353674b61a45b023845ea742a@40.117.197.50:30300”,“id”:0}

I believe this encode result is same as my bootnode in my node.toml.

I did parity_encode on my own node:

jhltest@MyUbuntuVM:~$ curl --data ‘{“jsonrpc”:“2.0”,“method”:“parity_enode”,“params”:[],“id”:0}’ -H “Content-Type: application/json” -X POST 104.42.189.110:8545
{“jsonrpc”:“2.0”,“result”:“enode://d2ac0975d5e139600f9a7fc33f5f83c02b3e4c5b253ef4a8eb8d645e382e0f7bcc9e645997f1ca1c0198a5c7b9c9cb74f68f6acaab9dc5455601f2a1b58cff96@104.42.189.110:30300”,“id”:0}

Next I tried to pass my encode to Igor’s node via RPC by invoking parity_addReservedPeer API on Igor’s node, but got error ( “Method not found” )

jhltest@MyUbuntuVM:~$ curl --data ‘{“jsonrpc”:“2.0”,“method”:“parity_addReservedPeer”,“params”:[“enode://d2ac0975d5e139600f9a7fc33f5f83c02b3e4c5b253ef4a8eb8d645e382e0f7bcc9e645997f1ca1c0198a5c7b9c9cb74f68f6acaab9dc5455601f2a1b58cff96@104.42.189.110:30300”],“id”:0}’ -H “Content-Type: application/json” -X POST 40.117.197.50:8545
{“jsonrpc”:“2.0”,“error”:{“code”:-32601,“message”:“Method not found”},“id”:0}

Then I did opposite, passed Igor’s encode to my node via RPC, invoking parity_addReservedPeer API and was successful.

jhltest@MyUbuntuVM:~$ curl --data ‘{“jsonrpc”:“2.0”,“method”:“parity_addReservedPeer”,“params”:[“enode://886bc3f5f6f6258a89febdf31c71514e27b3647151e96e16bd4bdf6328884b3e8d41bcfb64095496e3701142c4b1f0e6047781d353674b61a45b023845ea742a@40.117.197.50:30300”],“id”:0}’ -H “Content-Type: application/json” -X POST 104.42.189.110:8545
{“jsonrpc”:“2.0”,“result”:true,“id”:0}

In testnet Netstats, we now are peers …

Hmmm, interesting. Is is possible that the bootnode is configured not to expose the parity_addReservedPeer API?

Believe if have list of public IPs we can manually hook up peers in current testnet and stabilize the network.


#13

Any other takers for providing public IP of your Validator node?


#14

Was able to grab a few more IPs from exercising

jhltest@MyUbuntuVM:~$ curl --data ‘{“jsonrpc”:“2.0”,“method”:“parity_netPeers”,“params”:[],“id”:0}’ -H “Content-Type: application/json” -X POST 104.42.189.110:8545 > peers.log

and grepping thru logs

Anyway, almost “healthy” network …

Really would like a working hypothesis why things are not working ( bug in Parity, config or some kind of internal dev activity ).


#15

great results, John. So, after you added one peer to your node other node used you to connect to each other?


#16

Igor,

No magic, it is all manual effort.

Step 1 – encode node given public IP using parity_encode

Step 2 – for each other node with known IP have to exercise parity_addReservedPeer

More later … gotta run


#17

thanks… On each node? or only on yours?


#18

For each node.

So have 7 active nodes.

There were (7) parity_encode RPC calls

And (28) paritiy_addReservedPeer RPC calls,

Igor <-> John (2) parity_encode (1) parity_addReservedPeer

Igor <-> John <-> Roman (1) parity_encode (2) parity_addReservedPeer

Igor <-> John <-> Roman <-> Jeff (1) parity_encode (3) parity_addReservedPeer

Igor <-> John <-> Roman <-> Jeff <-> Henry (1) parity_encode (4) parity_addReservedPeer

etc …

Is is clear now?

Not sure what it going on with Igor and Henry node … should have 6 peers.

Never could find or get Michael Milirud IP.

FYI, also posted question to Kovan-Testnet Gitter Lobby with trace logs with request for help but no takers, see:

Finally, here is list of peers with external remote address from:

jhltest@MyUbuntuVM:~$ curl --data ‘{“jsonrpc”:“2.0”,“method”:“parity_netPeers”,“params”:[],“id”:0}’ -H “Content-Type: application/json” -X POST 104.42.189.110:8545 > peers.log**
**

Output of parity_netPeers RPC on my node 104.42.189.110

{
“jsonrpc”: “2.0”,
“result”: {
“active”: 0,
“connected”: 6,
“max”: 25,
“peers”: [
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: “3b4d08dff4d0d6ec29adbf33b19b51e2495ee02bbfbd21f6b0ca930a0a2c777aa015fe8691cee633c698a0b80d476c589ca16b25bffaed2edea6d905d39acb63”,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:45844”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: “dbfe4532f2f2ef6ed51085cef5e13a258f22af06f64fd02c098d488fbf7e73f2cf2a956450066a814602bb66f4c00156d7d6b4dc19ffa4093f464efe757d981e”,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:54512”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [
“eth/62”,
“eth/63”,
“par/1”,
“par/2”,
“pip/1”
],
“id”: “7b28234bcf7994353ebca39972c9dd690c337e2a9eb8e87f8f2dc4de91ec251451d84b173120f2b7fd9326ffd1636b62f0cdba2b6d0ddd604930ec01082f879b”,
“name”: “Parity/v1.7.0-beta-5f2cabd-20170727/x86_64-linux-gnu/rustc1.18.0”,
“network”: {
“localAddress”: “10.0.0.4:46048”,
“remoteAddress”: “13.68.221.227:30300”
},
“protocols”: {
“eth”: {
“difficulty”: null,
“head”: “7d794805d46b9f832804a516dae4389b013c5aecd0d67fe4e3d7d010709b171f”,
“version”: 2
},
“pip”: {
“difficulty”: “0xe8854ffffffffffffffffffffffffedf5be5a”,
“head”: “7d794805d46b9f832804a516dae4389b013c5aecd0d67fe4e3d7d010709b171f”,
“version”: 1
}
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: “54fb76c197cd1f5c27e2e9de05d877b5ae05fc503cfe449e1129d8f71f1dd01100a1a013c8f0b2d6548ccc04a76b4f0435c72f63e775cc5bd5754e64348f015f”,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “13.113.181.98:43742”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [
“eth/62”,
“eth/63”,
“par/1”,
“par/2”,
“pip/1”
],
“id”: “f30e8c09e7ca1a32bbfaf32d45f059b59b6091fa1ac017db570d55b5980fdd638d1e49225cbb86ca9723c0d0f985b4db798a934941c9630a8a81c2800349f624”,
“name”: “Parity/v1.7.0-beta-5f2cabd-20170727/x86_64-linux-gnu/rustc1.18.0”,
“network”: {
“localAddress”: “10.0.0.4:38524”,
“remoteAddress”: “13.91.49.213:30300”
},
“protocols”: {
“eth”: {
“difficulty”: “0xe8852ffffffffffffffffffffffffedf5be5f”,
“head”: “7d794805d46b9f832804a516dae4389b013c5aecd0d67fe4e3d7d010709b171f”,
“version”: 2
},
“pip”: {
“difficulty”: “0xe8852ffffffffffffffffffffffffedf5be5f”,
“head”: “549cde2cfb1e37a07f3b5b0d2cbd6bd52353572778f41849069e6b70c8217811”,
“version”: 1
}
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: “2faa4b21dfa48970d8e36efce234c812c19ef72afac0355a473f2380e5579b88337e31c035b2e726f4ac98c892a3e67c3e3c910553dd63e3fd9fce96f5f895ef”,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:52376”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [
“eth/62”,
“eth/63”,
“par/1”,
“par/2”,
“pip/1”
],
“id”: “7aa81dfb867ca4bb2e1e12c3114d8452a48c696ea2f2f5271cd2559e75f202db095f494bc9fa1e68838d2c7cacdaa9ad2f475742f2a8c583d6cee02100d5f21e”,
“name”: “Parity/v1.7.0-beta-5f2cabd-20170727/x86_64-linux-gnu/rustc1.18.0”,
“network”: {
“localAddress”: “10.0.0.4:53144”,
“remoteAddress”: “13.64.71.228:30300”
},
“protocols”: {
“eth”: {
“difficulty”: “0xe8854ffffffffffffffffffffffffedf5be5a”,
“head”: “7d794805d46b9f832804a516dae4389b013c5aecd0d67fe4e3d7d010709b171f”,
“version”: 2
},
“pip”: {
“difficulty”: “0xe8852ffffffffffffffffffffffffedf5be5f”,
“head”: “549cde2cfb1e37a07f3b5b0d2cbd6bd52353572778f41849069e6b70c8217811”,
“version”: 1
}
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: “fae1a85ecb7604258a18d53219ca4902671782fff826abcd71495012458982f47c6d3a01a8da3e7272c6ca03cadbcce9feb86f5400cfaba44a707e93433e0a57”,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:51480”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [
“eth/62”,
“eth/63”,
“par/1”,
“par/2”,
“pip/1”
],
“id”: “36cb5dc109c799f97cb28edcd32fa2d7a817fbe48f74ccf97482fb72d0b8442cc73689fbeb95be9ded83d9bf3f2974867e92ac46938050334074bc12db26be16”,
“name”: “Parity/v1.7.0-beta-5f2cabd-20170727/x86_64-linux-gnu/rustc1.18.0”,
“network”: {
“localAddress”: “10.0.0.4:47766”,
“remoteAddress”: “52.161.29.64:30300”
},
“protocols”: {
“eth”: {
“difficulty”: “0xe8854ffffffffffffffffffffffffedf5be5a”,
“head”: “7d794805d46b9f832804a516dae4389b013c5aecd0d67fe4e3d7d010709b171f”,
“version”: 2
},
“pip”: {
“difficulty”: “0xe8854ffffffffffffffffffffffffedf5be5a”,
“head”: “7d794805d46b9f832804a516dae4389b013c5aecd0d67fe4e3d7d010709b171f”,
“version”: 1
}
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [
“eth/62”,
“eth/63”,
“par/1”,
“par/2”,
“pip/1”
],
“id”: “5c7e04aaad4c556be7ab936f8d2023ad8d7517de3a5047917c9231fef55282ff7ed26c361622908016cfe0eb0663ea705ea892a38102c44e01fda12e41fb2166”,
“name”: “Parity/v1.7.0-beta-5f2cabd-20170727/x86_64-linux-gnu/rustc1.18.0”,
“network”: {
“localAddress”: “10.0.0.4:51976”,
“remoteAddress”: “52.161.101.100:30300”
},
“protocols”: {
“eth”: {
“difficulty”: “0xe8853ffffffffffffffffffffffffedf5be5d”,
“head”: “7d794805d46b9f832804a516dae4389b013c5aecd0d67fe4e3d7d010709b171f”,
“version”: 2
},
“pip”: {
“difficulty”: “0xe8854ffffffffffffffffffffffffedf5be5a”,
“head”: “7d794805d46b9f832804a516dae4389b013c5aecd0d67fe4e3d7d010709b171f”,
“version”: 1
}
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: “bbc6ef92003ca29c94b2868ba7799a9a2823370600710893a727d325df0df4d85efa983c23f010bccc3d9de64babf57659030fa9805b5996555c9fbce0cbd78d”,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:37760”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: “aaf7b88aeae28ec68257314aa02c7add5fd78a11bcbf5fc369882f72cb04769f23d9ffa9aa5214ab67a134d442bc70088fcdbdc8550dedb35afbe5f1fa83a760”,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:48130”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: “f5e26fd7828377a230f1b664b9999cceda9e0508ab510948d16438c9a5ed3c04b5c5217efd41eb991beb4c89c2f4baf2f692c67caef3b52b1b0254c680b63333”,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:43334”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: “03289699ce00f4e7e8fc4ceb9c940542eaa398b4a1e15a1d88946d6229bccb3f6b46532fdf96615babe83e149339024a5326335de5f8cd817518ba3b8275bb17”,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:44528”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [
“eth/62”,
“eth/63”,
“par/1”,
“par/2”,
“pip/1”
],
“id”: “886bc3f5f6f6258a89febdf31c71514e27b3647151e96e16bd4bdf6328884b3e8d41bcfb64095496e3701142c4b1f0e6047781d353674b61a45b023845ea742a”,
“name”: “Parity/v1.7.0-beta-5f2cabd-20170727/x86_64-linux-gnu/rustc1.18.0”,
“network”: {
“localAddress”: “10.0.0.4:57938”,
“remoteAddress”: “40.117.197.50:30300”
},
“protocols”: {
“eth”: {
“difficulty”: “0xe8854ffffffffffffffffffffffffedf5be5a”,
“head”: “7d794805d46b9f832804a516dae4389b013c5aecd0d67fe4e3d7d010709b171f”,
“version”: 2
},
“pip”: {
“difficulty”: “0xe8854ffffffffffffffffffffffffedf5be5a”,
“head”: “7d794805d46b9f832804a516dae4389b013c5aecd0d67fe4e3d7d010709b171f”,
“version”: 1
}
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [
“eth/63”,
“eth/62”
],
“id”: “b43850aea5a0a5df79eeffe1f7ade23bb5146499e59c4cf38bfa0dcbd62219881777675bc81c63d39e44e3c7fd4d99dc377f8bc23e96c6409fca7987da7273b8”,
“name”: “Geth/v1.5.9-stable-a07539fb/linux/go1.7.4”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “52.169.83.225:48444”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: “1e927575c83041b67a194f59d32148a28cc43783e578aa3c2e4835bcd23694c11798c85a50b0fecb63812ed6fd2f15cd40a4d94f806bf949a7112f3183aa068b”,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:35908”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: null,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:30300”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
},
{
“caps”: [],
“id”: “4a3575a1714b09b1c5c426266d0a4b024350faca8cfeb2b965ea885a6a85174ff286d543b0f0c9e3574c92006781e497dbbb1a0292122714d02fe1c8dd181780”,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:59388”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
}
]
},
“id”: 0
}

Peers ( would be helpful if we have names associated with

13.91.49.213 – Roman

52.161.101.100 – Jeff

40.117.197.50 – Igor ( bootnode? )

104.42.189.110 – John L

13.64.71.228 --?

52.161.29.64 --?

13.68.221.227 – ?

xxx.xxx.xxx.xxx - Micael Milirod

52.169.83.225:48444 – didn’t response to parity_encode RPC call ( timed out )

13.113.181.98:43742 – didn’t response to parity_encode RPC call ( timed out )

Also would be nice to know what a Handshake node is:

{
“caps”: [],
“id”: “4a3575a1714b09b1c5c426266d0a4b024350faca8cfeb2b965ea885a6a85174ff286d543b0f0c9e3574c92006781e497dbbb1a0292122714d02fe1c8dd181780”,
“name”: “”,
“network”: {
“localAddress”: “10.0.0.4:59388”,
“remoteAddress”: “Handshake”
},
“protocols”: {
“eth”: null,
“pip”: null
}
}

Is it necessary? What is impact of performance?

And who the heck are these guys:

52.169.83.225:48444 – didn’t response to parity_encode RPC call ( timed out )

13.113.181.98:43742 – didn’t response to parity_encode RPC call ( timed out )


#19

Summon @Micwebnet
Please give us an IP address of your mining node


#20

@jlegassic 52.170.38.51 IP of Michael node