Protocol

Bitcoin Protocol Rules

The rules of the Bitcoin protocol are the rules that precisely define the Bitcoin system.

There are different classes of rule in the Bitcoin system including:

  • Immutable rules
  • Mutable rules
  • Communication rules

Immutable Rules

The immutable rules are codified into bitcoin node clients and must be strictly adhered to in order to implement the Bitcoin specification in software [1]. They are a set of rules that define the format and constraints that transactions and blocks must follow. These include:

  • The sum of the value of the inputs of a transaction must be greater than or equal to the sum of the values of the outputs
  • The block subsidy will drop by half at a scheduled rate of every 210,000 blocks, starting with a subsidy of 5,000,000,000 satoshis from the genesis block
  • The network will adjust the target for the difficulty of the Proof of Work needed for a valid block to maintain an approximate 10 minute block discovery rate
  • Only blocks that add to the block chain formed by building upon the Genesis block are valid
  • The structure of the Bitcoin database as a timestamp server validating chains of digital signatures

Additional immutable rules govern such things as:

  • Transactions data formatting, including sizes of certain fields and their encoding schema
  • Block structure and header information including sizes of certain fields and their encoding schema
  • The Bitcoin scripting language and its specification

Changes to these protocol rules in the past have resulted in network forks that duplicated the database such as BTC which removed the requirement for Bitcoin to be a chain of digital signatures, and BCH which modified the timestamping aspect of the system.

The Bitcoin SV philosophy is that where these rules have been changed in the past they should be returned to be as close to the original rules as possible and then “set in stone”, will no further changes allowed, enforced through Nakamoto Consensus.

Policy Rules

Policy rules are “optional” or “non-mandatory” rules that clients implement. An example is the “minimum fee” rule, which specifies that the node will only accept and relay unconfirmed transactions that pay above a certain fee. Some nodes will refuse to accept transactions that do not comply with this rule but policy rules are not consensus rules. If a transaction is present in a block which violates a policy rule but complies with the consensus rules, then the transaction and block is valid.

Local Policies

Policies are “local” by definition. They apply to the instance of software that is running, they do not apply to the validation of blocks, or the transactions within a block. A block accepted from another miner may contain transactions that do not conform to local policy.

Standard Policies

Common local policies that are used by a significant proportion of network nodes. They are defined as a "Standard" to facilitate common application across independent software implementations but it is important to note that it is not required that software implement or adhere to these policies.

P2P Protocol

The P2P Protocol is a well defined method for Bitcoin nodes to communicate. The P2P Protocol can change and a re-implementation is planned for the future. Software can use any method of communication. A large amount of the innovation that scales Bitcoin SV is done by improving the peer-to-peer protocol.

See Also

References

[1] - https://github.com/bitcoin-sv-specs/protocol/blob/master/updates/genesis-spec.md