IRC meeting summary for 2016-10-27
Overview
Notes / short topics
- 0.13.1 is released. (Binaries, magnet link, mailing list post, blogpost)
- Gmaxwell will coordinate with Achow101 and Cobra to get the final alert out, as discussed on the mailinglist and the 2016-09-22 meeting.
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.