This is more a hybrid "physicist writes a cryptography/graph-theory paper".
This paper takes secret sharing as a black box and asks the question: once you have your N shares, where on a network should you put them?
The author's claim is that placement is a first-class security parameter, not an implementation detail, because both recoverability and exposure depend on the topology of who holds what.
It's not a cryptography paper, the threat model is very weak by cryptographic standards — e.g. random compromise rather than adaptive or targeted adversaries, no correlation between hacking a vertex and its neighbors (the author flags this extension as realistic but out of scope), and only N-of-N (not M-of-N as one might expect) reconstruction.
I read it as a foundational framing paper that connects share placement to network reliability theory and statistical physics.
I agree with you: no matter how good of a job the code (by construction or types or otherwise) does of “making unsafe states unrepresentable”, that in no way makes a real world complex system “safe” by itself.
Code can be structured so that valves may only be open OR closed, but nothing stops the real world from returning a sensor reading that says “the valve is <undefined>”. To remain a “safe” system, the system must deal with inconsistent states like “heisen-valves”.
> [Most production incidents] are due to the code entering a state that should never have been possible.
You say:
> [...] it is more true that most production incidents are due to the system entering into one of thousands of unsafe states which were possible and latent in production potentially for years
I see you both agree that a broken system enters an "unsafe state" (your words) or a "state that should never have been possible" (OP's words).
"Unsafe state" and "state that should not have been possible" are, in practice in a real system, the same practical thing. I suspect you both would agree "system confuses a string for an integer and acts based on erroneous value" or "system acts on internal state that indicates the valve is both open and closed" would be states that a system should not be in. Outside pedantry, your descriptions are practically synonymous with each other.
I've released version 2.0 of roughenough, a Rust implementation of the draft IETF Roughtime protocol (https://datatracker.ietf.org/doc/draft-ietf-ntp-roughtime/). The Roughtime protocol provides cryptographic secure time synchronization with detection of server malfeasance.
Release 2.0.x of roughenough is a rewrite of the implementation to be simpler, more comprehensive, and more performant. The repo has multiple crates that implement:
* Performance-oriented async UDP server
* Command-line client with multiple output formats
* Multiple backends for secure key management for the server
* Clients can (optionally) report malfeasance to a remote server for analysis
> In that sense, Rust enables escapism: When writing Rust, you get to solve lots of 'problems' - not real problems, mind you, but fun problems.
If this is true for Rust, it's 10x more true for C++!
Lifetime issues are puzzles, yes, but boring and irritating ones.
But in C++? Select an appetizer, entree, and desert (w/ bottomless breadsticks) from the Menu of Meta Programming. An endless festival of computer science sideshows living _in the language itself_ that juices the dopamine reward of figuring out a clever way of doing something.
Related: the notion of "safety" (refusing to discuss "harmful" content) is rather shallow and (relatively) easily undone: _Refusal in Language Models Is Mediated by a Single Direction_ [https://arxiv.org/abs//2406.11717]
The average duration between any two moon phases is 29.530589 days.
Many watches use 29.5 days between phases for simplicity. This results in the watch's moon phase display being off by one day for every two years the watch operates.
There are a few watch manufacturers that use epicyclic gear trains to make the moon phase calculation more precise. An example: the Ochs und Junior moon phase watch will operate for 3,478.27 years before its moon phase display is off by one day (https://www.ochsundjunior.swiss/watches/moon-phase/).
This paper takes secret sharing as a black box and asks the question: once you have your N shares, where on a network should you put them?
The author's claim is that placement is a first-class security parameter, not an implementation detail, because both recoverability and exposure depend on the topology of who holds what.
It's not a cryptography paper, the threat model is very weak by cryptographic standards — e.g. random compromise rather than adaptive or targeted adversaries, no correlation between hacking a vertex and its neighbors (the author flags this extension as realistic but out of scope), and only N-of-N (not M-of-N as one might expect) reconstruction.
I read it as a foundational framing paper that connects share placement to network reliability theory and statistical physics.