Secure Node Tracking and Payment System Software Development Project Discussion

A big part ZenCash is operating Secure Nodes. There is some work to be done to get this system running, and we are getting closer to that. Outlined below is the system and process we intend to follow to get this done.

Please read through, comment, add to, and discuss the high level specification outlined below.

The first step is to find someone to select as the software development project manager for the different Secure Node system below. Next would be for the project manager to get more specific software specifications written. After that, we can get proposals for development of the software application on ZenCash maintained servers.

Please DM me (BlockOps) if you are interested in providing a proposal for project management of development of the Secure Node system.

ZenCash Secure Node System Software Requirements Specification - Initial

Zen Nodes run the software that makes the ZenCash system work. Part of the ZenCash specification is to redirect 3.5% of the mining reward to the owners of ZenCash Secure Node which meet the requirements.

The purpose of funding secure nodes is not to reduce the amount of ZenCash available to the market with the intent of taking it out of circulation.

The purpose is to create a node network that is large enough and resilient enough to provide the foundation for a worldwide private communication and publishing system that is difficult to interrupt and gather data on.

The ideal would be 1000-5000 secure nodes, each running on a separate system, all over the world. The Zen Secure Node reward system has to be designed in a way that will prevent the operation of a large number of secure nodes on one server in one place.

The intent of this document is to create an overview specification for system that will enable Secure Node Tracking and Payment. The first level implementation is to get the basics of the system going so people can operate and be rewarded for running Secure Nodes. Over time the system can be improved to be more distributed, resilient, and automatic.

Each of the specific applications are intended to run on servers owned by the Zen Foundation, with operation. Each application will require a more specific software specification, as well as development.

General Description

Zen Secure Nodes require multiple applications running on different systems to operate. It involves the Zen nodes running software to monitor for and respond to a challenge. There are also applications running on systems that track the challenge, record it, and report. Furthermore, there are applications running on systems to authorize payment.

Zen team will contract for the development of the applications, which will be developed in an open-source manner with an MIT license.

List of System Applications:

A. Secure Node Challenge Publishing System (ChalPubSys)
B. Secure Node (SecNode)
C. Secure Node System Application (SecNodeApp)
D. Secure Node Response Tracking System (TrackSys)
E. Secure Node Response Reporting Server (ReportSys)
F. Secure Node Payout System (NodePaySys)
G. Secure Node Information System (NodeInfoSys)
H. Zen Block Explorer (BlockExplorer)

A - Secure Node Challenge Publishing System (ChalPubSys)

This is the system that generates the challenge. Anyone operating a secure node can monitor the challenge system and respond to it.

  1. Create and publish a challenge.
    1. Find a random transaction in the ZenCash blockchain
    2. Get the first address listed in the transaction
    3. Publish
      1. Transaction number from above
      2. Due time 1 hour from when published
      3. Shielded address to send the response to
      4. Challenge sequence number
  2. Format of challenge publishing
    1. Publish in JSON format on specific port.

B - Secure Node (SecNode)

This is the actual secure node. It is a hardened server that runs the Zen node system software. It also needs to run the SecNodeApp software. It has to maintain a small amount of Zen on it to be able to send shielded transactions. It runs

  1. Zen node software
  2. SecNodeApp software, listed below

C - Secure Node System Application (SecNodeApp)

This is an application designed to operate on the same system as the Secure Node. It will check the ChalPubSys every minute. When a new challenge is published, it will take action and generate a Response, publish the Response, and send a Response Notification.

The action sequence would be:

  1. Detect a new Challenge has been published.

  2. Lookup the Response transaction and address required by the Challenge

  3. Create a text block with the following info in it:

    1. 12 byte hash of Response address
    2. Secure Node t_address
    3. Staking t_address
    4. Challenge Sequence number
  4. Encrypt the text block with SSL private key

  5. Publish in a JSON format on a specific port, including

  6. Encrypted text block

  7. public SSL certificate

  8. Communicate the response published

    1. Send a shielded transaction (z_transaction) to the Response z_address containing URL of the Secure Node response in the memo field

D - Secure Node Response Tracking System (TrackSys)

This server receives the shielded transactions, analyzes them, and records them in a database.

Response documentation. Starts when challenge is posted, stops when response time limit is reached.

  1. Receive the shielded transaction, read memo field
  2. Get JSON information from the URL in the memo field
  3. Separate JSON data into elements, record elements into database
  4. If any of the elements are incorrect, put blanks in database.

After time that all responses have to be accepted, it stops looking at responses that come in until the next challenge is posted.

TrackSys validates the information in the database from the most recent challenge

Issues that this server needs to look for:

  1. Duplicate IP addresses - limit of 1 node per unique IP address per challenge
  2. Sequence number is old
  3. hash of response is wrong
  4. less than 42 zen in the staking t_address (use BlockExplorer to verify)
  5. If possible, verify the secure node shows up in the NodeInfoSys that it is using SSL to communicate with other nodes.

