Bitcoin Forum
March 29, 2024, 02:52:01 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 »  All
  Print  
Author Topic: Is there any full node implementation 100% compatible with the core client?  (Read 4497 times)
hhanh00 (OP)
Sr. Member
****
Offline Offline

Activity: 467
Merit: 266


View Profile
January 13, 2015, 09:46:31 AM
 #1

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

1711723921
Hero Member
*
Offline Offline

Posts: 1711723921

View Profile Personal Message (Offline)

Ignore
1711723921
Reply with quote  #2

1711723921
Report to moderator
"There should not be any signed int. If you've found a signed int somewhere, please tell me (within the next 25 years please) and I'll change it to unsigned int." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711723921
Hero Member
*
Offline Offline

Posts: 1711723921

View Profile Personal Message (Offline)

Ignore
1711723921
Reply with quote  #2

1711723921
Report to moderator
PRab
Member
**
Offline Offline

Activity: 98
Merit: 10


View Profile
January 13, 2015, 02:02:30 PM
 #2

Compatible in what way? RPC, P2P, consensus code?
hhanh00 (OP)
Sr. Member
****
Offline Offline

Activity: 467
Merit: 266


View Profile
January 13, 2015, 02:07:01 PM
 #3

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

PRab
Member
**
Offline Offline

Activity: 98
Merit: 10


View Profile
January 13, 2015, 02:14:57 PM
 #4

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
Legendary
*
Offline Offline

Activity: 1260
Merit: 1019


View Profile
January 13, 2015, 02:17:51 PM
 #5

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 (OP)
Sr. Member
****
Offline Offline

Activity: 467
Merit: 266


View Profile
January 13, 2015, 03:06:41 PM
 #6

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
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
January 13, 2015, 09:54:23 PM
 #7

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
Sr. Member
****
Offline Offline

Activity: 278
Merit: 251


View Profile
January 14, 2015, 01:05:42 AM
 #8

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
Sr. Member
****
Offline Offline

Activity: 278
Merit: 251


View Profile
January 14, 2015, 01:11:38 AM
 #9

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 (OP)
Sr. Member
****
Offline Offline

Activity: 467
Merit: 266


View Profile
January 14, 2015, 05:27:05 AM
 #10

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
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile
January 14, 2015, 06:01:54 AM
 #11

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
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
January 14, 2015, 07:59:03 AM
Last edit: January 14, 2015, 08:09:40 AM by gmaxwell
 #12

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.

Quote
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
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile
January 14, 2015, 02:34:57 PM
 #13

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
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1021


bits of proof


View Profile WWW
January 14, 2015, 03:13:39 PM
Last edit: January 14, 2015, 04:06:43 PM by grau
 #14

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
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile
January 14, 2015, 04:11:50 PM
 #15

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
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1021


bits of proof


View Profile WWW
January 14, 2015, 04:21:49 PM
 #16

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
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile
January 14, 2015, 04:32:33 PM
 #17

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
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1021


bits of proof


View Profile WWW
January 14, 2015, 05:21:08 PM
 #18

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 (OP)
Sr. Member
****
Offline Offline

Activity: 467
Merit: 266


View Profile
January 14, 2015, 05:25:54 PM
 #19

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 (OP)
Sr. Member
****
Offline Offline

Activity: 467
Merit: 266


View Profile
January 14, 2015, 05:29:13 PM
 #20

@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?

Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!