Thoughts on turtlecoin public nodes

About a month ago, I set up trtl.nodes.pub, an automatically updated directory of public turtlecoin nodes.

Since then, I’ve been tweaking it every now and then:
– Some nodes seem to be dead or down, so when a node is not reachable for 20 consecutive polls (~200 minutes) it will not show up.
– I modified the API to respond with a JSON that is similar to https://github.com/turtlecoin/turtlecoin-nodes-json/blob/master/turtlecoin-nodes.json and as such it is a drop-in replacement (with some extra info, such as fee info)

The motivation behind trtl.nodes.pub is to help the “marketplace” (?) of public nodes. I want to make it easy for users to pick a public node, and at the same time to avoid having all traffic go through one or two of them.

In this direction, the API will query the DB and get results sorted by last block height (i.e. node is up to date), poll score (this is calculated based on the number of times the node was not reachable during the last 20 polls, and it’s a measure of reliability) and finally fees. However, the top 5 results will then be sorted in random order before they are returned as a JSON list.

I would like to think in advance on how this service could work if the TurtleCoin ecosystem grows much bigger and the valuable of the token gets higher. If this happens, I can see the possibility of people trying to game the service and I would like to try to be ready. In this direction I’m working on a system that will penalise hosts that use the same IP to avoid the case where the API returns 5 results that are the same node with different hostnames. (I’m also thinking of giving a higher score to nodes that use more than one IP, ie. two A records for the same host name.)

There is one more thing. It turns out that using a public node may be an attach vector that a malicious actor can take advantage of. The attack takes advantage of the fact that when a client connects to a public node, it exposes its IP to it. I’m working on what could be an easy solution to this: a simple proxy designed to hide the client IP and that anyone can deploy on Google Cloud services for free.

2 thoughts on “Thoughts on turtlecoin public nodes

  1. you could see how these guys do it https://bitnodes.earn.com/nodes/leaderboard/
    this site has been at the task of maintaining a bitcoin node list for a while.
    they actively crawl the whole BTC network and TurtleCoin has a self-published list which you pull from so that is a bit different, however, the scoring system is something to check out 😉

    Without nodes reporting their PeerID via the RPC interface going to be difficult to detect or somehow take into account what nodes are doing at the IP/hostname level. And turtlecoind-ha forces a new PeerID when it kills a daemon to restart it if it detects any issues.

    Not sure it would be possible to detect the same node being served from multiple IP addresses though, and that could be masked easily enough… if anyone built a node that used the same data backend and made that available all around the world reducing latency to the next hop, that is probably a desirable fact rather than undesirable…

    I like your pub node list site, works great!

    Like

    1. Thanks! bitnodes has some interesting ideas.
      Maybe I should list nodes based on IP and not hostname. (And even have multiple entries for nodes with multiple IPs). Any ideas are more than welcome!

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s