1266 sats \ 2 replies \ @petertodd 2 Oct \ on: Code implements specification or Code is specification devs
Writing clear specifications in English is incredibly difficult, essentially impossible. That's why the Ethereum yellow paper – an attempt at doing just that – was an utterly unreadable mess.
If your specification is code on the other hand, you have the enormous advantage of being able to leverage highly sophisticated tooling to help you understand what exactly that specification means, and actually implement it: compilers.
And yes, even a code specification isn't actually an implementation. You still need a compiler (or interpreter) to actually turn that specification into the actual opcodes that the CPU actually runs – the implementation.
This question is one of those things that distinguishes competent people who actually understand how Bitcoin and consensus systems work, and the incompetent blowhards. No-one who has actually worked on this stuff in detail thinks human readable specifications are sufficient. You're always going to end up referencing code specifications to really nail down what you are actually specifying. You can write pseudo-specifications that aid in understanding the real spec. But they'll always be just an explanatory aid.
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?
reply
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