Our Goals

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

Bitcoin Verde's 2021 Flipstarter has been funded.

We're very excited to begin work on our next development cycle. In our 2021 Flipstarter we've outlined 6 primary changes and features we believe will provide the most immediate value to our implementation and community. The primary focus of these changes are centered around increasing the viability for network operators to choose Bitcoin Verde as their node software and increase 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.

Pruning Mode

A pruning mode will provide Bitcoin Verde operators the ability to substantially reduce the storage requirements for running their Bitcoin Verde node. When implemented, pruning mode will provide a configuration option to trim blocks of a predetermined depth once their contents have been validated.

Pruning mode is widely supported by other nodes of the network and working to enable it allows Bitcoin Verde to provide a competitive client for node operators with limited storage. We hope this reduction in resources can serve to further reduce the barriers for new operators joining the network.

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 can be used to greatly reduce the time required to synchronize a node on startup. Functionally, this may be particularly useful for businesses interested in running their own node and for developers under time constraints. An example of this is the recent CoinParty Hackathon, where developers wanted to run a node for testing, but had limited time to set up.

The addition of compatible UTXO Commitments with BCHD will serve to strengthen Bitcoin Cash's utility as we work to further reduce all barriers of entry.

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.

Electron Cash (FULCRUM API) Compatibility

Bitcoin Verde will be 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.

Implementing this functionality will allow Bitcoin Verde to run as an Electron Cash SPV Server, enabling users with electron wallets to connect and communicate with Bitcoin Verde. This addition will provide a quality of life improvement for Bitcoin Verde operators interested in running their own Electron Cash wallet, while providing Electron Cash end-users additional trusted servers to connect to.

Bitcoin Verde Mining Pool

Bitcoin Verde has previously created a minimally viable version of mining pool software. The goal of this phase will be to complete development of the Bitcoin Verde mining pool and provide our software to the BCH mining community. To reduce development time, it is our intention to utilize the current MVP and make large quality of life improvements to its current state.

Complete Features

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:

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.