Skip to content

Latest commit

 

History

History
79 lines (50 loc) · 5.47 KB

decentralized-improvement-proposals.mediawiki

File metadata and controls

79 lines (50 loc) · 5.47 KB
Raw

  BIP: ?
  Title: Decentralized Improvement Proposals for the Bitcoin protocol
  Author: Tomas van der Wansem <[email protected]>
  Status: Draft
  Type: Standards Track
  Created: 2015-12-28

Table of Contents

Abstract

Many different proposals are being made to improve the bitcoin protocol. This proposal specifies a standardized way for different implementations to amend or change the rules of the protocol with minimal risk.

Motivation

The current method of changing the protocol is through sequential updates of the reference implementation. These updates are guarded by a threshold (BIP34) to minimize risk. A proposal is being implemented (version bits) that would allow multiple different changes to be scheduled in parallel.

The current limitation is that all change proposals must pass through the develepment process of the reference implementation.

The disadvantange of this centralization has become evident: The only method that other implementors have to make changes to the protocol, is to apply these changes in their implementations without consent of other implementations. Even if these changes are guarded by an activation threshold, other implementation may not be aware of the change which may cause an effective split of the blockchain.

For this reason, such changes outside the reference implementation are in its current form, dangerous.

This proposal attempts to resolve this.

Definitions

We define a Decentralized Improvement Proposal (DIP) as a 41-80 byte data structure consisting of the following fields:

  • Magic string (3 bytes): The ASCII characters 'D', 'I', 'P', used to identify the structure as a DIP
  • Forward-Compatibility-Indicator (FCI) (1 byte): A byte defining the forward compatibility of code that has not implemented the DIP with respect to blocks generated after DIP-switch (see below). The following values are defined:
    • 1: The DIP is partially forward compatible. Even after the DIP-switch, nodes not supporting this DIP MAY broadcast and relay transactions and blocks. Nodes MAY NOT assume that they are fully validating.
    • 2: The DIP is not forward compatible. After the DIP-switch, nodes not supporting the DIP MAY NOT connect to other bitcoin nodes.
  • CRC (4 bytes): The CRC32 value of the body of the main resource referenced by the Specification-URL.
  • Specificaion-URL (max 72 bytes): A URL referencing a resource with content-type text/plain or text/html containing the full motivation and specification for implentation of the proposed change.
    • If the resource is in text/html format, the resource MAY reference auxilary resources (scripts/syles), however the full specification MUST be included in the main resource.
    • The specification MUST include or contain a reference to source code that implements and tests the change.
    • The specification MAY NOT change. If changes are made to the specification, the proposal is to be treated as a new DIP.
  • Padding: If the total size of the 4 fields is less then 41 bytes it MUST be padded with 0s to the size of 41 bytes
We define a *Block indicating support for a DIP* as a block that includes a transaction that includes an output script consisting of OP_RETURN and a DIP.

We define an "upcoming DIP-switch" as a block, for which including the block itself, the last 1000 blocks contain exactly 950 blocks which indicate support for a DIP.

We define a "DIP-switch" as block that has a block height of 10000 more then an upcoming DIP-switch.

Specification

Any node MUST implement:

  1. When the node receives an upcoming DIP-switch for a DIP that has not been fully implemented or tested it MUST warn the user.
  2. A node MAY NOT relay transactions containing a DIP (but of course MAY relay blocks containing transactions contain a DIP)
  3. When a node receives a DIP-switch for a FCI-1 DIP it has not fully implemented and tested, it MUST warn the user and it MAY NOT rely on fully validating transactions.
  4. When a node receives a DIP-switch for a FCI-2 DIP it has not fully implemented and tested, it MUST disconnect from the network and it MAY NOT reconnect to the network again.
  5. A node SHOULD provide an interface to the user to indicate the current status of different DIPs found in the blockchain
Any node that supports mining MUST implement:

  1. A mining node MAY generate and broadcast a Block indicating support for one or more DIPs ONLY IF it has fully implemented and tested the implementation of the DIPs according to the Specification-URL of the DIPs. The change for each DIP MUST be triggered only after the DIP-switch.
  2. A mining node SHOULD implement a configration option such that a user can disable or enable DIPs that the implementation supports.
  3. A miner node MAY NOT generate or relay blocks that include support for DIP after the DIP-switch for that DIP.

Forward compatibility

As this change in itself may result in changes that are not forward compatible (FCI-2), it is a FCI-2 DIP. Support may be indicated in a block by including the DIP for the final version of this proposal (Status: Final)

Implementation

To be done

Notes

  1. This proposal supercedes the concept of block versions. The version of a block should be determined by the existence of DIP-switches in the blockchain.
  2. It may serve purpose to add bits to the DIP to indicate what parts of the protocol have been changed. Suggestions are welcome.
  3. The indication of support through an OP_RETURN script is a first suggestion. As other people may have more intricate knowledge of the protocol, suggestions for a better place to put this are welcome.