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
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.
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.
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.
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:
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.
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:
User selects X number of random secure nodes.
User connects to the first secure node.
User requests a relay through the first secure node to the second secure node.
User connects to the second secure node through the first secure node.
The connection process continues X times through random nodes.
User sends the message through the connection chain, broadcasting through the final exit node.
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.
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.
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.
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.
Yes that is the proposed scenario right now. The staking t_address could be in the same wallet for all the nodes, but it needs to be a separate t_address per node. It gets a bit more complicated if we tried to tie multiple nodes to the same t_address.
The caveat is that payments will need to be made to the staking address, otherwise someone could use an someone else’s address for the stake and collect zen on their node. Making payments to the staking address discourages this, but does not really enforce using your own address if you want the payments to go to someone else who is staking it.
There is a requirement of a minimal amount of zen on the node itself to pay any transaction fees a challenge incurs. Perhaps 1 or 2 zen which should cover it for a long time (at .0001/transaction).
The staking address is not associated with the secure node’s wallet.dat. It is part of the configuration of the pool app and used to identify the node and make payments from the payment system on the pool server.
This makes sense now. I spaced on the multi-address / wallet part.
I am thinking of creating an AWS AMI that will have the secure node and associated security settings preloaded to lower the entry barrier for those trying to set up a secure node.
One would load the image, configure t_address and secure node wallet, send a few ZEN for challenge transaction fee, and be good to go. Are there any efforts toward this already?
Using a big cloud provider like AWS to host secure nodes for a distributed system sounds all kinds of wrong. I can understand why someone would want to do it to make money, but it will harm the project by making it trivial for the establishment to track traffic and have access to multiple nodes simultaneously.
We want geographically distributed nodes, run by competent people who keep them updated and secure. We do not want a click-and-go solution enabling people who don’t know what they are doing to weaken the project in their attempt to make money from it.
I am new to cryptos, but extensive experience in business, dev and IT.
As far as I understand secure nodes and communication between them should be built in such way that it doesn’t matter where they are hosted or who is monitoring them. So it is not an issue whether they are hosted on AWS or any other cloud provider, giving they are deployed and configured properly. “Weak” nodes can be hosted in super secure data center, still they can be compromised.
If there is monetary incentive, of course there will be different people (also dishonest) who are willing to earn money by running secure nodes. In my opinion the dev team should come up with solution that nodes that are run by any type of person are secure and risk of compromising any node is minimal.