BUIP058: (withdrawn) Dynamic checkpoints

[freetrader]

Summary

Add a feature which allows dynamic addition and removal of non-hardcoded checkpoints.

Checkpoints denote blocks that must be present in a valid chain. A checkpoint is a tuple (chain_height, block_hash) indicating that the block at that height must always have the given hash.

Currently, there are only some hardcoded checkpoints in src/chainparams.cpp (not frequently updated).

Motivation

To allow more flexible, persistent protection of a chain against re-organization [1], at the discretion of the operator.

This could be particularly useful in a hard fork scenario such as the very contentious "breaking of the 1MB barrier".

Having an advanced user option to add checkpoints saves the operator from having to use 'invalidateblock' as a way of fighting attacker re-org blocks, essentially saving effort and reducing chance of costly mistake.

Since additional checkpoints may act to block re-organizations to a longer valid chain with more proof-of-work, this feature should be considered as an expert tool, probably only to be used by operators of mining nodes.

Implementation

An RPC call interface shall be added to add and remove dynamic checkpoints.

Whenever a dynamic checkpoint is added or removed, the active chain shall be re-evaluated for compliance and if necessary, a re-organization performed in an attempt to achieve compliance with the stipulated checkpoints.

The dynamic checkpoints shall be recorded in a human-readable checkpoint data file (e.g. checkpoints.csv) whenever the list changes.

At startup, the client shall read this file, if present, and add any checkpoints from there to its list of built-in checkpoints used for chain processing.

The client shall abort startup if the checkpoint data file is malformed (see Notes). If the file is not present, it shall proceed using only the built-in (hardcoded) checkpoints.

The RPC interface does not need to be specially exposed through the GUI - it would be available through the Debug Console anyway.

It shall not be possible to dynamically remove built-in checkpoints.

Notes

A checkpoint data file is malformed if it is syntactically invalid, or if it contains the following semantic problems:

• duplicate entries
• entries with conflicting hashes for identical height
• entries with conflicting height for identical hashes

There have been a number of suggestions for potential names of the RPC calls.

Adding: 'mandateblock', 'requireblock', 'addcheckpoint'

The removal call names could be formed by pre-prending 'un-', or substituting 'remove' for 'add'.

I have intentionally not included some form of automatic addition of checkpoints in the form discussed in [2], to keep this BUIP functionally simple.

References

[1] https://bitcointalk.org/index.php?topic=437
[2] https://bitco.in/forum/threads/buip056-increase-the-block-size-limit-triggered-by-a-support-threshold.2111/page-2#post-39031

 

[freetrader]

@solex : can I provisionally grab the number 58 for this one, and add it to the upcoming vote?

 

[freetrader]

I have provisionally renamed this to BUIP058. If there is a conflict please let me know.

I request this BUIP to be included in upcoming vote, as I believe from a user requirement POV it is very simple to understand what this feature must deliver.

There may be some implementation complexity since dynamic addition/removal of checkpoints must be processed correctly w.r.t. the active chain, but I think those challenges are resolvable. The dynamic checkpoint removal will not be allowed to remove the built-in checkpoints.

 

[solex]

@freetrader certainly, It's added to the index as 58.
As far as voting is concerned there needs to be a 14 day window for public consultation after the Developer has finished discussing and revising the BUIP with the proposer.

 

[freetrader]

@solex - Got it, thanks for reminding me of the 2 week windows (one for the Developer, and a subsequent one for public). Next voting round it is then for BUIPs 58 & 59.

 

[freetrader]

I drafted this prior to the minority fork that became Bitcoin Cash, in case there was a need for such functionality to defend the fork chain against attack.

It seems no longer needed, and therefore I withdraw this BUIP with immediate effect.

 

[solex]

Thanks for the update, @freetrader
I will update the index.

 

[freetrader]

I already updated via PR which @sickpig has merged . Thanks @solex!

 

[freetrader]

So, this feature was actually implemented once now

Not on BU, but on BCHN, experimentally, in MR 807 .

Ironically, even the second time around it was not needed, and will probably not be merged into the client, but the code (and some docs) are there (in its not completely polished state) if someone needs to unearth it or wants to do something further with it.

 

[solex]

Thanks for the information @freetrader
The next BU vote is in December. Your view on any proposal is welcome.

 

[donald26]

HOW YOU CAN RECOVER YOUR LOST CRYPTO/FUNDS: Lost hope in a crypto scam? I got my $394,330 back! I invested $430,000 in a bogus crypto site. Big returns promised, withdrawals blocked, extra fees demanded – it was a nightmare. Feeling trapped, I even considered the unthinkable. My family helped me through it, and my niece suggested HACKERSTEVE911. They'd helped her with grades, but I'd never thought of them for this. I contacted them, expecting little. But within four days, they recovered $394,330 back to my wallet! My hope, my life, was back. If you're in a similar situation, don't lose hope. Contact them on hackersteve911@gmail.com