Who We Are

Bitcoin Verde is a BCH full-node implementation founded by Josh Green, owner of Software Verde. Software Verde is a group of full-stack software developers from Columbus, Ohio dedicated to developing technology that serves our community, clients, and friends. We have an affinity for open source software and in general are all life-long technology enthusiasts. Our team is primarily composed of Josh Green, Andrew Groot, Eliot Lesar, and John Jamiel.

We first began our journey of creating Bitcoin Verde in late 2017, a few months after the BCH hard fork. Eager to contribute, we decided to learn by doing. Unsure where to begin, Josh had come to a realization; the majority of implementations were forked versions of the same Bitcoin (Core) reference client. We decided then the best way we could contribute while learning the ins and outs was with a ground up build. Joining the ecosystem in January 2019, Bitcoin Verde has always had a primary goal of providing diversification to the BCH network. We believe we have achieved that goal through the release of our indexed java full-node implementation.

Since our journey began we have worked with several groups, technologists and not, to contribute to the community anyway we can. Joining countless discussions, educating local governments, contracting with Bitcoin Unlimited to create a descriptive BCH specification, and continuing to improve our implementation are all highlights of our work we are proud of. We have worked hard over the last few years to ensure the work we produce is meaningful and valuable to our community. Currently, Bitcoin Verde provides the network with a full-node implementation, a block explorer, and development library. Our ambitions for the future are to continue to make improvements to our implementation and eventually provide wallet and mining-pool modules.

Our Goal

Our goal for this campaign is to generate enough interest and support to fund our current development roadmap. Currently, Bitcoin Verde has four core features identified that we believe will be necessary to continue to operate as a competitive, viable option for BCH operators, whether they be full-nodes or miners. These four features include:

• Creating a Non-Indexing Module
• Creating a Block Template Validation Service
• Implementing Testnet Configuration
• Modifying the Bitcoin Verde Explorer: Memo Support

The Work

Creating a Non-Indexing Module

Currently Bitcoin Verde indexes large parts of the blockchain. Some of these indexed components include (but are not limited to):

• all transactions
• all outputs and inputs (both spent and unspent)
• P2PK/P2SH addresses
• SLP tokens
• SLP validation
• contentious/orphaned blocks.

Despite being very useful for explorers and wallet services, these indexes provide a lot of drawbacks for validation services and no real value for mining nodes. Creating a non-indexing module for Bitcoin Verde will provide several benefits that would ultimately contribute to our team goals to becoming a viable mining module. Benefits from this addition include:

• Reducing the time for the initial block download
• Allows mining pools to start running a Bitcoin Verde node in a more reasonable amount of time
• Reducing the minimum required resources
• Reduces barriers of entry for both miners and non-indexing node operators
• Allows pool operators to run redundant/backup nodes for their pool at a lower cost
• Reducing overall infrastructure cost to run a Bitcoin Verde node

The Solution

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

• A new transactions table will be 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.
• This migrates mined transactions from the database (which is indexed and normalized, which is space inefficient and less performant) to a more compact format in a flat file.
• To keep mempool/unconfirmed-transaction logic consistent between modules, the former transaction_* tables will be renamed and reused for unconfirmed transactions.
• Having unconfirmed transactions indexed and normalized allows Bitcoin Verde to keep its infinite transaction-chaining limit, without any additional development.
• As transactions are mined in a block they will be removed from the unconfirmed_transactions_* table, and will only be stored in block flat files.
• Since the transaction SQL tables will not be large, indexing only unconfirmed transactions nominally increases the disk footprint of the node, while still allowing extensibility for future features and complex decisions to be made regarding next-block inclusion of unconfirmed transactions.
• Total transaction size and fee amount will be added to the transaction table to improve block template generation.

Changes will affect mostly the data-layer, which is encapsulated by the TransactionDatabaseManager and related classes. Validation logic and network logic may be minimally affected. Many of the existing tests depend on direct manipulation of the database's data for their setup.

With a different schema, these tests will be broken when run with the schema changes for this module. These schema changes won't cause the original test suite to break since the test suite loads the indexing schema by default. However, with this configuration, many of the tests will not be run against the new schema, causing a fairly large gap in test coverage for critical functionality.

