What Comprises a Bitcoin Fullnode Implementation?

Often times in the press I see a lot of confusion around what a fullnode implementation of bitcoin actually is. I saw this as a great opportunity to try and break things down as simply as possible, with everything compiled into one place. Hopefully this helps clear up any confusion. Special thanks to Matt Corallo (Core Developer) and my colleagues for helping with the initial drafts. 🙂

What is a Fullnode?

A bitcoin fullnode, put simply, can act as a backbone to the bitcoin network, even if all other nodes are knocked offline. Fullnodes, by definition, should be able to fully comply with the unique rules of the bitcoin protocol. That being said, the criteria that defines the different types of fully validating nodes on the network vary slightly; but there does, for the most part, exist an universally accepted standard.

In short, an effective fullnode will verify each block of incoming transactions it receives to ensure that everything in that block is fully “valid” (adhering to all consensus rules) — this allows that fullnode to trust the block’s overall integrity, without specifically trusting the miner who created it.

In order to adhere to bitcoin’s consensus ruleset, your fullnode will need to be able to validate the following:

• Verify that transactions in each particular block have all the correct signatures for the bitcoin currently being spent.
• Ensures that each block may only create a certain number of bitcoin per block (which is currently 12.5 BTC).
• Checks that transactions/blocks are submitted in the correct data format.
• Verifies that within the blockchain, no transactional output has been double-spent.

Fullnodes as described above (there are other rules as well, but they fall outside the scope of this post) are effectively active participants in the bitcoin network. These nodes are constantly validating whether transactions/blocks are following all consensus rules. They can also serve the purpose of relaying blocks to other fullnodes in the network (if port-forwarding is enabled, more on this further down). These are the requirements that ensure that bitcoin’s blockchain remains immutable (unalterable), and its security intact.

The current blockchain database size, once fully downloaded and validated, is currently ~110gb (historical size data can be found, here)

A good fullnode implementation will always ensure they’re are wholly compliant during development with the current consensus rules present in the reference implementation of bitcoin (commonly known as Bitcoin Core). Since there is no formal specification for bitcoin at present, the reference client is commonly referenced as the go-to specification for the majority of bitcoin developers.

Optional Requirements: Some fullnodes help to relay transactional information to other nodes, and are usually run by services such as exchanges, block explorers, and miners (often referred to as “Economic Fullnodes”).

P2P Network Services
Fullnodes, while also existing to validate the consensus ruleset, may also provide various other services to active participants in the P2P network.

These additional services also play a key role in securing lightweight nodes (SPV clients) to ensure they have accurate transactional information since they don’t process the entire blockchain and must reference a fullnode to sync accordingly.

Services provided by fullnodes can include:

• Serving valid historical blockchain data to new nodes that are syncing with the network so they may stay up-to-date; therefore they must keep a full, recent backup of bitcoin’s transactional database.
• Transmitting new transactions on the network and assisting in propagating them from users← →miners, to other active nodes in the network.
• Filtering/validating all of the networks incoming/outcoming transactions, so that SPV nodes (lightweight clients) can also validate the network and not have to download every transaction ever made on the network in order to find/process their own transactions.
• Mining; originally this was a core aspect of Bitcoin Core codebase; since then, bitcoin mining has evolved to incorporate the use of ASICs overtime. Although, definitionally, a full node historically would also mine as well, this particular requirement has been removed as a qualification for most. Only miners now are typically concerned with fullnodes that support mining (like Bitcoin Core, and Bcoin).

The bulk of these services are offered by fullnodes after they’ve enabled incoming connections by port-forwarding their node to port 8333. The more full nodes accepting incoming connections, the more secure/decentralized the overall bitcoin network is. Nodes can be run by individuals, or businesses. However, many services often opt to run a fullnode in the cloud too (think AWS/Google Cloud). By running an instance of their fullnode in the cloud, companies/developers can ensure they have a fixed node to constantly archive/backup the entire blockchain, in order to query it at their leisure.

You can always view the number of active, port-forwarding nodes on the network with sites like Bitnodes & NodeCounter. However it is important to note that some people (i.e. privacy-centric individuals) do not wish to forward their ports; or perhaps bandwidth is too expensive for them locally. We can make decent approximations, but for the most part the total real number of active nodes is, unknown. And that’s okay! Bitcoin’s decentralization is not dependent upon knowing what everyone is up to with their wallets. :)

Open ports help the bitcoin network bootstrap new nodes by uploading historical blocks to new nodes who are syncing. Bitcoin’s P2P network serves to help aid in censorship resistance; as long as there is a copy of the record somewhere (whether that’s a server, or stored on some uncensorable decentralized network), bitcoin will carry on and prosper.

Advantages of Running a Fullnode

Security, first and foremost! SPV Nodes don’t process the full blockchain, which can put them at risk of accepting transactions or blocks that are not valid. Unless that particular service is running a concurrent instance of a consensus validating fullnode to cross-check their own transactions, invalid blocks/transactions could be automatically processed, causing potential financial damage/loss for the service/users.

Privacy, being your own bank means complete financial control. By running a fullnode, you can help ensure your transactions remain private as possible. Most web-based wallets and services utilize SPV nodes, thus they have to outsource their verification to third-party servers (this includes your addresses 😧) . Those services know which addresses are yours, and can, without much effort, link them together to infer ownership of funds in those addresses balances. To get the full power of the bitcoin network, and maintain pseudo-anonymity, you should run a fullnode.

Closing Up

Fullnodes are pivotal for the bitcoin network, the most notable/widely used bitcoin fullnode implementations capable of fully validating the network as described above include: NBitcoin (C#), btcd (Go), bitcoind (C++), and now, bcoin (Node.js) and Bitcoin Knots (C++). The proliferation and adoption of these various implementations are a crucial component in keeping bitcoin’s development decentralized, with as many technical subject matter experts as possible distributed all over the globe.

References Used:
https://en.bitcoin.it/wiki/Full_node
https://en.bitcoin.it/wiki/Clearing_Up_Misconceptions_About_Full_Nodes