There is normally one well-defined protocol: this protocol is like any other protocol reference, a piece of paper (a book, most probably). It explains all aspects of the protocol in a meaningful and technically detailed way. This unique "bible" is the protocol.
I know. I know. Did you forget I've been programming for 38 years. Surely you realized the DAO didn't have this. With that in mind, you may re-read my prior post.
That reference implementation, with largely sufficient test bench software, should be "frozen", just as the protocol text is.
And if the test bench has a bug that was not found? (Starting to realize your error by now I hope)
I think you don't get the gist of what I try to say. If you start a decentralized and hopefully immutable system, you need an "axiomatic basis". There are two ways to do this: the "code" way, or the "reference book" way. As this immutable system is supposed to be based upon INTEND, it seems normal to me to use the "reference book" approach, where, in human language, every aspect is sufficiently explained in detail that there is no doubt over its *intended* functioning.
If you then provide "reference code", that is for illustrative purposes only, with the idea to mutually clarify things. However, code is more prone to errors than a human readable reference text, except in rare cases where there are typos in the reference text and that the code implements something that fits more with the overall intend than the reference text with a typo.
In any case, this is something that should be thoroughly peer reviewed, studied etc...
If there are fundamental errors in this, then the system should be simply abandoned if discovered later - nothing stops you from building a new system with "corrected" aspects, but that is nothing but a hard fork / imitation.
There is absolutely no reason to abandon the system if it is working correctly according to both the reference code and the reference description. This is why there shouldn't be a "lead dev team" once the system is launched. It is what it is, and it will continue that way, or it has a serious flaw, and it should be abandoned. But there's no reason to make it evolve.
Yes, different code implementations can have the code evolve, but the reference protocol should be adhered to without modification.
Nothing stops other dev teams from forking, copying, altering whatever they want of course, but there shouldn't be any "leadership" or anything of that kind of a running crypto system, because it should remain as it was laid down the first day.
Yes, it will get old, yes there are ideas of improvement and so on, but these should be side forks, copies, etc... made by "outsiders".
Bitcoin shouldn't have Core ; ethereum shouldn't have the Foundation and Vitalik, .... These people can invent new systems, can invent forks from their previous creations, all you want. But a running crypto system should be considered as "frozen protocol and no gouvernance or leadership". Until it wears off and dies.
If you tell me the scripting code is the law, then I will say your law is random and undefined. We can't prove a negative in an unbounded universe.
No, the law is exactly well defined.
You don't seem to understand
unbounded nondeterminism and for example the Halting and incompleteness theorems.
The law can be: "we throw a dice and if it is even, we chop your head off." That's still a very clear law.
I agree with you, though, that a Turing complete system can never be "law". That said, Ethereum made a very ugly cut off to render every Turing complete code non-Turing complete (to escape the halting problem): the gas limit ! To me, that must be a HUGE source of unexpected behaviour and hence exploits
You have to be totally out of your mind to invent such a rule. But it is the rule. And a clear rule that is
Mind you that "the law is well defined" does not mean "we know in advance what the outcome will be !". (it should, if "code = law" is to be taken seriously by other people than reckless idiots, signing up to undetermined state trees : you should have to be able to explore all states of a contract, which is impossible in a Turing complete system which is why I think Ethereum is fundamentally flawed). It only means: "there's
a clearly defined procedure to get to the outcome, using all then valid environmental influences, random entries and so on, when the moment has come to find the outcome."
The hacker pursued one avenue in the undocumented protocol and Vitalik pursued another. Your definitions are arbitrary and ambiguous.
The protocol never stated that one would stop an unstoppable contract, no ?
That is if you presume that the protocol does not include the protocol of the smart contract code. Again you are trying to say the source code is a protocol, but it is not. You do not seem to understand computer science on a very high theoretical plane.
It is a multi-layered system. Ethereum's *interpretation* of a smart contract was well-defined as far as I understand. So ethereum's protocol was more than well-defined enough for it not to be an issue in this affair. If there was an issue with exactly how the ethereum virtual machine handled contract source code, there may have been a point. That is, if the ethereum virtual machine behaved differently *in practice* than how it was DOCUMENTED (in paper) by the ethereum protocol description, then there was something to say about this. But as far as I understood, even the subtlety used by the hacker was documented (paper documented) usage of the virtual machine, that worked as described. So the *ethereum protocol* was perfectly in agreement with the running code of the ethereum virtual machine. The compiler too. As such, Solidity, which is part of the paper description of the Ethereum protocol, was correctly coded in the ethereum nodes.
As such, the "source code of the contract" was, well, the full contract, based upon the paper description of the Solidity language. That is the whole idea of "code is law". In as far as there is a *paper* description of the intend of the ethereum protocol, the whole idea of a smart contract is that the source code is the contract for any thing on top of it.
This is the very specificity of "smart contracts", namely that the code and nothing but the code is the contract. That intend is obliterated, and that smart contracts never contain bugs.
You have different priorities than the Ethereum community. So you have no role in deciding what their protocol actually is (well you do as you are part of the environment and can potentially influence public and legal action). The COMPLETE protocol was certainly not written down (nor could it be!).
I know. From the moment that there is leadership, there is no immutability (you don't need a leader to hold status quo). But then this can be a fun system, like Play Station is a fun system, but it is not a decentralized, immutable thing. There are many interesting things out there which are successful, work well, are useful, and are not decentralized immutable systems. Ethereum is one of them. Facebook another. Google another. Very similar systems in fact.
One person's permutation toy, is another man's erector set.
LMAO
Look at the massive level of innovation being unleashed on Ethereum (and Raiden is bringing payment channels to Ethereum very soon, well before Bitcoin will have LN):
Ethereum may be very successful. Google is, too. Fun systems. But not decentralized and immutable. Just fun coding platforms, and experimenting systems. If it has leadership, it is corruptible, has a single point of failure, and is not what I'm interested in as a system that can go underground as a resistance tool to survive and eventually as a means for subversive action (although I think it is futile).
I mean who decides whether the contract stopped. Some argued that the implicit consumer protection contract was cardinal to that of the ambiguous (non-rigorously documented) protocol of executable EVM code. So it continues to this day. 