(1) If coverage is outlined as “every thing that is not consensus”, but these coverage checks are included within the consensus information… what precisely are they doing there? Are they deprecated?
No, not deprecated. There is not a clear dividing line within the Bitcoin Core file system the place say one file solely checks coverage guidelines and one file solely checks consensus guidelines. (See this StackExchange put up from Suhas Daftuar discussing consensus and coverage subdirectories). That is for numerous causes. One is the inheritance of the codebase from Satoshi who created a big bundle of code that though refactored and cleaned up over a decade by Core contributors nonetheless bears a resemblance to what they inherited from Satoshi. Maybe extra importantly it’s actually tough to stipulate what all of the consensus guidelines really are as a result of there are edge instances the place you assume the code you are touching is not consensus associated however then it seems you launched a consensus bug that ends in a possible chain cut up. Pieter Wuille mentioned this on the Chaincode Labs podcast in 2020:
One of many issues I feel discovered from that’s specifying what your consensus guidelines is de facto arduous. That doesn’t imply you possibly can’t attempt however who would’ve thought {that a} configuration setting within the database layer you might be utilizing really leaked semantically into Bitcoin’s implicitly outlined consensus guidelines. You may attribute that to human failure after all. We should always’ve learn the documentation and been conscious of that.
There may very well be a bug in your C library. There generally is a bug in your kernel. There may even be a bug in your CPU.
We are able to discuss in regards to the boundary in making an attempt to summary the a part of the codebase that deliberately contributes to consensus however it is extremely arduous to say clearly this code has no affect on consensus code as a result of bugs can leak. I feel one of many issues to study there may be you actually need software program that’s meant to be used in a consensus system the place not solely you’ve the requirement that if everybody behaves appropriately all people accepts the suitable reply but in addition that everyone will disagree about what’s an invalid piece of information in lockstep.
(2) Are ALL of the consensus guidelines included someplace in these consensus information? I am assuming not. So, I ask…
No. There have been makes an attempt prior to now to create a consensus library (libbitcoinconsensus) and extra not too long ago libbitcoinkernel that Carl Dong has mentioned and contributed to however it’s actually arduous. Consensus is a extremely slippery idea in Bitcoin.
(3) Might we compile an inventory, maybe, of every thing {that a} legitimate block would wish with the intention to be accepted as legitimate that’s NOT already included someplace in these consensus information??
Should you imply like an exhaustive checklist within the English language then you are going to battle. You may attempt and you may most likely embrace many of the apparent issues however it’s the edge instances and issues that appear they’re solely non consensus associated that end up to not be which will probably be lacking.
