* Final step at this point is to erect an adequate set of unit and
integration tests to ensure mix-net correctness.
* the processMsgAction is a temporary hack and should be replaced with
a better interface once sphinx is integrated into the final daemon.
* Node ID’s can only be as long as the security parameter k. Using 16
gives us much smaller overhead for routing messages. However, this
means all node ID’s would have to be 16 bytes.
* So with this change a node-id is the SHA-256 of a node’s public key.
The public key MUST be serialized in compressed form. This node-id
could then possibly be encoded as a bitcoin address (Base58Check).
* It’s assumed senders have a way to retrieve a node’s public key given
the node id.
* Over head is quite small, at just 225 bytes if assuming 5 hops
* Most likely also don’t even need the message at all?
* What would it contain?
* Bunch of TODO’s still left in the code, need to write the portion for
processing and forwarding mix headers received by the nodes.
* After the processing stuff, need to write an extensive set of tests
to ensure correctness.
* Also, need to figure out the division between nodeID and lightning
address. For sphinx, they must be “prefix free”.
* Meaning the way we calculate the shared secret
* They get M = (G * x_us) * b_0, they calc the secret with M * x_them
* M * x_them = G * x_us * b_ * x_them
* We have H = (G * x_them), we calc with H * (x_us * b_0 mod n))
* H * (x_us * b_0) = G * x_them * x_us * b_0
