IRC meeting summary for 2016-10-27

Overview

Notes / short topics

Main topics

  • Testchains
  • Removing checkpoints

Testchains

background

Jtimon is working on an easier way to create a new testnet outside of the main testnet (PR #8994). To test certain features or different edge cases the normal testnet might not be sufficient. Right now the instability of the testnet causes some people to just not test on it.

meeting comments

Further development will work on a signed blocks option, the mechanism used in Elements Alpha to create blocks. Jtimon is working on this in his own branch.

Within a trusted group using a regtest is just as useful as signed blocks, however when exposing it publicly something like block signing is needed. Jtimon notes his PR makes it so one can select “-chain=custom -chainpetname=mysharedsecret” and people without access to mysharedsecret won’t be able to create the genesis block locally as the hash of the genesis block depend on -chainpetname.

meeting conclusion

  • Take a look at PR#8994 (Testchains: Introduce custom chain whose constructor…)

Removing checkpoints

background

Every once in a while, an old block hash is hardcoded into Bitcoin software. Different implementations choose different checkpoint locations. These checkpoints are currently used for 3 use-cases:

  • Preventing header flooding with low difficulty headers
  • Skipping signatures in earlier blocks
  • estimate progress

meeting comments

Gmaxwell has a branch which removes checkpoints. He hasn’t taken it out completely as he still needs to replace progress estimation.

There are 3 components:

  • removal of checkpoints for the initial block download, which is a no brainer.
  • Removal of checkpoints for script checking, which depends on benchmark results as discussed in the 2016-09-09 meeting.
  • avoiding header flooding. Gmaxwell did came up with a tidy way to do this, but it would require an implicit consensus change which is very trivial and obviously fine, but would likely delay things. He proposes to introduce a constant in chain params which is the known amount of work in the best chain at release time. The initial block download check already uses this. Once we have any header chain that has at least that much work in it, we do not accept any more blocks with difficulty under 16 million, which is roughly equal to about 10 commercially available mining devices.

The difficulty can fall that low under a soft fork to a different proof-of-work, however under those conditions old clients are horribly insecure, which isn’t a characteristics of a soft-fork. Some more discussion ensues about the insecurities of soft-forks for PoW changes.

meeting conclusion

  • Discuss further after meeting

Participants

IRC nick Name/Nym
sipa Pieter Wuille
gmaxwell Gregory Maxwell
wumpus Wladimir van der Laan
btcdrak BtcDrak
cfields Cory Fields
Chris_Stewart_5 Chris Stewart
CodeShark Eric Lombrozo
morcos Alex Morcos
harding David Harding
jtimon Jorge Timón
BlueMatt Matt Corallo
kanzure Bryan Bishop
jonasschnelli Jonas Schnelli
jeremyrubin Jeremy Rubin
petertodd Peter Todd
luke-jr Luke Dashjr

Disclaimer

This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.