We will use this time to address some ambiguities and misconceptions. This is urgent to assure timely completion of work.
Notes from Sebastian
Just to be on the same page with secp256k1 and netty-tcnative with OpenSSL:
macOS: The official dynamically linked netty-tcnative from Maven works fine
Linux: The official dynamically linked (against OpenSSL) netty-tcnative from Maven doesn't work at all. We can however contribute to the netty-tcnative project and make it work. The problem manifests only in the official release because they try to be backward-compatible with older versions of OpenSSL. When compiled from sources against the right version of OpenSSL the dynamically linked version should work. It works for me on Ubuntu 16.04, compiled against OpenSSL 1.0.2. It did not work for me on Fedora 28, compiled against OpenSSL 1.1.0. There are no official statically linked versions of netty-tcnative on Maven. They have to be compiled from sources, what I did. The same statically linked netty-tcnative jar works on Ubuntu and on Fedora. I didn't test it on Debian (or other distros), but I think that it will work too.
MS Windows: No information collected so far.
RISK - If we just use TLS for encryption, then you can't know if you've been man in the middled
QUESTION - What does it meant that the validators have a sec256k1 public key? Where did it come from?
Validators generate it themselves
It is part of participating in the Ethereum network
These validators would like to continue to use this key on the RChain platform