Features &
Roadmap

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.


2021

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.

2020

Bitcoin Verde has completed our 2020 Flipstarter with all development goals met. This achievement has resulted in 4 primary changes/upgrades to our implementation.

Under Development

RPC Compatibility

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.

Complete Features

UTXO Commitments

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.

Electron Cash (FULCRUM API) Compatibility

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 Mining Pool

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

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

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.

Block Template Validation Service - The BitBalancer

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.

How it works

  1. A service is created that is connected to the latest version of multiple node implementations ("validating nodes"):

    • BCHD
    • Bitcoin Unlimited
    • Bitcoin Verde
    • Flowee The Hub
  2. This service accepts a standard block template from getblocktemplate as specified by BIP-22, BIP-23, BIP-9, and BIP-145.

  3. Once a block template is received, the BitBalancer ensures each validating node has seen each transaction within the template block.

    • The service then attempts to validate the template block for each implementation.
    • The service then responds to the requester if any node finds the template invalid.
  4. 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.

  5. The validating nodes may not be equipped to validate a template block. This solution will:

    • Define a formal BIP to extend getblocktemplate to allow its proposal mode to allow a flag to ignore the proof of work validation for the block data.
    • Create a reference implementation and pull request for BCHN that fulfills the above extension to getblocktemplate.
  6. Providing an implementation for BCHN due to its current majority market share.

    • If other implementations provide similar required functionality without directly using getblocktemplate then this issue may be later extended to create a compatibility shim(s) for those implementations.

Non-Indexing Module

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.

Changes to Bitcoin Verde

With cacheBlocks, blocks are stored serialized on-disk. Many of the transaction-, address-, and slp-related SQL tables have been removed.

  1. A new transactions table has been created with columns that can be used to point to the location on disk where the transaction's block is stored, and an offset of where the transaction is within the block flat file.
  2. To keep mempool/unconfirmed-transaction logic consistent between modules, the former transaction_* tables has been renamed and reused for unconfirmed transactions.
  3. As transactions are mined in a block they are removed from the unconfirmed_transactions_* table, and will only be stored in block flat files.
  4. Total transaction size and fee amount have been added to the transaction table to improve block template generation.

Bitcoin Verde Explorer: Memo Support Added

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.

Changes made to the Bitcoin Verde explorer:

  • Bitcoin Verde has been extended to parse Memo protocol transactions.
  • Memo transactions are indexed by the node.
  • A routine has been implemented to back-port the indexes for nodes that are currently synced.
  • RPC calls have been updated to include Memo data, similar to the functionality provided for SLP.
  • The explorer API has been updated to include transaction Memo data.
  • Our explorer will now display tabulated Memo data, similar to bitcoin.com.

Testnet Configuration Implemented

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.