Skip to content
{{ message }}

Instantly share code, notes, and snippets.

# KarolTrzeszczkowski/BLOCK_INTERVAL adjustment mechanism.md

Last active Jul 30, 2020
```Title: BLOCK_INTERVAL adjustment mechanism
Author: Karol Trzeszczkowski (Licho)
Status:
Type:
Created: 2020-05-18
```

## Abstract

An algorithm proposed.

## Introduction

Bitcoin emission schedule is one of the key elements in Bitcoin design, and a promise that was made to early investors. Furthermore, predictable inflation is believed to be one of the crucial components of hard money. Bitcoin is designed to have a specified number of bitcoins in a single block so technical considerations of block production, propagation and transaction confirmation get entangled with monetary policy. While DAA proposal addresses the technical aspects of block production, this proposal addresses the monetary policy aspect of it. The former answers the question how to keep the block production rate that we want, while the latter answers the question what block production do we want to have. Under the idealized conditions of constant hashrate and difficulty, the total time it would take to mine blocks up to a certain height would be described by a normal distribution. The standard deviation of this distribution is equal to `Σ = σ√H` where `σ` is standard deviation of a single solve time and `H` is height. In reality, ever increasing hashrate, events from the past and imperfections of Difficulty Adjustment Algorithm(DAA) cause the error to be much larger. For example, for the block at height 633950, previous BCH blocks were separated by 564s on average, instead of 600. The error is an order of magnitude larger than `3σ`. To prevent such errors from accumulating in the future, a BLOCK_INTERVAL adjustment mechanism is proposed. The algorithm would take a secondary role to DAA and adjust the `BLOCK_INTERVAL` parameter in DAA based on the bigger picture.

## Requirements

1. Assure predictable coin emission,
2. Fulfill the original promise of Bitcoin,
3. Not interfere with the DAA,
4. Not affect user experience.

### BLOCK_INTERVAL adjustment mechanism

The formula to calculate new block time is the following:

`BLOCK_INTERVAL = ΔT² / (T/H),`

where ΔT is 600 seconds/block, `T` is the total time since the genesis block to the current block median time past and `H` is the last block height.

## Rationale

The formula for the `BLOCK_INTERVAL` can be represented as:

`BLOCK_INTERVAL = c * ΔT,`

`c = ΔT / (T/H).`

The factor `c` is chosen to be equal to 1 when the global average of the block solve time is equal to `ΔT = 600`. The factor is above 1 when the total time is too short and below 1 when too long. It will counteract the drift that has accumulated over the years of Bitcoin existence and eventual future drift (Req. 2). For example, for the block at height 633950, previous blocks were separated by 564s on average. BCH blockchain was too fast. The `BLOCK_INTERVAL` calculated with the method described in this document would be 638s. This mechanism will cause `BLOCK_INTERVAL` to asymptotically approach the original target interval. Reducing the global error by half, to 582s, will take about 250 000 blocks which is around 5 years. Reducing it again by half to 591s will take another 5 years, and so on. After approximately 30 years the targeted block time will be restored and the schedule will be kept by a negative feedback loop (Req. 1). This mechanism will not interfere with the primary difficulty adjustment algorithm because they operate at different timescales. DAA operates at the scale of days, `BLOCK_INTERVAL` adjustment operates at the scale of years (Req. 3). The initial increase in the target solve time is in the range of 6% which should be hard to notice for a regular user (Req. 4).

Over time the mechanism will become less and less responsive. Expanding the formula for `c` around a small parameter we get:

`T = ΔT H + error`

`c =ΔT/(T/H) = ΔT / (ΔT + error / H) ~ 1 - error / H ΔT `.

The absolute error of the same magnitude will have smaller effect as the blockchain will age, as the factor `error / H ΔT` is inversely proportional to the height. By the time this mechanism will become 3 times less sensitive, the error will have smaller significance, as the block reward will already go through 7 halvings and the block reward will be a tiny fraction of the supply. It should be judged in the context of the entire system. Diminishing significance of this mechanism is also a guarantee that it is safe to add it and it will not cause any interferences in the future.

Trade-offs

• Decreasing sensitivity

The mechanism can be made to have a constant sensitivity, by taking `c` in the form:

`c = ΔT / (ΔT + error / H)`

and replacing `H` with a constant. Such design can be used to correct for the past errors faster at the cost of user experience (Req. 4) or to keep the schedule more tightly. This approach is more complicated and unnecessary, as the simple formula fulfills the requirements anyway.

• Additional complexity

The technical debt added with this proposal is minimal as it is done with a single line of code, but also the benefit of fine-tuning the schedule so arbitrary and coarse that it includes earthshaking reward halvings seems minute. By the time it takes effect, majority of block reward should be replaced by the transaction fees.

### Cons

The DAA proposed here will not cause violent hashrate swings that are currently the source of the drift and it will make smaller mistakes so the future average solve time drift will be less significant. The additional safeguard might be unnecessary to assure predictable coin emission (Req. 1) although it won't correct for the past errors (Req 2.)

### Summary

A mechanism regulating the supply to match the original Bitcoin promise more closely have been proposed. The algorithm fulfills the requirements and the costs of putting this mechanism to DAA are insignificant. The inclusion should be considered.

### Acknowledgments

I want to thank @huckfinne for financially supporting my continuous work on BCH and Amaury Sechet (Deadalnix) for suggesting this area of research.

to join this conversation on GitHub. Already have an account? Sign in to comment