Bitcoin is a good example. But what about other stuff?
example 1: the behavior of an assembly instruction set must be incredibly rigid.
example 2: the TCP/IP protocol. The paper specifications are insane. And describing bit-length blocks in headers should be unambiguous, no?
example 3: the L-mount alliance in cameras has dozens of camera manufacturers and camera lens manufacturers. Since they claim to be equal partners in this alliance the master should be the specification instead of one camera manufacturers code.
Don't you see a point for both sides of the argument here? Or are still deeply on the "code is specification" side?
OpenTimestamps uses the "code is specification" model.
Also, the OPUS audio codec includes a C implementation: https://datatracker.ietf.org/doc/html/rfc6716#appendix-A A lot of cryptography standards do this too.
TCP/IP is a lot simpler to implement correctly than Bitcoin. Unlike Bitcoin, it's not a consensus protocol... and a full implementation of Bitcoin mostly requires TCP/IP anyway! But even then, TCP/IP isn't actually defined in RFCs the way you think it is. In reality it's defined by running code. When push comes to shove, the running code wins. That's why early networking development relied on "testing parties", where multiple manufacturers got together to verify that their stuff actually worked.
L-mount is an even simpler standard. And again, it's not a consensus protocol, making everything a lot simpler. It's ok if two different cameras/lenses aren't bug-for-bug compatible. And again, like TCP/IP, I can guarantee you that camera and lens manufacturers maintain big libraries of lenses/cameras to test against.
Sorry. All your examples are things that are a lot easier to get right than Bitcoin. Which is why standards for them can get away with lose English language specs. Though as I explained with TCP/IP, in reality the English language specs aren't actually good enough.
reply