Bitcoin Verde is constantly being evaluated to ensure we're staying competitive, up-to-date, and providing real value to the Network. Check out our roadmap to see what's under development and what's been complete below.
In 2022 we focused on shoring up Bitcoin Verde as a mining node and proving its viability. We were successful with our goals and mined our first BCH block with Bitcoin Verde!
In 2021 we outlined 6 primary changes and features we believe provide the most immediate value to our implementation and community. The primary focus of these changes: increasing the viability for network operators to choose Bitcoin Verde and increasing retail adoption through improvements to the network.
Bitcoin Verde has completed our 2020 Flipstarter with all development goals met. This achievement has resulted in 4 primary changes/upgrades to our implementation.
This extension is to expand support to the full Bitcoin JSON-RPC protocol, allowing Bitcoin Verde to become a drop-in replacement for other nodes when supporting services.
Bitcoin Verde's default RPC API is a custom API, not compatible with the traditional Bitcoin JSON-RPC API. Our implementation's lack of JSON-RPC compatibility has created a barrier between our client, business owners, and developers as the unfamiliarity with the current custom RPC API makes Bitcoin Verde difficult to use even for seasoned users. Improving our implementation to be fully compatible with Bitcoin Core JSON-RPC will allow users to more easily setup, connect to, and begin using a Bitcoin Verde node to support the backend of their service.
In order to verify incoming transactions a node must first be able to recreate the current UTXO state. To do so, the node downloads the entire history of the blockchain--often referred to as the “initial block download” (IBD). With this process taking up to a day, this requirement has proven to be a major barrier to entry.
By providing a validated hash of the UTXO-set at the time a block was created, UTXO commitments are used to greatly reduce the time required to synchronize a node on startup. Functionally, this is particularly useful for businesses interested in running their own node or for developers under time constraints. An example being a CoinParty Hackathon, where developers wanted to run a node for testing, but have limited time to set up.
Bitcoin Verde has been upgraded to be fully compatible with the Electrum Cash 1.4.4 protocol. The Fulcrum API is a drop in replacement for ElectrumX/ElectronX and is fully compatible at the protocol level with Electrum Cash.
This functionality allows Bitcoin Verde to run as an Electron Cash SPV Server, enabling users with electron wallets to connect and communicate with Bitcoin Verde. This addition provides a quality of life improvement for Bitcoin Verde operators interested in running their own Electron Cash wallet, while simultaneously providing Electron Cash end-users additional trusted servers to connect to.
Bitcoin Verde has completed development of the Bitcoin Verde mining pool. Bitcoin Verde's Mining Module has undergone its first real world test on, mining our first block, #721,020 on January 1, 2022. More news to come as it develops.
Pruning mode provides Bitcoin Verde operators the ability to substantially reduce the storage requirements for running their Bitcoin Verde node. When implemented, pruning mode provides a configuration option to trim blocks of a predetermined depth once their contents have been validated.
Double spend proofs provide an elevated user experience by increasing merchants' and wallet-users' willingness to accept unconfirmed transactions. This works by allowing nodes to send and receive a small, standardized message with proof that a sender has signed two separate transactions in an attempt to spend the same BCH twice. This proof can then be further validated by other nodes and users of the network to verify its claim.
This block template validation service is a reverse-proxy/load balancer used to reduce the risk of miners creating an invalid block to near-zero. This is achieved by first validating the template block against other implementations before any work is performed on the block template.
A service is created that is connected to the latest version of multiple node implementations ("validating nodes"):
This service accepts a standard block template from getblocktemplate as specified by BIP-22, BIP-23, BIP-9, and BIP-145.
Once a block template is received, the BitBalancer ensures each validating node has seen each transaction within the template block.
A best effort attempt by the service is made to determine which transaction(s) trigger the invalid state of the template block-- with the invalid transactions identitified, the requester may choose to omit them.
The validating nodes may not be equipped to validate a template block. This solution will:
Providing an implementation for BCHN due to its current majority market share.
Despite being useful for explorers and wallet services, Bitcoin Verde's indexing provided signifcant drawbacks for validation services and no added value for mining nodes. In order to stay competitive, we have developed a non-indexed module of the Bitcoin Verde full-node.
With cacheBlocks, blocks are stored serialized on-disk. Many of the transaction-, address-, and slp-related SQL tables have been removed.
Fully supporting the SLP and Memo actions taken by users provides viable redundancy for other block explorers as well as increases the choice of platform for users and those running their own block explorer.
Bitcoin Verde is now configured to connect to testnet. Connecting to testnet increases our implementation's exposure to edge-case transactions as well as significantly improves our ability to coordinate with other node implementations for hard-fork testing.