Quote from: rocks on June 02, 2015, 05:31:25 PM

Quote from: justusranvier on June 02, 2015, 03:35:56 AM

Quote from: cypherdoc on June 02, 2015, 03:30:40 AM

i read about this here one time but i don't fully understand it nor the implications, not being a coder.

a spec is a written, detailed, normal language description of how the protocol works, is that correct? wouldn't the current developer's guide qualify as something similar?

where as the code is what actually executes within the operating system and carries out the protocol rules?

and why NL, do you believe it would've prevented what we have going on now?

The Bitcoin Core is in such bad shape that fully specifying its behaviour is indistinguishable from impossible.

You could say this is Satoshi's fault. What we now call Bitcoin Core started out life as a prototype and evolved into its present condition - it is not an engineered piece of software.

Yes the Bitcoin core evolved in a convoluted and non-ideal manner, but I think the reason we have a situation where "the code" = "the specification" is more basic. Even if the Bitcoin core code was well designed, we would still be in the same situation where the code is the specification.

The reason is in a distributed system such as Bitcoin, there is no rule enforcer. i.e. a centralized entity with the power to tell the distributed system when it is not functioning according to spec.

The result is if the majority of nodes run a common set of code, that code becomes the specification even if the code deviates from the spec. The majority will follow that deviation, because it is the code they are running. If you think about it, that is exactly what a hard fork is. A hard fork is a majority of nodes agreeing to deviate from the existing specification. This holds true whether the hard fork was intentional or if the hard fork was unintentional (due to a bug).

Since the majority of nodes in the beginning ran the bitcoin core, that core became the spec, and any other implementation that deviated from the core would be kicked out of the system.

Quote from: justusranvier on June 02, 2015, 03:35:56 AM

I think the best course of action would be to acknowledge that the prototype has served its purpose and retire it in favour of treating a non-prototype codebase as the reference implementation for which a specification can be written.

Even if we did this, and put a large amount of open effort into creating the a new perfect core, we would still have the above issue. That core would be the specification if the majority ran it, including all of it's unknown bugs.

Quote from: justusranvier on June 02, 2015, 12:39:49 PM

The problem is that there are two very different things in play here:

How humans think the Bitcoin protocol behaves
What Bitcoin Core actually does

There is no case where a divergence between these two things is good. It means that despite years of effort Bitcoin Core is in some ways still a black box capable of surprising behaviour instead of predictable behaviour.

We have no guarantee that Bitcoin Core is self-consistent (like it wasn't in March 2013). Due to the way that code was written, it's likely that we never will have such a guarantee.

The only way out of this mess is to deprecate Bitcoin Core in favour of more-specifiable implementations as rapidly as possible.

If Bitcoin Core (and derivatives) were a minority of the nodes in the network, then the next time one of Bitcoin Core's surprises manifested it would be a problem that a minority of the network would need to fix instead of newly-discovered behaviour that the entire network would need to implement.

And that there is the solution IMHO, we need two things.

A clear specification, and
A situation where there are many separate individually developed cores run on the network, where no one core represents a majority of nodes

If you have those two things, then if any core has a bug, it is up to that core to fix itself to adhere to the spec. Without both, then we are back to the situation where a bug becomes the spec, no matter how well engineered the core is.

thanks nicely put, this also addresses the concerns and lack of trust many have of Gavin and Mike having proposed unpopular or inappropriate ideas in the past, ultimately it preserves the protocol and doesn't empower developers to change it but does encourage cooperation in addressing problems, this gives me confidence again.

marcus_of_augustus poison pill is only a concern if we are switching Core for XT, but that's not what is happening, in fact I see Core under influence by Blockstream as the poison pill, but we are in fact distributing development, and moving the spec from Core to the majority, be there only 3 competitors at this time.

The irony, is we are seeing political positioning to maintain centralization, and the politicians are arguing that their version of centralized power is needed for decentralization.

I'm with Gavin on this one lets decentralize the gate keepers and preserve the network of users.