What Comprises a Bitcoin Fullnode Implementation
Understanding What Qualifies As a 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.
This post was written in 2017, and in light of recent events, I want to reiterate these points as the community seeks to make the ecosystem more resilient (finally) by respecting alternative fullnode implementations.
What is a Fullnode/What Can They Do?
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 consensus rules of the bitcoin protocol (or the rules pertaining to a particular blockchain-based asset, such as Ethereum). That being said, the criteria that defines the different types of fully validating nodes on a 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, but this is not a direct requirement to be considered a fullnode). 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 ~180gb (historical size data can be found, here)
Since there is no formal specification for bitcoin at present, the reference client (commonly known as Bitcoin Core) is often referenced as the go-to specification for the majority of bitcoin developers. This ensures your implementation remains wholly compliant, and does not fork-off the network.
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 & Coin Dance. 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 (remember: the public blockchain is…public). 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, 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). 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.
Subscribe to our Newsletter to get this in your inbox:
References Used:
https://en.bitcoin.it/wiki/Full_node
https://en.bitcoin.it/wiki/Clearing_Up_Misconceptions_About_Full_Nodes
https://bitseed.org/the-different-kinds-bitcoin-full-nodes/
