<blockquote>
<p>(1) If policy is defined as &quot;everything that isn't consensus&quot;, yet those policy checks are included in the consensus files... what exactly are they doing there? Are they deprecated?</p>
</blockquote>
<p>No, not deprecated. There isn't a clean dividing line in the Bitcoin Core file system where say one file only checks policy rules and one file only checks consensus rules. (See this StackExchange <a href="https://bitcoin.stackexchange.com/questions/100317/what-is-the-difference-between-policy-and-consensus-when-it-comes-to-a-bitcoin-c">post</a> from Suhas Daftuar discussing consensus and policy subdirectories). This is for various reasons. One is the inheritance of the codebase from Satoshi who created a large bundle of code that although refactored and cleaned up over a decade by Core contributors still bears a resemblance to what they inherited from Satoshi. Perhaps more importantly it is really difficult to outline what all the consensus rules actually are because there are edge cases where you think the code you're touching isn't consensus related but then it turns out you introduced a consensus bug that results in a potential chain split. Pieter Wuille discussed this on the Chaincode Labs <a href="https://btctranscripts.com/chaincode-labs/chaincode-podcast/2020-01-28-pieter-wuille/" rel="nofollow noreferrer">podcast</a> in 2020:</p>
<blockquote>
<p>One of the things I think learned from that is specifying what your consensus rules is really hard. That doesn’t mean you can’t try but who would’ve thought that a configuration setting in the database layer you are using actually leaked semantically into Bitcoin’s implicitly defined consensus rules. You can attribute that to human failure of course. We should’ve read the documentation and been aware of that.</p>
<p>There could be a bug in your C library. There can be a bug in your kernel. There can even be a bug in your CPU.</p>
<p>We can talk about the boundary in trying to abstract the part of the codebase that intentionally contributes to consensus but it is very hard to say clearly this code has no impact on consensus code because bugs can leak. I think one of the things to learn there is you really want software that is intended for use in a consensus system where not only you have the requirement that if everyone behaves correctly everybody accepts the right answer but also that everybody will disagree about what is an invalid piece of data in lockstep.</p>
</blockquote>
<blockquote>
<p>(2) Are ALL of the consensus rules included somewhere in these consensus files? I'm assuming not. So, I ask...</p>
</blockquote>
<p>No. There have been attempts in the past to create a consensus library (libbitcoinconsensus) and more recently libbitcoinkernel that Carl Dong has <a href="https://btctranscripts.com/chaincode-labs/2022-04-12-carl-dong-libbitcoinkernel/" rel="nofollow noreferrer">discussed</a> and contributed to but it is really hard. Consensus is a really slippery concept in Bitcoin.</p>
<blockquote>
<p>(3) Could we compile a list, perhaps, of everything that a valid block would need in order to be accepted as valid that is NOT already included somewhere in these consensus files??</p>
</blockquote>
<p>If you mean like an exhaustive list in the English language then you're going to struggle. You can try and you can probably include most of the obvious things but it is the edge cases and things that seem they are entirely non consensus related that turn out not to be which will be missing.</p>

CC BY-SA 4.0
2024-01-30T09:32:53.297Z
2024-01-30T09:55:47.840Z
2024-01-30T09:55:47.840Z
Michael Folkson
<p>I asked this question before, and it was quickly locked and pointed to a thread about mempool policy... yet my question remains unanswered.</p>
<p>Let it be known, I don't want to know what policy is [or is not], any further than understanding why policy is included in the Consensus code as seen in the following locations:</p>
<p><a href="https://github.com/bitcoin/bitcoin/blob/master/src/consensus/" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/master/src/consensus/</a>
<a href="https://github.com/bitcoin/bitcoin/blob/master/src/consensus/amount.h" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/master/src/consensus/amount.h</a>
<a href="https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h</a>
<a href="https://github.com/bitcoin/bitcoin/blob/master/src/consensus/validation.h" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/master/src/consensus/validation.h</a></p>
<blockquote>
<p>TX_INPUTS_NOT_STANDARD,   //!&lt; inputs (covered by txid) failed policy rules</p>
</blockquote>
<blockquote>
<p>TX_NOT_STANDARD,          //!&lt; otherwise didn't meet our local policy rules</p>
</blockquote>
<blockquote>
<p>TX_MEMPOOL_POLICY,        //!&lt; violated mempool's fee/size/descendant/RBF/etc limits</p>
</blockquote>
<blockquote>
<p>TX_RECONSIDERABLE,        //!&lt; fails some policy, but might be acceptable if submitted in a (different) package</p>
</blockquote>
<p>(1) If policy is defined as &quot;everything that isn't consensus&quot;, yet those policy checks are included in the consensus files... what exactly are they doing there?  Are they deprecated?</p>
<p>(2) Are ALL of the consensus rules included somewhere in these consensus files?  I'm assuming not.  So, I ask...</p>
<p>(3) Could we compile a list, perhaps, of everything that a valid block would need in order to be accepted as valid that is NOT already included somewhere in these consensus files??</p>

