Secure Node Tracking and Payment System Software Development Project Discussion


I like the idea about Slack, I agree that’s the best way to understand the problem.

Your reasoning about a single image does make sense to me, but I believe we’re at an impasse. And that’s okay too.

What you’re suggesting is effectively the equivalent of everyone rolling their own crypto, one of the most cardinal sins in cryptography. The risk management chart you mentioned is a good way to look at this, to me ‘very low’ is more like ‘exceptionally low’, and the ‘low’ impact is more like ‘medium’ impact as more and more people are compromised and uncertainty creeps into the community. In fact, I could imagine an outcry for more hand holding because of just that. I think we are already seeing signs of that in Slack. Either way, I think our intentions are for the most part aligned and it’s just our approach that differ, and as things play out we’ll naturally converge on a solution.


I haven’t suggested anything yet, just opposed some suggestions. I like the current approach of creating guides so people can build their own nodes. Ideally these guides will come in many flavours both in terms of OS and platform. It is nothing like everyone rolling their own crypto - people would be using tested and maintained official open source packages in a guided way. It however fosters understanding of the system rather than promoting what effectively will be a ‘black box’ solution for many.

The suggestion that people building their own secure nodes will lead to

is far fetched and unlikely. We are currently running all nodes in that manner on none of what you anticipate has happened.


Devman - thanks for your response, I finally have the time to reply. If the detailed spec you are working on is published anywhere I’ll be happy to read it, hopefully I am not missing important details below. It ended up being a lengthy post so I’ll start with the summary :slight_smile:

Overall there are few (but important) differences between the two arrangements - here is the summary of benefits and drawbacks for the proposed pooled system as I see them now.


  • allows instant response to nodes looking to register, which will make node deployment easier to troubleshoot


  • requires a port open to the world on the tracking server which would be easy to DDoS or otherwise attack
  • difficult/impossible to publicly audit the node uptime calculation
  • the solution is further removed from the ultimate goal of using the challenge responses as a test of the publishing functionality (to e.g. GNUNet)

In both cases, I would suggest the server uses a private cert for encryption and the nodes verify that cert when connecting or receiving a request. This should prevent amplification or MITM attacks.

In more detail:
1 DDoS: a polling server will be much harder to DDoS as the central server would not have to listen and respond to requests. A DDoS attack would need to exhaust the connection bandwidth to be effective which is much harder than to tie in all available machine resources with bogus requests. A polling server is MUCH safer in this respect.

2 DDoS node: When the node is listening on a port it is trivial to limit the source addresses that it responds to (unlike the polling server). The port will only be opened to the IPs of the polling servers. A simple IP tables rule can make sure noone other than legitimate pre-defined polling servers can connect, which completely eliminates all attack vectors over that port (except compromise of the tracking server).

3 Uptime-availability: there would definitely need to be more than one challenge a day - more like one every 15-30 min I would expect. The exact number would be a matter of balancing granularity with resource usage. The challenges and verifications that the pooled system uses can all be built into the polled system as well. The only item I am not sure about is the challenge during registration as I don’t know what it consists of. Can you describe it?

4 Uptime-tracking: I did not assume there will be only very few disconnects, but agree that is probably safe to assume that. I’d also agree that if well written, the code should be able to notice a disconnect event without having to explicitly check connected clients periodically. Still there will be summing up of durations of disconnect events in the end. Overall the pooled system will be slightly more complicated and prone to error because of the added dependency on the code correctly detecting disconnects. It will be further from the ultimate goal of challenge responses being published to e.g. GNUNet, so either that white paper functionality will be dropped or more re-development will be required. Finally, it would be easy to set up some form of audit system for the uptime tracking as we would just add a system whcih is allowed to poll nodes. With the pooled design we have to trust the pool - I can’t see any feasible way of auditing the decision it makes on the uptime of nodes.

5 Node health and 6) RPC on the node - it is good that ultimately the local SecNodeApp executes the RPC commands; in that case both options should work equally well. Block height is easy to fake, but connected peers can help if we match the results across nodes. If node A says it is connected to node B, C and D but they don’t declare being connected to A then A is faking. Some level of mismatch might have to be permitted.

7 Yes the polling server would verify the URL every polling interval which does mean more work but it is not resource heavy in any meaningful way and can provide an extra check/security. If this is taxing than I think, the polling server can easily store the results and copy the behaviour of the pool system.

8 Self registering: The only difference here as I understand it is whether the node can initiate the registration or has to wait for the next challenge period. Yes it would be easier for troubleshooting nodes if the result was instantly available but opening a listening port on the tracking server open to the world is a price I would not pay for that small convenience.

9 Using the blockchain for administration: fully agree we should limit the amount of transactions and these should not be required at every polling interval. Would it be better if these transactions are done randomly as determined by the tracking server rather than always at the time of node registration, which is triggered by the node?

10 Scalability: The only difference between a pooled and polled system is whether the check will be executed over a ‘always on’ connection established by the node or over a short-lived connection established by the tracking server. The number, timing and type of checks executed is independent of the type of connection used.


