Topic: Is there any full node implementation 100% compatible with the core client? (Read 4539 times)

An implementation forking from the majority view is not an issue for the majority or for the network at a whole.

BUT you personally would not want to be in the minority for any exploitable time period, because that could mean that you accept coins for your goods that are already spent in the majority view.

Your financial loss would be realized and final once you fix your software and return to majority consensus.

A vast majority of the nodes is running a version or another of the core client. I don't know the exact numbers but when I look at https://blockchain.info/en/connected-nodes, it looks like it's close to 100%.
In my opinion, if most of the nodes run similar code it increases the risk of a common exploit similar to heartbleed or shellshock. Furthermore, Bitcoin core upgrades are conservative because it must avoid introducing bugs as much as possible. In my opinion, if the network was more heterogenous with let's say 10 different implementations sharing equal weight then the chances of a major fork will remain limited. An attack would need to find a flaw that affects 5 different implementations to gain majority.

Yet, it is the responsibility of whoever chooses to run a node to understand the risk taken. They could run several implementations for instance.

Your work there is appretiated, but lets admit further benefits:

1. It is cheaper to learn from mistakes others make
2. Dangers uncovered elsewhere keep the herd together

What do you mean saying "we"?
Do you include me and 7bln other people on Earth?
Should I care about any implementation of bitcoin app? Why?

I'm kind of alarmed at the false equivalence you're drawing between all possible changes. That bogus, and I know you know it.

When you're talking about a compact intentional delta you can reason about the exposure; you might fail, you might not. Normally it wouldn't make sense to do this on the balance of the costs.

The _ability_ to do something is important; it's a functional check and balance even if you don't actually pull the trigger on it or if you find those changes are just helpfully welcomed in.  When the consensus is potentially bifurcated without someone doing something awful it reduces the pressure to maintain homogenity as a justification to not deploy features which are harmful to a minority ("let them run their own nodes, and see if anyone cares").
 
There is no escaping that we must care about implementations even run by a small number of people. If something happens in the network that harms them its a harm for all of us.  Outsiders rightfully do not judge Bitcoin for this implementation vs that implementation. We're all in this together.

Barack Obama and Vladimir Putin?

Those who control the github keys of the most popular fork (bitcoin/bitcoin) determine the code run by the majority, this however is just common sense. Those who achive and maintain consensus and trust of people have power.

Those who know the beast called "Nakamoto consensus" are quick to point out the dangers, that are very real.

You are still free to fork or rewrite for your own benefit or loss. There are safer ways to play that too, keep asking and listening.

Am I the only one that sees how conflicted the messaging is in this thread?

In one camp we have people saying that BC is not really centralized because it's free and open source and can therefore be forked and modified in any arbitrary fashion, but then the other camp talks all about consensus issues and why implementations not running the official BC source are a bad idea.

What's interesting about this is the moment you fork the code and start making changes to it, it is also an alternative implementation.  You could argue about the probabilities of forking risk, etc, but the fact remains, the moment you fork it and modify it, you are running something that is not the same as the majority of other nodes on the network.  It would not take much at all for somebody to fork BC and refactor some code while adding some features that they want which accidentally (or even intentionally if it's a malicious actor intending to distribute their fork) makes a mistake that very subtly breaks consensus.  This is really no different than any other alternative implementation when you get right down to it.

It's either acceptable to have Bitcoin nodes running different code bases or it's not.  I just don't see how any reasonable person can claim it goes both ways.  Either the message must be that it's too dangerous to run anything except the official Bitcoin Core sources, in which case the development truly is centralized and controlled by the small group of people who hold the ssh keys, or that it is in fact acceptable to run modified sources (which very much implies alternative implementations).  It's just not reasonable to claim that it's not centralized because theoretically anybody can fork it and do whatever they want while at the same time saying don't do that because it's too dangerous!

