Quote from: almightyruler on December 23, 2019, 02:00:28 PM

Quote from: micro4lpha on December 09, 2019, 05:31:36 PM

bitcoind: Runs under its own user

This makes it sound like you'll be running multiple daemons on the one server, relying only on the file permissions to deny or grant access? You really should be completely isolating each separate coin, so that a compromise of one wallet won't affect the others on the server.

I don't know about Linux containerization, but under FreeBSD you can use 'jail' to run an extreme chroot: only the coin client and a couple of required libraries (as well as the application data) are visible to the process. This means that a compromised coin client can't open a shell (no /bin/sh), can't recompile anything (no cc), and can't start any kind of remote access daemon such as ftpd or nc. Lock each one up tight.

Each coin runs on its own server with its own security measures (ports, user, rpc info, allowedips, etc). The idea is if in the worst case scenario someone is able to get into one of the servers they won't be able to do anything with the others. We're using VPN/tunneling to our servers as they are under a private subnet so you must have explicit access within our office to access the servers.

We will be having a hot wallet (which would be the server) for smaller amounts as well as cold wallet (offline storage) for larger amounts.

Quote from: gmaxwell on December 24, 2019, 01:08:41 AM

The non-stop sequence of micro-architectural side channels on intel-- plus a moderate number on other vendors makes me pretty skeptical of having private keys on anything that isn't physically isolated.

Private keys will be stored in Amazon KMS with CloudHSM to encrypt/decrypt, a little expensive but well worth the security.