Is there any full node implementation 100% compatible with the core client?

[hhanh00]

100%... not 99.999%. I know it's very difficult.
Do the miners actually use bitcoin core too?

[PRab]

Compatible in what way? RPC, P2P, consensus code?

[hhanh00]

Compatible in what way? RPC, P2P, consensus code?

consensus code

[PRab]

I think the best answer is "we don't know". Even bitcoin core has been found to not be 100% compatible with itself (https://bitcoin.org/en/alert/2013-03-11-chain-fork).

I believe that btcd(https://github.com/conformal/btcd) passes all known consensus tests and I have been running a node for months without forking. I don't know exactly what you are trying to accomplish, but your best approach is likely to pick a client that meets your needs and automate what you want to happen if/when a fork occurs. Even if you are on the "correct" side of the fork, if there are 2 competing forks the most prudent behavior is likely to shutdown until one fork significantly outpaces the other.

[amaclin]

Compatible in what way? RPC, P2P, consensus code?

consensus code

OK. Lets try "exception method".
What are the implementations which are not 100% compatible?

[hhanh00]

I think the best answer is "we don't know". Even bitcoin core has been found to not be 100% compatible with itself (https://bitcoin.org/en/alert/2013-03-11-chain-fork).

I believe that btcd(https://github.com/conformal/btcd) passes all known consensus tests and I have been running a node for months without forking. I don't know exactly what you are trying to accomplish, but your best approach is likely to pick a client that meets your needs and automate what you want to happen if/when a fork occurs. Even if you are on the "correct" side of the fork, if there are 2 competing forks the most prudent behavior is likely to shutdown until one fork significantly outpaces the other.

Like several people I am writing a full node for educational purposes and I want to do a good job. Its structure is quite different than other implementations (I reviewed a few) because it's in a functional language and therefore I'm sure it's not the same as bitcoin core. Unfortunately, testing is difficult because verifying a block is biased towards accepting. If your implementation rejects a block that has a valid hash, you are wrong simply because no miner would produce a bad block today. So you might as well have 'return true'.
Bitcore has a series of tests but i'm not using c++ and I'd need to port them.
Your link refers to some trip test that I will try out. Any suggestions are welcome.

[gmaxwell]

I would bet any amount of money that none of the complete reimplementation that I am aware of are consensus consistent.

If you're doing something for educational purposes, then obviously the stakes are less severe. If the prospect of inventing novel ways to assure consistency excites you, then you should do so enlighten the world... but if it doesn't, why are you implementing a Bitcoin full node?  Effectively, achieving consistency _is_ the tasks, if you don't enjoy that tasks you'd probably be better of finding a project to work on that where you do enjoy the work of it.

[tl121]

Bitcoin 0.10.0rc1 is not 100% compatible with bitcoin 0.9.3 via the RPC interface.  As a result it does not work with the current version of Electrum Server github.

[tl121]

I would bet any amount of money that none of the complete reimplementation that I am aware of are consensus consistent.

If you're doing something for educational purposes, then obviously the stakes are less severe. If the prospect of inventing novel ways to assure consistency excites you, then you should do so enlighten the world... but if it doesn't, why are you implementing a Bitcoin full node?  Effectively, achieving consistency _is_ the tasks, if you don't enjoy that tasks you'd probably be better of finding a project to work on that where you do enjoy the work of it.

You could be right, but if that's the case then either these alternate implementations do not pass all of your consensus tests (in which case they are definitely at fault) or the bitcoin core product must be considered to have one or more serious bugs in either the code or the consensus test suite. 

[hhanh00]

You could be right, but if that's the case then either these alternate implementations do not pass all of your consensus tests (in which case they are definitely at fault) or the bitcoin core product must be considered to have one or more serious bugs in either the code or the consensus test suite.  

Bugs are acceptable in consensus code. English has plenty of exceptions in grammar and spelling but as long as we follow them we understand each other.

I would bet any amount of money that none of the complete reimplementation that I am aware of are consensus consistent.

If you're doing something for educational purposes, then obviously the stakes are less severe. If the prospect of inventing novel ways to assure consistency excites you, then you should do so enlighten the world... but if it doesn't, why are you implementing a Bitcoin full node?  Effectively, achieving consistency _is_ the tasks, if you don't enjoy that tasks you'd probably be better of finding a project to work on that where you do enjoy the work of it.

I'm implementing a full node for a couple of things. 1. to make sure i have a complete understanding of the implementation that goes beyond reviewing code. For me, it's like reading a book versus writing one. 2. all the implementations i have seen follow a similar logic specially wrt blockchain management and scripting. i wanted to do it my way to see if it's better or worse. 3. i'm aiming for short. no wallet, no mining, no dos protection.
These goals in mind, it is clearly not fit for wide distribution. It's working fine though - being able to sync up from the beginning while validating, holding a mempool content identical to the core client and etc. But it's reaching a point of diminishing returns. The consensus rules I know I'm not implementing add weight but aren't particular challenging. So I was thinking about looking at another guy who faced the same problem to see where the road ends and whether it's worth going the extra few miles. If no one is consensus consistent then I need to revisit my plan.

[justusranvier]

Compatible in what way? RPC, P2P, consensus code?

consensus code

OK. Lets try "exception method".
What are the implementations which are not 100% compatible?

All of them, including Bitcoin Core.

[gmaxwell]

including Bitcoin Core.

There has at least not been a new version so far which introduce an incompatibility, that we know of (frequently repeated _incorrect_ claims otherwise aside.). It wouldn't be the most shocking thing; but enormous effort goes into preventing it.

So I was thinking about looking at another guy who faced the same problem to see where the road ends and whether it's worth going the extra few miles.

BlueMatt wrote a pretty extensive agreement testing framework and discovered several corner cases that were not previously known. He's generally of the opinion that achieving a correct reimplementation is more or less intractable. His approach made progress, especially in unearthing weird behaviours, but doesn't result in great confidence of soundness; and doesn't show an implementation free of its own buts not related to non-obvious behavior in Bitcoin Core.  Our strategy in Bitcoin Core as of late has been toward compartmentalizing and simplifying in order to make code reuse more reasonable; and also get things structured to be more agreeable to approaches that would possibly make formal analysis more realistic, but thats a long term effort.

[justusranvier]

It wouldn't be the most shocking thing; but enormous effort goes into preventing it.

Which is equally true for alternate implementations.

Since it's not possible for any implementation of Bitcoin to prove perfect compatibility with own present and past versions, treating any single implementation as special is incorrect.

They're all alternate implementations.

[grau]

It wouldn't be the most shocking thing; but enormous effort goes into preventing it.

Which is equally true for alternate implementations.

Since it's not possible for any implementation of Bitcoin to prove perfect compatibility with own present and past versions, treating any single implementation as special is incorrect.

They're all alternate implementations.

To be fair, it is easier to keep an implementation consensus compatible with its prior versions, than to achive consensus compatibility with an unrelated code base.

I think that the best option for alternate implementations is to define a side chain that is attractive for reasons other than their token, so value migrates to them.

[justusranvier]

I think that the best option for alternate implementations is to define a side chain that is attractive for reasons other than their token, so value migrates to them.

Trying to make value flow out of the Bitcoin blockchain is the same as trying to kill Bitcoin.

I wouldn't call software whose purpose in life was to extract value from the blockchain an "alternate implementation" - I'd call it an attack.

[grau]

I think that the best option for alternate implementations is to define a side chain that is attractive for reasons other than their token, so value migrates to them.

Trying to make value flow out of the Bitcoin blockchain is the same as trying to kill Bitcoin.

I wouldn't call software whose purpose in life was to extract value from the blockchain an "alternate implementation" - I'd call it an attack.

It is called competition. It is what makes things strong.

[justusranvier]

I think that the best option for alternate implementations is to define a side chain that is attractive for reasons other than their token, so value migrates to them.

Trying to make value flow out of the Bitcoin blockchain is the same as trying to kill Bitcoin.

I wouldn't call software whose purpose in life was to extract value from the blockchain an "alternate implementation" - I'd call it an attack.

It is called competition. It is what makes things strong.

Of course.

You don't call your competitors "teammates", however.

Software that tries to compete with Bitcoin is not an alternate implementation of Bitcoin - it is a competitor to Bitcoin.

[grau]

I think that the best option for alternate implementations is to define a side chain that is attractive for reasons other than their token, so value migrates to them.

Trying to make value flow out of the Bitcoin blockchain is the same as trying to kill Bitcoin.

I wouldn't call software whose purpose in life was to extract value from the blockchain an "alternate implementation" - I'd call it an attack.

It is called competition. It is what makes things strong.

Of course.

You don't call your competitors "teammates", however.

Software that tries to compete with Bitcoin is not an alternate implementation of Bitcoin - it is a competitor to Bitcoin.

The consenus of Bitcoin user created a new type of asset that is not limited to the features supported by the original code.

If people decide to move their asset to an other chain, they do it because they think it offers them something higher value.

They might be right or wrong.
- Assuming they are right, then side chains adds value to the ecosystem.
- Assuming they are wrong, then supply of Bitcoin shrinks and those sticked with it enjoy appretiation.

[hhanh00]

I ran Matt's test harness on bitcoin core 0.9.3 and an assertion was raised. Then I tried on my code and realized that the test harness relies on a specific message order or it deadlocks. After that I started debugging the test harness and got a headache. Maybe it is time to surrender.

[hhanh00]

@grau & @justus, no offense but your debate is quite off-topic. If you must discuss the pros/cons of alternate implementations on altcoins, could you create your own thread?