If a specific Staking t_address has a valid response for the time period, it updates a second database with the information

  1. Challenge number
  2. Staking t_address
  3. Node t_address
  4. Valid response

If a specific t_address has an invalid response for the time period, it updates a third database with the information.

  1. Challenge number
  2. t_address
  3. Reason

E - Secure Node Response Reporting Server (ReportSys)

This server will operate a web page that posts the information in the databases of the TrackSys. Pages:

  1. Information about each transaction as it comes in:
    1. Timestamp
    2. Staking t_address
    3. Node t_address
    4. Response hash acceptable
  2. Information about the last challenge
    1. Number and List of secure nodes providing a valid response
    2. Number and List of secure nodes not providing a valid response
  3. Historical record of responses for each Node and Staking t_address since last payout period

F - Secure Node Payout System (NodePaySys)

This is the server that calculates the payment transactions to be made every payout period. Here’s how the payout is calculated

  1. Total number of valid responses in last week
  2. Total number of ZenCash blocks solved in last week.
  3. Payout per valid response = (Total Blocks) * (0.4375) / (Valid responses)
  4. t_address payout = (Valid responses in period) * (Payout per valid response)

Here’s how the payment can be done:

  1. Create a file with all the payment transactions in it.
  2. Provide a total amount needed to the Secure Node Payment address. Pay from a multisig address (2 of 5)
  3. Treasury person transfers ZenCash to Secure Node Payment address
  4. Paymaster 1 goes to payment web page and enters private key
  5. Paymaster 2 goes to payment web page and enters private key
  6. Payment transaction to Secure Nodes is done.

Web page is updated with information with list of Secure Node Payments for the period.

Information Systems

G - Secure Node Information System (NodeInfoSys)

This server maintains a count and identification of all the Zen nodes it can find. It figures out which ones are operating with a valid SSL certificate. Operates a web page providing information

  1. Graph of Zen Nodes over time[m]
  2. Graph of Zen Secure Nodes over time
  3. Searchable list of all Secure nodes

H - Zen Block Explorer (BlockExplorer)

Server running a full Zen node with entire Zen blockchain. This is a block explorer that searches the block chain by:

  1. Transaction
  2. Block Number
  3. Transparent Address

Potential Issues

There will be issues that arise as the system is tested, with both internal and external sources. Some of the ones already identified are:

  1. Spamming the shielded response address with garbage
  2. Spamming the shielded response address with fake answers that invalidate real answers
  3. Operating fake nodes
  4. Operating lazy nodes
  5. Centralized repository of all nodes and their IP address in server

Method of Development and Deployment

This document will start new thread on ZenCash forum. Zen team will discuss Zen community, listen to recommended changes, then update specification.

After specification updated, Zen team will request proposal for Secure Node system development project manager to manage the development of the system.

The ideal project manager for this development will have:

  1. Successful open source software project management experience
  2. Proven software development history
  3. Experience with cryptocurrency development and maintenance.

After project manager is selected, more detailed software specifications will be written for each of the system applications, and proposals requested for the development and support (1 year) of one or more of the system applications.

Payment schedule

Payment will be in ZenCash. Pricing for proposals can be made in either ZenCash or USD equivalent to ZenCash at time of payment. Intended payment schedule

  1. Award - 30% of total
  2. Testnet version running - 30% of total
  3. System deployed and operating - 40% of

Operating System Example

At the beginning, a Challenge will be published daily. This can be increased in frequency as the system scales.

  1. Challenge is published by ChalPubSys (JSON format)
  2. Challenge Sequence Number
  3. Transaction number from the ZenCash blockchain
  4. Shielded address (z_address) to send response to
  5. SecNodeApp is running on a Zen Secure Node. It checks for a new challenge every minute. When it sees a new Challenge, it
  6. Creates a Response
    1. Challenge Sequence Number
    2. Response address (looked up from the transaction number)
    3. Secure Node identifier (Secure node t_address)
    4. Secure Node ZenCash staking info (Staking t_address)
  7. Encrypts the response using SSL private key
  8. Publishes SSL public key and Response (JSON format)
  9. Creates a z_transaction with Response URL in memo field and sends it to the Challenge Shielded Address
  10. TrackSys checks ZenCash blockchain for new responses. When it sees one, it:
  11. Reads the memo field.
  12. Gets the JSON information from the URL in the memo field
    1. Verifies SecureNode SSL public cert is valid
    2. Decrypts the Response with the SSL public cert
    3. Validates the Response is correct for the challenge
    4. Records the valid response for both the Node t_address and Staking t_address.
  13. When the Challenge period is complete, it stops checking for new responses and creates a list of Node and Staking addresses that provided a valid challenge .
  14. ReportSys updates it’s data and presents it in a user readable web page.
  15. Information from TrackSys as each response comes in.
  16. List of successful Secure Nodes per valid Challenge sequence number
  17. Historical record of Challenges and valid Responses
  18. Process 1-4 continues for the duration of the 1 week period. When the week is over, NodePaySys calculates payouts based on formula above.
  19. The more successful Responses, the less each Secure Node is paid.
  20. Payment will be sent to the Staking t_address
  21. Payments will be made weekly.

