The point of capability-secure design is that it's possible to prove that a chunk of code, regardless of its nastiness, cannot take certain actions.
In particular, in this case, it sounds like the offending code:
* Makes outgoing connections with sockets
* Alters the flow of execution outside its scope
Both of these flaws can be mitigated if the ability to do these things is closely-held and not available to all code.
It's true that object-capability languages like E, Monte, Pony, etc. cannot stop you from writing bad code. But they can automatically prove that your code only is as bad as it appears to be, and not any worse via skulduggery.
This code is running on a dedicated Zynq SoC on the miner, where it's treated more as "firmware". Any capability based system running on this SoC would be designed by Bitmain, so they could just backdoor it as well. In addition, the software is required to make outgoing connections, for the stratum mining protocol.
Hard to grok was probably one of the main requirements in this case, so this whole sidebar doesn't mean much in this context. The writer of this code has no interest in safe or lucid.
In particular, in this case, it sounds like the offending code:
* Makes outgoing connections with sockets * Alters the flow of execution outside its scope
Both of these flaws can be mitigated if the ability to do these things is closely-held and not available to all code.
It's true that object-capability languages like E, Monte, Pony, etc. cannot stop you from writing bad code. But they can automatically prove that your code only is as bad as it appears to be, and not any worse via skulduggery.