I should received my Intel NUC today. For less than $250 it has a celeron, 4G memory, 60G hard drive. I should be able to set it up with a cert and dynamic DNS using Namecheap.

It should be able to run as a secure node. I’ll publish a howto for that also when I get a chance.


Well Brandon there are more and more people finding out about zen and the need for secure nodes ( like me) that are willing to setup a secure node. Give it Time and the nodes will pop up all over the world, like I’m in Belgium 



Blockops that’s good news please keep me informed, and I will setup a dedicated node for the ZenCash network.


Ok installed 2 new VPS special for secure node
is up and running and awaiting the last steps to make it a secure node :slight_smile:
This server is in a brussels datacenter (Belgium)
also this vps is in datacenter in the Netherlands

this servers and domain cost me , so if any one care to donate feel free to do so : znR9wJV9tRBoEk2jEmPTmquewpW4gBziC4E

Cheers :slight_smile:


Thanks All from Argentina,
Thanks Blockops for the nice tutorial, waiting the final steps, i have adapted it to make it work on a proxmox virtual machine( LXC ) on my garage, and used a free dinamic account.

[email protected]:~$ zen-cli getinfo
“version”: 2000954,
“protocolversion”: 170002,
“walletversion”: 60000,
“balance”: 0.00000000,
“blocks”: 140368,
“timeoffset”: 0,
“connections”: 8,
“proxy”: “”,
“difficulty”: 111228.3888628116,
“testnet”: false,
“keypoololdest”: 1500745916,
“keypoolsize”: 101,
“paytxfee”: 0.00000000,
“relayfee”: 0.00000100,
“errors”: “”
[email protected]:~$

To avoid all people from having the same vm you can use multiple os flavor so people can chose, just thinking.


This is the TLS Development branch on zensystemio github


Compiled and installed ! but im not sure if theres any diference, it looks the same to me:)

[email protected]:~$ zen-cli getinfo
“version”: 2000954,
“protocolversion”: 170002,
“walletversion”: 60000,
“balance”: 0.00000000,
“blocks”: 141566,
“timeoffset”: 0,
“connections”: 8,
“proxy”: “”,
“difficulty”: 87447.66154684068,
“testnet”: false,
“keypoololdest”: 1500745916,
“keypoolsize”: 101,
“paytxfee”: 0.00000000,
“relayfee”: 0.00000100,
“errors”: “”
[email protected]:~$



Is there a spreadsheet available somewhere which explains/demonstrates the income to Secure Node operators?

I’ve been trying to create one but I’m getting confused working out the payments!

Basically I’m starting to think that eventually hosting a secure node would become unprofitable and more likely will never be profitable unless you use an old pc at home and only pay for electricity.


By the way the Bitcointalk page has been locked since early this morning
“ATTENTION: Due to the bounty incentivising posting on the ANN thread (which is an on-forum altcoin giveaway in any and all definitions), this thread is locked. There is zero tolerance for those blatantly breaking the “no on-forum altcoin giveaways” rule.”


I think I can put that kind of spreadsheet together. Yes, we needed to create a new bitcointalk thread. Ours got locked for violating TOS. Here is the new one:


This Spreadsheet should help you get closer to figuring out the ROI on Secure Nodes.

Just plug in your different values to play around with it:


Thanks Blockops, could you put in the equations please, specifically the amount of Zen to receive per month (7.56), without this it’s pretty useless lol.

Also I read somewhere that the server should have 4GB of RAM minimum to handle the secure transactions or something (the whitepaper I think), is there any other minimum requirements that’s required?

The 4GB of RAM already rules out the the standard $5 VPS’s plus when you take into account the blockchain increasing in size by 2MB every 2.5 minutes; a couple of years down the line the cost of extra storage space will certainly start to add up. I know hopefully the coin will have gone up in value by then but it’s something that needs to be taken into account as it’s one of the known quantities at this stage.

Cheers again.


looks like on a view only spreadsheet share it does not show the equations. sorry about that, I thought it did.


it is a 2 mb size limit on the block, and only is that big if they are full.

you can use swap space to get from 1 to 4 GB.


Could you copy the equation of the B11 cell and paste it to the right then take out the ‘=’ so it is shown how to come to that figure then please, thanks.

Oh ok that could potentially save quite a bit of HDD space then!

Would using swap be performant enough to do the job satisfactorily?


ok, I updated the spreadsheet. Been traveling so it took me a little while to do that - hopefully that works for you now.

Yes, swap will get the z_transaction done just fine.


I fully agree too. I have no problem setting up and administering a node, but there’s no way I would put my wallet on a VM image.

The whole idea behind blockchain is to get a majority agreement between untrusted parties. If a trusted central authority is added in the mix (to certifiy the VM), this defeats the point of the entire project IMO.

I’m not so worried about the critical mass thing. It took me a few hours to set up my node. I’ve scripted most of the steps, so I can now deploy more nodes in minutes if needed.

@Brandon, really if there’s a need for masternodes for non-technical folks, I believe this is a service that someone like mp-hosting will provide.


Thanks for that @Blockops