Topic: Gold collapsing. Bitcoin UP. - page 294. (Read 2032266 times)

Agreed on all this formalise the spec talk, but this could only be another big (and possibly another fractious) debate at this stage of bitcoin's development. If you can get every interested party in the bitcoin development arena to agree, at this stage in the project, I'd be impressed. It would be best overall though, genuine marketplace for implementations. And a marketplace for forking too, but that's clearly coming anyway at some point or other, better to embrace it and keep the barriers to entry low.

Bitcoin is protocol. -> valid chain of blocks filled with transactions

Imagine if Bitcoin Core/XT, btcd, libbitcoin, BitcoinJ, Toshi, etc. all got together to make sure there was a common test suite that was a strict superset of all the relevant unit tests in each codebase.

The next step would be for each implementation to make sure to add any missing consensus-related tests to their own repositories. Repeat the process as necessary.

After all that was done, you could use the test suites as the basis of a spec.

Organizing that is something useful that Bitcoin Foundation could have done, instead of... whatever it was they did.

if the code is the specification then the code can't deviate from the specification. What happens if the code fails to converge to consensus is that the specification/code is proven to be broken, in which case the majority is forced to accept a change to the specification if they want to have a consensus system. In other hard-fork cases the majority may choose to accept a change, but it isn't forced.

Agree with Justus about multiple implementations.

It is highly ironic isn't it....

Humans as a species seem to love leaders and centralized decision making, we must be wired for it. Every example of a decentralize economic & political system that humans have organized (early US, early Rome are two examples) have been short lived and degenerated into the inevitable command and control organization model. But that's a different topic.

That sounds like an ideal plan. Not sure how to put it into action though. The current blocksize debate if anything shows how the current devs have conflict of interests in even considering this as a direction.

One option is to start with a move towards adoption of multiple implementations before making the "spec". If Bitcoin XT and btcd both gained enough adoption vs. the Satoshi client that all three were below 50% of the network, then we would now have a situation where a bug in the Satoshi client was no longer the spec, and the Satoshi client would have to quickly bug fix itself to adhear to the XT and btcd majority (and same for XT and btcd).

This situation would then force the drafting of a real specification. With one dominate implementation the need for a spec is diminished. But with several implementations the need for them to draft what is agreed becomes quite strong.

Yes, different implementations. That is better wording.


Yes, a spec should be a plain language description on what is and is not valid. Even this can become complicated, but it serves a design point for any implementation. But as I said above, the spec alone is not enough. Even if you have a written spec, but there is a single implementation that is used by the majority, the implementation would trump the spec if a non compliant bug came up.

It's all about that Greece

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.  

What we should aim for is at least three full node implementations in the wild, with no single implementation having majority usage.

Also, a clear spec with extensive testing of each implementation's correctness.

As soon as we make a transition away from a monoculture (one implementation has a majority), we'll have an upper bound on the severity of likely chain forks. If 1 of n implementations disagrees with the other (n-1), then it's clearly a bug in that particular implementation that should be fixed.

The worst case scenario is a bug that causes more than one implementation to diverge at the same time, but that's no worse than what we've already been through in the past and the odds of that happening can be continually reduced with a good QA program.

that's helpful tho i'm alittle confused about a couple things.

when you say different "cores", you mean like Bitcoin Core & btcd?  i thought everyone was referring to them as different "implementations" of the bitcoin protocol?

so is a spec a generalized description written in plain language that is supposed describe what the protocol does from a practical standpoint and thus acts like a broad ruleset to which different cores or implementations are to adhere?

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.


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.


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.  

if you doubt that everyone in the world will ever get an internet connection, here you go:

http://www.technologyreview.com/news/537956/emtech-digital-project-loon-head-details-how-the-balloons-interact/

It's not that black and white, I think everyone has learned more since the bad idea of "green" listing and being able to use money to track child porn.

Those stupid ideas are not death sentences, they are warning signals they are examples of why we need to constantly pay attention to maintain Bitcoin.

Gavin and Mike have moved on it seems and so long as I'm not the benevolent dictator Mike H would like I'm happy to see debate and the majority direct Bitcoin.

My understand is flexible and I won't hesitate to drop XT if it's moving in the direction of adding tracking features and educate the majority.

see, this is where i think the devs understandably relate to the wrong fundamental unit of the system; the full node as opposed to the user.

no, the individuals bank is not the full node, it's the user and his wallet.  yes, to a degree, the security of that wallet depends on full nodes and miners but fundamentally it's the user and his wallet and why so much emphasis is placed on it via security R&D and specialized wallet implementations.  MetCalfe's Law applies to the user base.  that base will only grow via access to easy, cheap, reliable tx's.

he posts the same BS over on Reddit.

same with me

The bug wasn't nearly so deterministic. Whether or not a particular block would trigger the bug depended on the runtime history of a particular node (when they started downloading blocks, how many orphans they had observed, etc) meaning that binary-identical versions of Bitcoin Core running on machines with identical hardware could exhibit divergent behaviour based on them connecting to different peers at different times.

Would have been a good idea to do from the beginning. I'm not sure if the existing code can be cleaned up well enough to make a meaningful difference.

If memory serves 2013 hardfork was more a "dependency" bug imho. Client with ver <= 0.8.0 cant's store block bigger than 512KB due to a Berkeley db default misconfiguration. It could have happened with any other external tool used by the client.

That said I fully agree that we need to decouple the protocol definition from bitcoin core.

In that regard what do you think about the plan to isolate the consensus code in a separete library?

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.

That work has already been done by the authors of btcd (btcsuite).

They do have some truly exceptional developers, particularly davec.

That he receives snubbing, derision, and personal attack for his efforts is a major example of how toxic and dysfunctional the Bitcoin development culture has become.

Some cypherpunks would do well to engage in soul searching regarding the question of so many of their flagship efforts (PGP) have been market failures.

Knowledge of cryptography doesn't automatically translate into understanding business, economics, engineering, or interface design.