<transactions><blockchain><block><protocol><consensus>
What are ALL the consensus rules?
DoctorBuzz1
# What are ALL the consensus rules?

(Asked by: username_0 on 2024-01-30)

I asked this question before, and it was quickly locked and pointed to a thread about mempool policy... yet my question remains unanswered.

Let it be known, I don't want to know what policy is [or is not], any further than understanding why policy is included in the Consensus code as seen in the following locations:

<https://github.com/bitcoin/bitcoin/blob/master/src/consensus/>
<https://github.com/bitcoin/bitcoin/blob/master/src/consensus/amount.h>
<https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h>
<https://github.com/bitcoin/bitcoin/blob/master/src/consensus/validation.h>

> TX\_INPUTS\_NOT\_STANDARD, //!< inputs (covered by txid) failed policy rules

> TX\_NOT\_STANDARD, //!< otherwise didn't meet our local policy rules

> TX\_MEMPOOL\_POLICY, //!< violated mempool's fee/size/descendant/RBF/etc limits

> TX\_RECONSIDERABLE, //!< fails some policy, but might be acceptable if submitted in a (different) package

(1) If policy is defined as "everything that isn't consensus", yet those policy checks are included in the consensus files... what exactly are they doing there? Are they deprecated?

(2) Are ALL of the consensus rules included somewhere in these consensus files? I'm assuming not. So, I ask...

(3) Could we compile a list, perhaps, of everything that a valid block would need in order to be accepted as valid that is NOT already included somewhere in these consensus files??

**Tags:** transactions, blockchain, block, protocol, consensus


---

## 1 answers

### Answer by username_1 on 2024-01-30. Score: 2

> (1) If policy is defined as "everything that isn't consensus", yet those policy checks are included in the consensus files... what exactly are they doing there? Are they deprecated?

No, not deprecated. There isn't a clean dividing line in the Bitcoin Core file system where say one file only checks policy rules and one file only checks consensus rules. (See this StackExchange [post](https://bitcoin.stackexchange.com/questions/100317/what-is-the-difference-between-policy-and-consensus-when-it-comes-to-a-bitcoin-c) from Suhas Daftuar discussing consensus and policy subdirectories). This is for various reasons. One is the inheritance of the codebase from Satoshi who created a large bundle of code that although refactored and cleaned up over a decade by Core contributors still bears a resemblance to what they inherited from Satoshi. Perhaps more importantly it is really difficult to outline what all the consensus rules actually are because there are edge cases where you think the code you're touching isn't consensus related but then it turns out you introduced a consensus bug that results in a potential chain split. Pieter Wuille discussed this on the Chaincode Labs [podcast](https://btctranscripts.com/chaincode-labs/chaincode-podcast/2020-01-28-pieter-wuille/) in 2020:

> One of the things I think learned from that is specifying what your consensus rules is really hard. That doesn’t mean you can’t try but who would’ve thought that a configuration setting in the database layer you are using actually leaked semantically into Bitcoin’s implicitly defined consensus rules. You can attribute that to human failure of course. We should’ve read the documentation and been aware of that.
>
> There could be a bug in your C library. There can be a bug in your kernel. There can even be a bug in your CPU.
>
> We can talk about the boundary in trying to abstract the part of the codebase that intentionally contributes to consensus but it is very hard to say clearly this code has no impact on consensus code because bugs can leak. I think one of the things to learn there is you really want software that is intended for use in a consensus system where not only you have the requirement that if everyone behaves correctly everybody accepts the right answer but also that everybody will disagree about what is an invalid piece of data in lockstep.

> (2) Are ALL of the consensus rules included somewhere in these consensus files? I'm assuming not. So, I ask...

No. There have been attempts in the past to create a consensus library (libbitcoinconsensus) and more recently libbitcoinkernel that Carl Dong has [discussed](https://btctranscripts.com/chaincode-labs/2022-04-12-carl-dong-libbitcoinkernel/) and contributed to but it is really hard. Consensus is a really slippery concept in Bitcoin.

> (3) Could we compile a list, perhaps, of everything that a valid block would need in order to be accepted as valid that is NOT already included somewhere in these consensus files??

If you mean like an exhaustive list in the English language then you're going to struggle. You can try and you can probably include most of the obvious things but it is the edge cases and things that seem they are entirely non consensus related that turn out not to be which will be missing.


---

