Block Template Validation Service
GitHub Issue #8
Problem Description
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.
Incompatibilities in consensus, while generally very rare, are possible due to minute differences in the implementation details between nodes.
Generally, these differences are only challenged by uncommon edge-cases within the scripting and validation logic between the nodes.
Since the block template is only lacking the proper work before it is considered valid, nearly all of the possible incompatibilities between block candidates can be detected before any work is ever performed.
This block template validation service (TVS) proposal 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.
Value Proposition
This solution will provide the following benefits:
- 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
Solution Overview
- 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 (if necessary)).
-
Once a block template received, the service ensures each validating node has seen each transaction within the template block.
-
Then the service 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 with transaction(s) trigger the invalid state of the template block, so the requester may choose to omit them.
Additional future extensions to this proposal may include returning a modified block template that excludes only the incompatible transactions.
Notes:
The validating nodes may not be equipped to validate a template block.
This proposal 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.
Additionally, this solution will create a reference implementation and pull request for Bitcoin ABC that fulfills the above extension to getblocktemplate
.
Providing an implementation for Bitcoin ABC (while others are omitted) is considered within scope of this issue due to its current majority marketshare.
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.
Solution Milestones
- Service Creation
a. Define the service API to validate a block template.
b. Invoke multiple RPC getblocktemplate:proposal
calls to connected node(s) to validate the template block, and return the validation status.
- Create BIP
a. Create a formal BIP to extend the existing functionality of getblocktemplate:proposal
.
b. Create reference implementation for Bitcoin ABC.
- Modify Bitcoin Verde
a. Modify Bitcoin Verde to fulfill the proposed BIP.
Estimated Relative Complexity
- Milestone 1 - 60 / 160 (37.5%)
- Milestone 2 - 60 / 160 (37.5%)
- Milestone 3 - 40 / 160 (25%)
Budget
This proposal does not have a minimum starting budget.
Completing this proposal will require approximately 160 hours
.
At a rate of 0.5 BCH/hr
, the total requested budget for this proposal is 80 BCH
.
Funding Address
Funding this proposal may be sponsored by sending Bitcoin Cash to the following address:
18SSESYMBCsFkDGHwcvUFCoxwFcsCHgV73
(bitcoincash:qpges4u8lm9w6mekdkrn9cpy79lst2lukywwgpkf8r
)
Authorization Signature:
The signature is signed with our primary donation address, 1VerdeMuXH1ApSZsQDkuHHZrwJaAtXTVn
, which can be found on bitcoinverde.org.
The signature message consists of a Bitcoin Signed Message with the following format:
Issue-Number | Issue Title | Funding Address | Estimate Hours | Budget BCH
Notes:
- The pre-image includes the concatenation symbol.
Pre-image:
8|Block Template Validation Service|18SSESYMBCsFkDGHwcvUFCoxwFcsCHgV73|160|80
Signature:
G8HaPOT1tLJE0JfcUnejdBKAuP+xzS5vu0ZZY85gEjS/WAQonhUI5kK94B1vb8cN4IFOSDDPKadmHzChy7xcgsg=