IRC meeting summary for 2016-10-27
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.
- Removing checkpoints
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.
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.
- Take a look at PR#8994 (Testchains: Introduce custom chain whose constructor…)
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
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.
- Discuss further after meeting
|wumpus||Wladimir van der Laan|
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.