I hoped he was paid for bitcoin core so he does not need to get his brain on something as futile as a bug in alternative implementations.
If I were rich, I would pay so he does not need to do it. (Well, that's a work in progress... the being rich part... )

May be someone pay for it?  

You are preaching a convinced one.
However having multiple fork of the project, with different implementation, makes the system more diverse and anti fragile. Sure there will be more fires, but one fire will not burn the whole forest.

I don't consider it a priority at this stage... maybe in 10 years. But for some people, this is a priority.

Having alternative implementation in several language might add more review power : Take myself, I am unable to contribute to core. I can't compile the C++ project, and develop on windows. (but I would if I wanted to take the time)
If there was an implementation of a full node in C#, I would be able to contribute.

Why are you doing this ? if the alternative implementation is not in consensus with bitcoin core, they will be forced to evolve or just die.
If you prefer not having diversity, I don't understand why you would waste your time saving other implementations, you have more important to do. Why not just letting them die ?

This is a false dichotomy.  Bitcoin Core is free / open source software. It isn't owned by anyone. Anyone is free to make their own modifications, run arbitrary versions of their own choosing from arbitrary sources, and people do. Even within one project the participants don't report to any authority except themselves.  Your argument actually cuts the other way when more diversity spreads thinner the review resources required to ensure that any implementation does what its users (or even its authors) thinks it does.

I think Hhanh00 comment about burden is weird; I am stuck reviewing redundant code in several language which I am not qualified to review in, and dealing with unfamiliar codebases because I have to cope with the mitigating interoperability risk created by other implementations. Node diversity is an significant cost to anyone working on the Bitcoin system who is not punting on dealing with the risk of the whole thing faulting. I am probably losing about 20% of my review time due to alternative implementations already, we have protocol enhancements hung up on concern that they'll just simply be rejected by other implementations (some of which are not very actively maintained relative to Bitcoin Core), etc.: It's a big enough task that people struggle to get things working, keeping up and working with the community is seemingly too much to ask for some. This isn't a cost we complain about-- it's a necessary consequence of an open system that people can (and inevitably will) do some of this--, but it very much is one. (This also holds for wallets and other tools, not just full nodes: I am not a developer of Bitcoin Core. I am a developer for the Bitcoin system as a whole, Bitcoin core just-- in my view-- is one of the most leveraged places to do work to benefit the Bitcoin system today.  That said, I have found and reported critical security vulnerabilities and design flaws in many wallets, services, and underlying infrastructure, sometimes fixing them by changes to the Bitcoin system when doing so appeared to be the best approach. These things are true for many of the other people who work on Bitcoin Core: We generally tend to take our share of the responsibility for the system as a whole, not exclusively the parts of it we work on most directly; as I've pointed out before: your own software being correct but not agreeing with other people is no great success in this space. Increasing ecosystem software diversity does not reduce the burden, beyond the point that it's best if no one program is asked to accommodate all possible needs.)

The risk of having a centralized core team for bitcoin against the risk of a fork for 2 incompatible implementations.
This is a trade-off that the market will choose. I think that right now the risk of fork out weight the benefit. But maybe the market will think otherwise with a high quality alternative.

If you have demand for it, then maybe it is a good idea.

Well - in my opinion, it's not a sustainable long term situation. I understand there are a lot of factors at play but putting the burden of all the core client work on a single implementation is an unfair responsibility to carry. Besides, it seems that some companies are willing to take the risk of running alternate clients. In my case, I simply aim to be at least as good as them while having a code base that I can be proud of.

My original intention was to build a full node with NBitcoin.
I quickly abandoned the idea, you can't imagine the number of corner case you have to take care of... and it is a moving target.
Frankly speaking, I learned to appreciate the work that core developers were doing when I tried to do it by myself. It is boring, difficult, and high in responsability.

As DeathAndTaxes said, I end up having my own bitcoind, and my software connect directly to the trusted node.
100% is not possible, and you can expect that if the reward is worth it, an attacker will end up exploiting the 0,00000001%

I know it is possible to get that far in a few months, as I did myself.

The emphasis is on 100% in this discussion, that is unlikely to be reached with an unrelated code base. This is not just a theoretical problem, since the smallest disagreement is suitable to fork your node off the majority. How much that costs depends on your use.

The combo satoshi border router + SPV extension is simply a much safer bet if you really deal with money.

Mmmm - well, it bootstraps, syncs and validates the blockchain. It passes the acceptance tests from Matt too. As a relay node, it keeps a tx pool, validates, relays new tx and you can trim old blocks just by deleting files. I've been running for a while.
At about 2k lines of code, it fits my requirement of small code that I can fit in my brain but I understand it's not 100% compatible and will never be.

A wallet disabled, UI stripped satoshi client is the closest you can get at the moment to a small consensus compatible full validation.
I wish one could exclude also RPC code at compile time.

Your own code that goes beyond SPV could help understanding, aid debugging or define a side chain.

Good advice but that defeats the reason I'm running my node. I'd like something small, light on memory usage and disk space that still does full validation. I ended up writing it myself.

This is a very good advice.

I'd add that your code should do SPV validation, then a split with respect to the border router is limited to common bugs on your side.