• This proposal includes extension to existing tests to include coverage of the non-indexing schema as well as the indexing schema.

Milestone, Deliverables and Estimated Complexity

We have estimated this addition to take approximately 180 hours of development time to see to completion. Our solution can be broken down into 3 major milestones, each with varying amounts of complexity. It is our proposal to allocate funding proportional to the complexity and time estimated to develop these milestones, with funding received at the completion of each.

1. SQL schema refactoring and data-layer migrations. 80 / 180 hours (45%)

   The first milestone will consist of the SQL schema and logic changes discussed in the solution overview. This milestone is considered completed once the tables are removed and the node successfully completes its initial block download on main-net.

2. Updating tests for new data-layer. 60 / 180 hour (33%)

   The second milestone consists of updating all broken tests to ensure existing regression tests pass. Additionally, the second milestone includes expanding the existing test suite to run against both indexing and non-indexing schemas.

3. Month-long main-net tests ran via the block template aggregator. 40 / 180 hours (22%)

   The third milestone will conclude after the node is synced to main-net and its template block is deemed compatible with both Bitcoin ABC and Bitcoin Unlimited nodes.

   Completion of this milestone requires the node be updated for the new sigops ruleset included in the 2020-05 upgrade, and requires the template block aggregator be completed so that the template block generated by Bitcoin Verde may be automatically validated by other node implementations against current main-net nodes. After a month of creating main-net template blocks without incompatibility, the milestone will be deemed completed.

Block Template Validation Service

There is a risk that blocks mined by miners could cause a chain split or be orphaned due to being incompatible between node implementations. From a miner's perspective, even a small risk associated with these incompatibilities can have a large impact on profitability. This incompatibility risk increases the incentive for miners and pools to all run the same implementation, which greatly reduces node-diversity between miners.

This block template validation service (TVS) aims to reduce the risk of the miners creating an invalid block to near-zero by validating the template block against other implementations before any work is performed on the block template. Benefits from completing this work include:

• Reduce the risk of unintentionally mining a block that would cause a network split
• Reduce the financial risk to miners of running different node implementations
• Increase miner confidence in node-diversity
• Alert developers of would-be incompatible blocks

The Solution

Create a service that is connected to the latest version of multiple node implementations ("validating nodes"):

• BCHD
• Bitcoin ABC
• Bitcoin Unlimited
• Bitcoin Verde
• Flowee The Hub

This service shall accept 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 service 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.

A best effort attempt by the service will be made to determine which transaction(s) trigger the invalid state of the template block, so the requester may choose to omit them.

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 Bitcoin ABC that fulfills the above extension to getblocktemplate.

Providing an implementation for Bitcoin ABC 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.

Bitcoin Verde does not currently support proposal mode of getblocktemplate. This issue will modify the currently equivalent functionality to match the getblocktemplate RPC API, including proposal mode.

Milestone Estimates and Deliverables

We have estimated this addition to take approximately 160 hours of development time to see to completion. Our solution can be broken down into 4 major milestones, each with varying amounts of complexity. It is our proposal to allocate funding proportional to the complexity and time estimated to develop these milestones, with funding received at the completion of each.

1. Define the service API to validate a block template. 30/160 hours (18.75%)
2. Invoke multiple RPC getblocktemplate:proposal calls to connected node(s) to validate the template block, and return the validation status. 30/160 hours (18.75%)
3. Create a formal BIP to extend the existing functionality of getblocktemplate:proposal. And reference implementation for Bitcoin ABC. 60/160 hours (37.5%)
4. Modify Bitcoin Verde to fulfill the proposed BIP. 40 / 160 hours (25%)

Implementing Testnet Configuration

Currently Bitcoin Verde only allows for connections to mainnet. While historically testing of edge cases has largely been done via unit tests with public test vectors, there is additional integration testing that Bitcoin Verde could benefit from by connecting to testnet, particularly in the time leading up to hard-forks where it appears testnet is more heavily used.

Connecting to testnet may also provide a way for Bitcoin Verde's unique perspective on testing Bitcoin Cash to benefit other node implementations in the event that the many differences between Bitcoin Verde and other implementations may lead to different kinds of test transactions.

