greg [8:06 PM]
i know we're against centralization but I'm having trouble idenitifying a testnet when it's up and running. Right now, if I understand correctly, I need to know the *IP:port* address of all validator nodes of a testnet, the *chain_id* and the *public keys* of all validator nodes. And there's no "directory" to look those up. Well, there's DNS to look up IP addresses, so if we agree on a naming convention, we can easily look up IPs and associate them with the chain_id (like in the current public testnets: "up-n-comer-node0.testnets.interblock.io"). This leaves the public keys... I thought maybe we can add the public keys of validator nodes to DNS also (easy way to broadcast the public key) but then we depend on one "directory" for all the data and DNS can be spoofed.
Question #1: Is the inherent security of tendermint enough in a DNS spoofing attack?
Question #2: Are there any discussions going on about how to share public keys in the future?
Resolving this would make life easier during testnet setups also. The current ansible solution is kind of an "all-knowing" solution (you have root access to every testnet validator) which is not a good model of the future. It would be nice to come up with a better solution. In the Docker world, you have the same problem. (edited)
[8:10]
A few details to question #1: situation A: so you are a new non-validator node for a network. You get a chain ID and you derive 7 DNS names from it. The DNS resolution gets you 7 IP:port destinations together with public keys. If some of the public keys and IPs point to the wrong node, will you be able to detect it? If ALL of the public keys and IPs point to a malicious network (same chain_id, properly setup validators) will you be able to detect it?
[8:11]
Situation B: you are a new validator node for a network. After going through the same steps, you try to add yourself to the network where there are a few / all nodes malicious. Do you have a way to find that out?
adrian
[8:14 PM]
What do you think about this idea: Every one of us commits to running one validator node for our testnet. Dog folding our live testnet. @greg deploy scripts are amazing at allowing us to run tests against bit centralised instances, but I don't think that we should use them for our public testnets.
greg [8:15 PM]
That's what I'm thinking too. In the real world, there will be mutiple parties involved. A centralized script like the ansible script doesn't work.
[8:15]
So, assuming everyone of us runs a validator node, how do you want to exchange public keys?
ethan.frey [8:22 PM]
Carrier pigeon :wink:
[8:22]
No NSA there...
greg [8:27 PM]
Do you mean RFC 1149 (IP over Avian Carriers) or the improved RFC 2549 (with QoS)? (edited)
adrian
[8:29 PM]
Mh, I was thinking through a file on github, where everyone uploads their private key
bucky [8:34 PM]
Lol
adrian
[8:34 PM]
That way we can also each sign the release and people can verify that they are using the correct validator hash through github commits. @ethan.frey Do you think that is a reasonable way to get people a trusted validator hash for the light-client?
bucky [8:34 PM]
these are good points
[8:35]
I think we also need to start building a list of peer seeds for the network
[8:35]
once the network is up, and people are coming and going, the addrbook.json will grow
[8:36]
i guess for testnets, its fine if things start more centralized. but its the place where we can experiment with seed/discovery strategies too
Main idea is that everyone one of us should run their own validator on their own DigitalOcean or AWS Linux box. That would be really good dogfooding for how validators will behave in the life testnet.
Furthermore, we can even have testnet coins and can allow members of the community to also run their validator for the testnet. Of coure, we should also have inflation and can test the code path for valditor reward schemes.
zramsay
commented
6 years ago
Discussion from Slack
Main idea is that everyone one of us should run their own validator on their own DigitalOcean or AWS Linux box. That would be really good dogfooding for how validators will behave in the life testnet.
Furthermore, we can even have testnet coins and can allow members of the community to also run their validator for the testnet. Of coure, we should also have inflation and can test the code path for valditor reward schemes.
@jaekwon @ebuchman @Greg-Szabo @ethanfrey