Video Overview of Secure Node System -


Quick drawing showing different system elements.

any ideas on how to decentralize the challenge and response system?

I understand this might not be possible on the first iteration of the software but it is an important long term goal

1 Like

As the first step for decentralisation we’re going to plan on running multiple copies of each of the servers fronted by a DNS system that can check on server status. There’s different ways we can maintain copies of the databases between the servers in a publisher subscriber or cluster type model.

And similar things with the front-end web servers that are pulling from the back-end databases. We’ve got some experienced system administrators as part of the community that are used to operating resilient designs.

That’s why I’m calling it a secure node system and not just an application.

Even longer term would just like to have it run and have all the secured nodes themselves perform all the functions and consensus of tracking and payment.

Regarding a question on the slack of Dash Masternodes vs Zen SecureNodes

In my opinion, Dash has some systemic problems with their Masternodes that will cause issues in the future. I used to own five of them but now I only own one because the way things are set up are going to cause large volatility price swings for Dash. Because so much of the supply is locked up in their Master nodes anything that they do to change the staking requirement away from 1000 Dash will cause a sell-off on the market.

Also, the only people that get to vote on policy and proposals are the Dash Master node holders. That causes a bias towards maintaining that form of governance.

It is my understanding that two of the early Dash developers run businesses where they host other people’s Master nodes on concentrated systems. There is nothing I have against what they are doing, but if there is a concerted attack on the system it will take a lot of the master nodes offline at once.

Since Dash is going to be relying on their Master nodes for more of what they are doing with their instant send and private send functions in the future, that puts their system at risk. They will probably work their way through the significant upgrades they have planned without an issue, but the costs of running a node will go up as well.

With Zen secure nodes we are not looking to take a lot of the Zen off the market by having a large amount be required for a Secure node. Secure node owners are also not going to be the only ones participating in the governance system.

The main purpose of having Zen secure nodes is to have many distributed and hardened elements of the Zen Network to allow for private transactions and private Communications worldwide.


No sure if a typo, but section G, #3 call for payouts performed using “Payout per valid response = (Total Blocks) * (0.4375) / (Valid responses)”.

Wouldnt this mean that the more valid responses, the less you get paid.

On another note, I was curious as to the process for auditing the OS itself. I believe it is important to perform at least a daily audit for any open CVEs and produce a score, if the system goes below the score, it gets disconnected from the zen network. Something in the lines of OpenVAS or Lynis.

Well yes the amount of payment will depend on the amount of valid responses. The more secure nodes that are running and the more they can meet the response properly the lower the overall payout is her response.

Regarding the security of the operating system I guess we’d have to look at what would be the nature of the problem if the operating system wasn’t secure. I think as long as the Node software is passing along valid transactions and using a valid SSL certificate the operating system itself might not need to be as secure.

In the original design we were thinking to make the operator put the Zen on the Node itself and be responsible for maintaining security but I think we can have the owner of the secure node keep the Zen on his or her own wallet and merely tell the node what the transparent address that is staking the 42 Zen is.

Hi everyone, here are my thoughts on this, by section:

A - ChalPubSys

Rather than publishing on a web page this should be available in JSON format thorugh a web server (may be that is what was meant). It will be read by software rather than people.

C - SecNodeApp - much like above, the SecNodeApp could make the challenge result available as JSON. I would also think a full web server operated on the node is overkill and contradicts the hardening requirement by incereasing the attack surface. The SecNodeApp can listen on a port and only accept connections from the TrackSys addresses, TLS authenticate connections and respond with the JSON over HTTPS. I am operating such small apps written in perl (using Perlbrew, Dancer2, etc.), it should be perfectly possible in Python as well, possibly even easier.

D - NodeInfoSys - How will this discover nodes? If it is possible to securely query connected clients with an RPC command that may be a way - i dont know. Otherwise some sort of ‘hello’ from the nodes might be needed. SecNodeApp could provide that for secure nodes.

E - TrackSys - I think allowing 3 nodes per IP is wrong and weakens one of the few ways (if not the only way) we have of ensuring nodes are distributed. SSL verification (pt. 5) should be perfectly possible.

Not sure what would the ‘Reason’ field contain in the database with invalid responses. If the validity needs to be double checked/audited later, the invalid response should be stored there.

G - if payment is made to the node t_ address which holds the 42 zen, then possibly the requirement that the address should hold exactly 42 zen should be relaxed

