I think you are confusing things here. Block validation does not have much to do with policy. Every node has to run the same block validation checks or risk inadvertently forking itself off, or getting forked off by an attacker feeding it a specially crafted block, and falling out of consensus. My choice as a user would be running Bitcoin Core, but I could also be running btcd, or libbitcoin, as long as they implement the exact same checks in their validation logic. Bitcoin Knots just re-uses the exact same block validation logic that Bitcoin Core does, so there is no difference there. We all have to apply the same logic, or risk falling out of consensus.
The difference that policy makes in the case where a Bitcoin Core and Bitcoin Knots client enforces different policy rules is that if a transactions enters a Bitcoin Core client's mempool, and is then included in a newly mined in a block, Bitcoin Core does not have to re-request the transaction from a peer and can validate the block with the transaction it already has. If Bitcoin Knots on the other hand does not have the transaction yet, it requests it from a peer first, and then validates the block with it. In the end, the result is the same. Both nodes validate the block in the same manner, persist the same block of transactions to disk, and have the same view of the set of unspent transaction outputs. Applying the same block validation rules is the consensus all nodes have to maintain with each other and policy does not really play into that.
TheCharlatan
npub196…ftlhg
2025-05-01 01:16:58
in reply to nevent1q…a53v
Author Public Key
npub196cr58e3ds70njgqul6ndm3gu4yxxjgx00sp32t95lru5k600u7q2ftlhgPublished at
2025-05-01 01:16:58Event JSON
{
"id": "11b299841dc49bf55e5b4a3f449d9fac79c28ca9a0e052cb7b523a248010c9f4",
"pubkey": "2eb03a1f316c3cf9c900e7f536ee28e5486349067be018a965a7c7ca5b4f7f3c",
"created_at": 1746062218,
"kind": 1,
"tags": [
[
"e",
"0a12bab85037e2b8aabd2fce044e4f7e5feab2272998efce0fbd8396fe29f98f",
"",
"root"
],
[
"e",
"3ab074a273999ec91f9bbb09fe8d4111cb7b69359564da34959599acccf06be6"
],
[
"e",
"9721ef9705a0288321f2bcd72c9774f47895dce5a431b592c5fbfaecfedd5e85",
"",
"reply"
],
[
"p",
"90eb20364eea23c320b750476b36772b5348bf2960d0d6ba941239a576ca3150"
],
[
"p",
"2eb03a1f316c3cf9c900e7f536ee28e5486349067be018a965a7c7ca5b4f7f3c"
],
[
"p",
"74ffc51cc30150cf79b6cb316d3a15cf332ab29a38fec9eb484ab1551d6d1856"
]
],
"content": "I think you are confusing things here. Block validation does not have much to do with policy. Every node has to run the same block validation checks or risk inadvertently forking itself off, or getting forked off by an attacker feeding it a specially crafted block, and falling out of consensus. My choice as a user would be running Bitcoin Core, but I could also be running btcd, or libbitcoin, as long as they implement the exact same checks in their validation logic. Bitcoin Knots just re-uses the exact same block validation logic that Bitcoin Core does, so there is no difference there. We all have to apply the same logic, or risk falling out of consensus.\n\nThe difference that policy makes in the case where a Bitcoin Core and Bitcoin Knots client enforces different policy rules is that if a transactions enters a Bitcoin Core client's mempool, and is then included in a newly mined in a block, Bitcoin Core does not have to re-request the transaction from a peer and can validate the block with the transaction it already has. If Bitcoin Knots on the other hand does not have the transaction yet, it requests it from a peer first, and then validates the block with it. In the end, the result is the same. Both nodes validate the block in the same manner, persist the same block of transactions to disk, and have the same view of the set of unspent transaction outputs. Applying the same block validation rules is the consensus all nodes have to maintain with each other and policy does not really play into that.",
"sig": "b76bcc64f66294e803a38ab27f12e5c9e6164651881ad89ac12b1c831efb53e92817c19d55dd1e086e86ab345195900ac25c84f95909e08d3dd0d8cdd35e01e3"
}