Does version of Bitcoin Core determine my consensus?

Question

As far as (voting) on the network? I run a full node, but do not mine. I hear people say we have a choice when changes are made.

Is it the version of Core that determines that?

Answer 1

There is no vote on what the rules of the network are, and your own node has no influence on the rules other nodes enforce.

Fully validating nodes (aka full nodes) locally enforce all rules of the Bitcoin protocol. A node operator expresses what they consider to be Bitcoin by deciding which node software to run. Since a node will reject any blocks or transactions that break its rules, the node operator can be sure that whatever blockchain their node shows follows the rules that they wish to enforce.

If a majority of the hashrate enforces stricter rules than some node, the stricter ruleset will produce blocks that are acceptable to those with looser rules. This can be used to introduce rule changes in a so-called soft fork: soft forks tighten rules and thus are forward-compatible to less-strict Bitcoin software. This makes the general rules on the network emergent. The network rules emerge from many users making a choice about the software they are running and the common denominator being enforced by the economic majority.

However, if a minority of the nodes enforces stricter rules than the majority of the network (without support of a majority of the hashrate), they will reject the longest chain and end up stuck on a stale chaintip.

To give some concrete examples:

• a miner may choose to miner smaller blocks than allowed
• a miner may choose to exclude inscriptions from their blocks
• a node that unilaterally decides not to accept blocks with inscriptions will stop following the best chain
• a miner that mines a bigger block than the majority of the network permits will see its block rejected

Answer 2

You are on the right track, I will attempt to explain from what I understand. Just be aware this could be inaccurate, do your own research beyond what I or anyone else says.

Bitcoin versions represent what are known as Soft Forks . The consensus code does not change meaning none of the original coin owners lose access to their coins, and they are also not forced to upgrade their clients(they may still want to though for other reasons which I will mention at the end).

As far as I have read, old nodes will just strip away extra data that they see as irrelevant to the transaction making it impossible for anyone with that node to USE said stripped data for a further transaction. However an upgraded node could be coded to keep that data and therefore use it to spend coins in an upgraded way that makes uses of the extra data. Now the old node has the same chain as the new node but it just cannot help anyone looking to make a transaction out of an updated output.

As I mentioned earlier there are reasons people may feel willing to upgrade their nodes, one obvious one is a reduction in future chain storage space or transaction fee cost. If there is an update that improves this it is unlikely that no one would adopt it. That being said it is set up in a way that no one HAS to adopt it because everyone verifying the chain can do with the data as they please as long as it is the correct verifiable data.

So YOU as a node runner are enforcing potential scalability on bitcoin, or any other potential soft-fork updates that may come down the line. In a sense your node is your vote and you can vote with more nodes however technically now miners have to include the transactions from a node into the blockchain. As long as the outputs being spent are valid technically they could be included in an old nodes tx pool (i am speculating i could be dead wrong here) but it is still unlikely as I assume they would just flag it as an nonstandard transaction. Not sure how that plays out, maybe its fine and the miners dont have to update? Like I said I could be dead wrong about this last part, but either way, as a node runner you're opting into supporting fee-reducing transactions that also enable backwards compatibility and reduction of block-space-bloat.

Answer 3

As far as (voting) on the network? I run a full node, but do not mine. I hear people say we have a choice when changes are made.

Assuming there is a soft fork (consensus change) activation attempt in progress you as a full node operator have three choices. You can run the latest version of Bitcoin Core which generally would include the new consensus rules and enforce those new rules. You can run an older version of Bitcoin Core which wouldn't include the new consensus rules or enforce them but because it is a soft fork (rather than a hard fork) this wouldn't fork you off the network. Or you could run an alternative client (if it exists) that either seeks to force through activation of that soft fork (user activated soft fork, UASF) or seeks to resist activation of that soft fork (user resisted soft fork, URSF). Consensus changes are very high stakes (they can cause chain splits and network splits) so at least in my opinion they should occur rarely, with ultimate caution and unless the user knows exactly what risks they are taking on they shouldn't deviate from their usual software practices.

Is it the version of Core that determines that?

The version of Bitcoin Core will determine whether it enforces the new consensus rules or not, yes. Very old versions of Bitcoin Core (pre v0.16) don't enforce SegWit or Taproot consensus rules for example. It is theoretically possible that a consensus change could be attempted without Bitcoin Core enforcing those new rules and without that code being merged into Bitcoin Core. But given Bitcoin Core's dominance on the network it would be difficult to activate a consensus change in this way.