To avoid spamming/ddos we could look at some form of proof-of-work ddos prevention mechanism. I think this is very important but don’t really have a solution atm.

I don’t quite understand how a real answer can be invalidated?

This should be mitigated if node discovery is done over RPC commands through connected clients spidering. Not because RPC responses can’t be faked but because the host has to be a peer to get queried. Have no idea if that is possible and secure though.

If this becomes a problem a) the challenge response windown can be reduced b) intermittent responders can receive less payment

1 Like

Thanks for the feedback - it makes sense to me to not run a full web server but instead publish the challenge as a JSON using the SSL cert on a specific port, both on the ChalPubSys as well as on the SecNodeApp

For the exactly 42 Zen per node. My idea was to maintain this on a user’s wallet on their own PC, not on the node. The SecNodeApp would send the user’s t_address in the response, but it would not be the same as the one on the node itself. It would not matter what the address of the node itself was, it would just need enough Zen on it to cover the transaction fees of sending the responses as shielded transactions.

Regarding ChalPubSys (A):

I think we could totally eliminate this by generating the transaction id used in the challenge from the last block in the chain.

I.e.: ChallengeTXId = F(last block)

If a single TX is not enough multiple TX Ids could be generated from the last block. Someone needs to do the math to ensure that F(Block_i) generates evenly distributed results between 1 and i, but this would totally eliminate the need for a ChalPubSys.

On “announcing”/discovering SecureNodes:

I think we could use the text field of the z_address of a 42ZEN transaction to announce a new (potentially) secure node to the network.

As a result, NodeInfoSys and TrackSys could use the blockchain to poll and verify secure nodes by checking for transactions with a specially formatted text field that contains the FQDN of the node. During polling, the node will be able to prove it has a valid SSL certificate, provide the response to the last challenge it solved, etc.


Part of the idea of the challenge is to make sure the node maintains a full copy of the blockchain. I think maintaining a full copy is important, but of course that’s up for discussion also.

Just a quick review so far:

This is what is in development or planned for development:

1 - add openSSL to Zen node software - already in progress
2 - script to check for a new JSON information on a website. When it sees new JSON info, do a lookup, create a text block, publish text block on in JSON format, send a shielded transaction to an address - this is the software that runs on the Secure Node
3 - Centralized server based applications that:

  • publish challenge
  • read shielded transaction with JSON URL
  • get data from JSON url, check if response is valid
  • keep track of valid responses. Every week, total up the valid responses
  • run a payment process.
    • Centralized applications that report on the network - number of secure nodes, block explorer.
1 Like

Are you think 42 ZEN exactly, or 42 ZEN minimum?

I think minimum, because we are going to use the same account to deposit rewards to.

One other potential issue that I haven’t seen mentioned is a protection mechanism against a malicious secure node that is tracking user activity. If a user broadcasts a message through a malicious secure node, that node now has the IP of the user, and the data they sent. This could be mitigated by adding relay functionality to tunnel connections from users through other secure nodes randomly, similar to Tor. Using this approach, a secure node will never be able to see both the user IP address, and the data they are sending, at the same time. They will get one or the other at best.

Process as follows:

  1. User selects X number of random secure nodes.
  2. User connects to the first secure node.
  3. User requests a relay through the first secure node to the second secure node.
  4. User connects to the second secure node through the first secure node.
  5. The connection process continues X times through random nodes.
  6. User sends the message through the connection chain, broadcasting through the final exit node.

Secure nodes will see only one of the following:

  • User connected and requested a relay.
  • Secure node connected and requested a relay.
  • Secure node connected and requested a broadcast.

One problem that comes to mind is the linear labor required to run multiple secure nodes.
Is there a way to stake multiple secure nodes from the same wallet?

Otherwise, maintaining multiple secure nodes would be a huge pain for most.

For example:
I have 420 ZEN. I want to set up 10 secure nodes. Do I need to set up 10 wallets and monitor them all individually? Or can I just stake 420 from my single wallet and use the same t_address on each secure node? The latter seems necessary.

It would seem that putting 42 Zen into 10 different addresses on the same wallet would be the best solution. You can have lots of different addresses on 1 wallet.

1 Like

While working on the detailed specifications a few of the challenges had me rethink some of the proposed architecture. Please comment on this alternative approach and add any ideas or concerns you may have.

1 Like

For clarity - you are saying a single (remote) node with 420 zen spread across 10 t-addresses in a single wallet.dat (‘the stake’) - then running 10 completely separate (preferably geographically separate) Secure nodes that hold NO ZEN
but point back to ‘the stake’ ???

I like the idea of this - especially utilising the method of loading ONLY the t-address (not the spending key) on the secure nodes wallet.dat for view-only access and ensuring that even a breach on the secure node server would not expose the zen stake to attack.