One of the key reasons this isn't already implemented is that testnet has a number of differences in terms of how transactions and blocks are relayed, validated, and mined. As such, these differences will all need to be implemented as toggle-able based on a new configuration field.

This solution will provide:

• An additional mode of testing that should provide benefits over current modes.
• Increased exposure to edge-case transactions that are less prohibited on testnet.
• Improved coordination with other node implementations for hard-fork testing.

The Solution

Although transaction standardness is not enforced by Bitcoin Verde currently, steps should also be taken to ensure that if and when standardness checks are added to Bitcoin Verde, they will still be disabled when connecting to the testnet.

In order to operate with the testnet, the following updates will be required:

• Alternative port numbers, magic number, and DNS seeds
• Different address version number and prefix
• Different genesis block
• Additional difficulty adjustment rules

Milestone Estimates and Deliverables

We have estimated this addition to take approximately 60 hours of development time to see to completion. This addition can be broken down into 2 milestones. It is our proposal to allocate funding proportional to the complexity and time estimated to develop these milestones, with funding received at the completion of each.

1. Update components with different static content. 20 / 60 hours (33%)

   The first milestone consists of the changes needed purely to communicate with the BCH testnet. This includes port numbers, anything affecting protocol message contents, and information about the genesis block. This milestone is considered complete once all components have been updated and published.

2. Ensure full synchronization is possible. 40 / 60 (67%)

   The second milestone of this addition will require us to update transaction and block validation rules to ensure that Bitcoin Verde will in fact accept the content it is now able to request and receive. Only once full synchronization has been confirmed will this milestone be marked as complete.

Modifying the Bitcoin Verde Explorer

The Bitcoin Verde node and explorer currently do not have any support for Memo. End-users and developers rely on block explorers to check the validity of their actions on the blockchain.

The support provided by the current state of the explorer is considered minimal, which deters users from using the explorer to its full potential. Fully supporting the SLP and Memo actions taken by users would provide viable redundancy for other block explorers, and increases the choice of platform for users and those running their own block explorer.

These additional features enable other developers to easily review what Bitcoin Verde considers valid. This is especially valuable for OP_RETURN-like applications, since their status is not inherently validated by miners.

In all, this modification will:

• Attract users to the Bitcoin Verde explorer that use the Memo protocol for messaging
• Allow other developers to easily review the validity of their OP_RETURN-based transactions to cross-validate implementations and consensus
• Keep support for the legacy address format while also adding CashAddr support

The Solution

Add Memo Support

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

Milestone Estimates and Deliverables

We estimate these modifications will take approximately 56 hours of development time complete. This modification is broken down into 2 major milestones, each with varying amounts of complexity. It is our proposal to allocate funding proportional to the complexity and time estimated to develop these milestones, with funding received at the completion of each.

1. Bitcoin Verde (Node) Memo Support 40 / 56 hours (71.5%)

   The first milestone will consist of all node changes required to support the Memo protocol, including RPC calls. This milestone excludes all Memo support for the explorer.

2. Bitcoin Verde (Node) Explorer Support 16 / 56 hours (28.5%)

   The second milestone will consist of all explorer changes required to support the Memo protocol.

Requested Funding

In total, by our estimations the next development cycle for Bitcoin Verde will require approximately 456 hours between 3 of our engineers and 1 technical writer. At a rate of 0.6 BCH/hr, the total requested funding for this proposal would be 273.6 BCH. However, prior to the creation of this funding campaign, Josh Green had written individual funding proposals for each feature, tracked as individual issues on GitHub.

Having already raised funds (24.838 BCH) intended to support this development cycle it would be irresponsible to not deduct contributions already made from their respective deliverables. After adjusting for contributions already received, the total remaining funding requested for this cycle is 241.162 BCH or approximately $62,000, where funding is broken down into 4 deliverables totaling 11 milestones.

Appreciation

The undertaking of this project is no small endeavor. It is due to the continued generosity and support of our community that we are able to continue our operations today. We appreciate every opportunity the network and all contributors have afforded us and look forward to continuing our involvement. We look forward to continuing our involvement with the BCH community and assisting in the maturation of our network.