Reviewing Vlad Zamfir’s "Critique" on Szabo’s Law
Firstly, I must at this time request that the reader read the Vlad post I would be referencing before reading on. That is only if you haven’t already read it.
It is of no real interest for me to dabble in discussions of “Blockchain Governance”, and how it pertains to arbitrating real world disputes, both potential and actual involving parties and their on chain engagements. For the simple reason that, it sometimes involves convoluted notions of optimal dispute resolution mechanisms, oft overlooked inherent trade offs in design and structure of Blockchains, and a whole swath of academic mumbo jumbo / Technobabble. For some who do engage in this mode of discussion and are subsequently fully immersed, there is the tendency to evolve into what I would characterize as becoming
“Randomized echoes of convoluted notions of governance grounded in relativist definitions and naive ideals”.
Moving on, in this post we are going to speak mainly on two points;
I. Crypto Law II Gotchas — The inherent contradiction in Crypto Law II with regards to the founding principles of the Crypto space as a whole.
II. Szabo’s Law — Further shedding light on it and its implications.
I. Crypto Law II Gotchas
How do laws governing Crypto stay legal? Do we wait for Governments to get their pen and paper to legalize a technology that aims to effectively render their input in the discussion of global transfer and storage of value useless, not needed and generally unwanted? And if so which government(s) are we waiting for? Or better yet, what percentage of Governments do we need to conclude its legality, 20, 50, 70? Which government exactly is to be appealed to for Crypto Law to be legal?
We are attempting to separate state from money, for example in the case of Bitcoin. Why would that be deemed legal in any existing Government?
Requiring conforming to laws of (any) state would effectively return power to a centralized authority — the state; thus sacrificing decentralization and seeing the irrelevance of the technology.
Crypto and the state can’t fully co-exist in function. The former aims to transcend restrictions set forth by the latter in transfer, management and general operations of value — money.
The only reason why Bitcoin has worked and others like ecash didn’t thus far is because it is Open, Decentralized, Censorship resistant and completely independent of (any) state in its function, use and design.
II. Szabo’s Law
Maintaining the following definition put forth by Vlad in his post;
Do not implement changes to the Blockchain protocol unless the changes are required for the purpose of technical maintenance.
Let us analyze this definition. The devil I suppose is in the details; what is meant here by “technical maintenance”? I think it is composed of the following two core concepts;
a. Security
b. Functionality
These two IMHO are the foundational pillars of Blockchain protocols. Decentralization is the main pillar of course, however, any attempts at maintaining it might require changes to the underlying protocol that force it, effectively resulting in the entities performing said change to become the central authority, diluting the thing they aim to achieve — decentralization.
It is quite straight forward to see how these two — security & functionality — go hand in hand. With the former directly influencing the latter either positively or negatively. However, for the sake of clarity we shall further elaborate on them a bit.
a. Security
When we talk about security we are referring to the overall security layer of the protocol; the strength of the implementation of cryptographic algorithms used, potential security holes that sacrifice functionality (to be elaborated on shortly), etc.
Any protocol level security bug(s) or vulnerabilities when exploited would sacrifice the second core pillar — functionality. This would then result in the collapse of the system, unless (maintenance) changes are made to safeguard against it.
We could for example assume that at the protocol layer of say Bitcoin, the implementation of SHA256 and ECDSA encryption is flawed and non standard. If Alice wants to send bitcoin(s) to Bob, and on the way Dave takes advantage of the poorly implemented encryptions and seizes control of Alice’s funds, that would completely destroy the functionality of the entire protocol; bitcoin is no longer able to be transferred, and thus renders the entire protocol useless.
b. Functionality
Does the platform at the protocol layer still facilitate the purpose of the system, and to what degree? Lets take Bitcoin for example. In assessing its functionality we are mainly concerned with how well it is still able to achieve Satoshi’s vision;
A purely peer-to-peer version of electronic cash … online payments to be sent directly from one party to another without going through a financial institution.
… [an Open, Decentralized, Censorship Resistant] system for electronic transactions without relying on trust.
— Bitcoin: A Peer-to-Peer Electronic Cash System (Bitcoin Whitepaper, 2009)
We can affirmatively say it still functions as intended. For other Blockchains it would be the same concept; to seek the original vision or problem it is aiming to solve, then compare it to how it is performing currently. Any discrepancy would sensibly warrant a (maintenance) change in the protocol that ensures it adheres to its original intended function, what ever that function may be.
Classic Open Source Law
In all open source projects the number one law is; Don’t break the code. Which is a sensible guiding principal that has seen and continues to see the success of many open source projects like Linux, Bitcoin, Python, VueJS, etc.
Additionally, in the Crypto space, where we always have to deal with the fact that we have people’s money on the line if we do (break the protocol), we have to take serious steps in ensuring that everyone is protected.
Achieving this protection doesn’t necessarily mean hard forking chains when people are swindled into sending their money to some (random) address, or for dispute resolution on functionality additions, or security upgrades to the protocol, but to ensure that the underlying protocols maintain their founding functionality by only changing the protocols when (technically) necessary; in cases where function is no longer evident or is lacking.
Naturally, any additional features (both security & functionality-wise) intended to be integrated into the protocols should ensure that they maintain or at least enhance (a) & (b). If they don’t, then they should probably not be included, so as to avoid destroying the functionality of the protocols.
Taking up one’s time developing protocols that aim to be a near perfect arbitrator could result in adding enormous complexity, and would potentially cause more sacrifices to be made at the protocol layer that could see the end of its functionality. Or worse, result in the chain mimicking a dictatorship or aristocratic state.
Ethereum’s DAO Hack as a case study
There are of course those who do feel that certain incidents like the DAO hack require preventive measures at the protocol layer, such that there is a cap on the maximum amount of coins that can be handled by any single smart contract for example. To some degree this is quite a plausible solution to such a problem. If that is something that the community; both devs and users feel would not sacrifice (a) or (b) then it should indeed be implemented at the protocol layer.
In all fairness, if this sort of design decision is integrated ex ante and not ex post to any incident — as a response, like it was in the case of the DAO hack — then it doesn’t violate Szabo’s law, because it could constitute a maintenance change, or at least an underlying protocol feature from inception.
Szabo’s Law isn’t ”aggressive and insecure”
I am not of the opinion that Szabo’s law is “aggressive and insecure” as Vlad put it, because for starters, there is no aggression, perceivable or otherwise from devs responding to dispute(s) with
Is this dispute a result of a security flaw in the underlying protocol (Layer 1) or functionality. Is there a possible change that can be made to enhance functionality/security that would resolve it? If not, I can’t be of help
For developers, the responsibility they have is two fold;
(1) Maintain the protocols
(2) Educate average users
For (1) its purely going by Szabo’s law., and for (2) they simply give users tips on best practices, like securing their private keys, performing transactions, being able to call out scams, etc.
Though being able to call out scams is more of a community responsibility. As we cannot stop people from attempting to scam others, the best we can do is to avoid them and stay safe.
Lastly, for the insecurity aspect of Szabo’s law, it seems that might have just been a personal attack at best. Or I am probably just unable to understand it at the moment.
Conclusion
I wrote this purely to draw the reader’s attention to two things discussed by Vlad that I felt needed some more clarification;
(I) Crypto Law II
(II) And Szabo’s Law
It seems a bit naive to think that governments around the world would be excited and willing to legalize Crypto, when its aim is to work around (and possibly over) them. Therefore, I feel Crypto Law II might not be that much sustainable, or could at best be characterized as an idealized Utopian law.
I felt his treatment of Szabo’s Law was a bit too superficial, hence our attempt to unpack it in (II) for better understanding.
I really hope this at least helps anyone interested in revising his treatment of Szabo’s law.
Disclaimer
The reader should please note that I do not constitute a reflection of the personal opinions of Nick Szabo with regards to (II). I simply aimed to point out certain things I felt needed more discussion in the treatment given by Vlad.
