Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman’s terms.
Link to last summarisation
Disclaimer
Please bear in mind I’m not a developer so some things might be incorrect or plain wrong.
There are no decisions being made in these meetings, but since a fair amount of devs are present it’s a good representation.
Copyright: Public domain Logs
Main topics
Versionbits
Status of segregated witness
Status of 0.12 bitcoin-core release Consensus code encapsulation (libconsensus) Locktime PRs Versionbits background BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last 1000 blocks have a version number higher than X the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other. meeting comments Morcos is volunteering to take over championing this proposal as CodeShark and Rusty are busy on other things. He’ll review both implementations and then decide on which implementation he’ll base his work upon. He notes that if non-core implementations are trying to do something else (and are using nVersion for their signaling) while segregated witness is being deployed, not conflicting will be important so users of other versions can also support segregated witness. If there’s an agreement with this approach it’s necessary that versionbits is ready before the segregated witness deployment. jtimon has some suggestions to make the implementation less complicated and more flexible. meeting conclusion Morcos will champion the new reference implementation for BIP9: Versionbits […]
