Thank you very much for your proposal. It looks like signers might soon be required with BCE 4.0 around the corner.
I understand that
is necessary to provide the exchange with a reliable service.
But I’m on the fence regarding
to achieve that goal, because of the combination of VPS and confidential data, such as wallets containing important keys.
It’s for that reason I run NuBot not on a VPS, but on a RaspberryPi under my control instead - and with the keys on it, “only” the liquidity broadcast could be messed up (as long as the keys are valid).
I know that VPS are convenient. I have several of them. But I’m hesitant using them for confidential tasks.
You just don’t have control over the hardware.
This includes physical access as well as the harddisks, the RAM - the whole VPS host.
I’m aware that my RaPi can get stolen and that the wallet files can get lost to others this way.
But it will be hard to get both the wallet files AND the wallet passphrase.
The VPS can’t protect you from losing both, if an evil administrator wants to have them.
BCE signer keys are the keys to money!
This sounds pretty much paranoid, but if BCE becomes as successful as some think, the signers are the number one attack vector.
To reduce the attack surface, VPS should be avoided.
Thank you for your comments. I’m interested in more opinions on this, as @JordanLee has indicated that a VPS is desirable to ensure maximum availability for traders. There are several anonymous services that are very reputable and wouldn’t pose much risk, although I admit it is non-zero.
In the end the risk for a reliable operation of BCE might be at a higher level, if people who have no sufficient experience with system administration try to set up a reliable solution at home.
With UPS, XEN and a redundant internet access you can easily achieve very high levels of availability.
As the skills to set such an environment up and maintain it are not by definition required for being a reputed signer, VPS might in the end be the safer alternative for a flawless operation.
I dare say BCE can’t afford raising the bar that high and forbid using VPS service for hosting the signing environment - it won’t just find enough signers then.
But that couldn’t stop me from voicing my basic concerns about that.
Agree, there is a risk with VPS. It is the old weighing up of security versus availability.
VPS availability is hard to achieve at home unless you have professional internet services at your business with redundant lines and the likes. The security of a VPS can be compromised indeed but the effort to do this and the risk being caught is usually high and therefore only interesting when a lot of value can be obtained. Besides that VPS providers are more interesting targets to be seized by governments.
I’m hesitating keeping lots of funds on one VPS at one provider therefore. I think the strategy is to spread the risk but that comes at a cost and inconvenience. A good strategy would be to have each signer on a different VPS service or other high availability service. The problem is that advertising the VPS providers used is a risk in itself so how to verify?
Alternatives
Have been trying to think of other examples where high value is trusted to single VPS environments to obtain a risk profile but couldn’t come up with good examples. Most organisation would indeed set up their own trusted datacentre. Another alternative is a hybrid VPS/hosting environment where your own hardware is hosted in high-availability environments with their own physical access restrictions. This is harder to setup as you won’t use the nicely packaged access and monitoring tools from the VPS provider.
Edit: high availability is to me having an UPS, failover hot standby hardware and redundant internet connection (e.g. 3g/4g + wired ISP or dual wired ISP/dual lines)
Tomjoad, obviously I support your bid to became a B&C signer. Few people here, if any, deserve that trust more than you. You’ve done a lot for this community.
However this thread is moving more towards how signers should operate in general. I’ll be watching closely to hear everyone’s opinion on it, but just to clarify, what happens exactly if a signer gets compromised? How does this affect the exchange in a worst case scenario?
That’s pretty much what I had in mind when I listed
Maybe we should ask a moderator to split it into a new topic. @tomjoad, would that be in your favour?
…it was not my intention to derail your proposal as I fully agree with @Yurizhai:
I didn’t want to cast a damning light on it in particular by starting a debate on principles regarding VPS here - the VPS debate applies to each and every NuBot, PyBot and signing environment!
Set B&C to point RPC requests to the VPS. Set firewall rules on the VPS to only allow connections from IP where RaPi is connecting from.
Since all of the transactions on the asset wallets will be multi-sig the risk of them being shutdown/confiscated/whatever is minimal. The keys for B&C would still be safely in your possession. Speed wouldn’t be a huge factor as it’s not a big race like mining or minting to distribute the blocks. Reputed signers are chosen by their reputation, so latency isn’t as much of an issue I think.
I’m not sure if this would actually work. Really depends on how all the puzzle pieces connect.
This sounds like a setup, which can give you the best of both worlds:
convenient operation/backups/restores, good connection and up-time of VPS
maximum safety for the BCE signer keys
Wouldn’t RPCUser and RPCPassword on the VPS conf files be enough?
I’m not speaking about preventing DDoS here, just access to the BTC/BCE/Nu daemons.
Is RPC communication secured or plaintext?
…I’m too lazy to activate Wireshark for answering this
Which requires some skills as well to get it soundly managed
The approach of @CoinGame seems to be a good combination of convenience/reliability and security, that can be implemented from John Doe - more or less.
Keeping the system up-to-date, installing patches etc. is the same.
But installing and backing up a dedicated server can be orders of magnitude more complicated than doing so with a VPS, where you typically have a nice web interface to do all that.
I believe it’s 'better to make being a signer as simple as possible. Btw, how many signers altogether are we planing to have? If there is 1000 signers in future, perhaps we don’t need high end hardware.
In fact, the iphone6s A9 chipset is as powerful as Intel skylake at same frequency, I wonder if we can develope a iPhone App (open source) for B&C signers. We don’t need to wait for Apple’s review before entering App Store because anyone can compile a open source Xcode project on his/her own iPhone.
Please refer to bread wallet.
WARNING:
installation on jailbroken devices is strongly discouraged
Any jailbreak app can grant itself access to every other app’s keychain data and rob you by self-signing as described here and including application-identifier* in its .entitlements file.
Minting isn’t very CPU intensive according to what I hear (more pressure on RAM?), but a problem with iOS (iPhone) has been that apps are not allowed to run longer than 10 minutes in the background. Apple gives exceptions for audio code (Spotify etc.) and some other uses. I wonder if apps can be programmed to run any code indefinitely when not going via the App Store. It seems it should be possible. I feel like it might reduce battery life to an unacceptable degree, unfortunately.
In 2017, a second hand iphone6s may become cheap and with its 1.8Ghz sky lake level performance and low power consumption, connected with wired lightning charger. It should be a safe device for B&C signers as long as our app can run indefinitely.
Raspberrypi3 is Cortex A53@1.2Gh, single thread performance is around 1/6 of A9 (iPhone 6S), such a rubbish hardware with same power consumption with the phone.
I like the idea of using an iPhone, but any Raspberry Pi is likely to be way cheaper than an iPhone 6s in many years, and I think people won’t be super excited to buy a modern phone only to have it sit on a table. If profitability is high, then maybe! The app would have to be written as well.
Especially if you take redundancy into consideration and ease of full system backup/restore!
Just dump the SD card via dd to a backup file and restore it within minutes!
Right! On a RaPi you can just compile the source code.
