Topic: Bitcoin dev IRC meeting in layman's terms (2016-01-14) (Read 403 times)

Wow, thanks for summarizing this... Quite a bit of work going through the logs

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

- link to this week logs 
- Meeting minutes by meetbot

## 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.

## Status of segregated witness

background
Segregated witness changes the structure of transactions so that the signatures can be separated from the rest of the transactions.
This allows for bandwidth savings for relay, pruning of old signatures, softforking all future script changes by introducing script versions and solves all unintentional forms of malleability.
During the last scaling bitcoin conference Pieter Wuille presented a way of doing this via a softfork, and proposed increasing the maximum amount of transactions in a block by discounting signature data towards the total blocksize. 
Segregated witness is part of the capacity increase roadmap for bitcoin-core. 
More detailed explanations: 
- By Pieter Wuille at the San Francisco bitcoin developer meetup (more technical) 
- By Andreas Antonopoulos in the let's talk bitcoin podcast (less technical)

meeting comments
Segnet, the testnet for segregated transactions, will be going to it's 3rd version soon. 
Luke-Jr has assigned all the segregated witness BIPs to a 14x range. Currently there are 4 BIPs: 141, 142, 143 and 144. 

## Status of 0.12 bitcoin-core release

background
Bitcoin Core 0.12 is scheduled for release around February and introduces a lot of fixes and improvements. (release notes)   
There's a release candidate 0.12rc1 available at https://bitcoin.org/bin/bitcoin-core-0.12.0/test/

meeting comments
Luke-Jr feels PR's #7149, #7339 and #7340 should have been in 0.12, but are now really late and possibly impractical to get in. 
For gitian builders: 0.12rc1's osx sig attach descriptor fails due to a missing package (that's not actually needed). Rather than using the in-tree descriptor, use the one from #7342. This is fixed for rc2. 
"fundrawtransaction" and "setban" should be added to the release notes. At some point it makes more sense to document these commands elsewhere and link to it in the release notes, as they've become very lengthy. 
Wumpus thinks the release notes have too much details, they're not meant to be a substitute for documentation.

meeting conclusion
Close PR #7142 as it's now part of #7148 
Everyone is free to improve on the release notes, just submit a PR.

## consensus code encapsulation (libconsensus)

background
Satoshi wasn't the best programmer out there, which leaves a pretty messy code. Ideally you'd have the part of the code that influences the network consensus separate, but in bitcoin it's all intertwined.   
Libconsensus is what eventually should become this part. This way people can more easily make changes in the non-consensus part without fear of causing a network fork. 
This however is a slow and dangerous project of moving lots of code around. 

meeting comments
jtimon has 4 libconsensus related PRs open, namely #7091 #7287 #7311 and #7310 
He thinks any "big picture branch" will be highly unreadable without merging something like #7310 first. 
The longest "big picture branch" he currently has is https://github.com/jtimon/bitcoin/commits/libconsensus-f2 
He'll document the plan and "big picture" in stages: 
1. have something to call libconsensus: expose verifyScript. (Done) 
2. put the rest of the consensus critical code, excluding storage in the same building package (see #7091) 
3. discuss a complete C API for libconsensus 
4. separate it into a sub-repository 
Wumpus notes he'd like to start with 3 as soon as possible as an API would be good to guide this.

meeting conclusion
review #7091 #7287 #7311 and #7310 

## Locktime PRs

background
BIP 68  Consensus-enforced transaction replacement signaled via sequence numbers. 
BIP 112 CHECKSEQUENCEVERIFY. 
BIP 113 Median time-past as endpoint for lock-time calculations.
In short: BIP 68 changes the meaning of the sequence number field to a relative locktime. BIP 112 makes that field accessible to the bitcoin scripting system. BIP 113 enables the usage of GetMedianTimePast (the median of the previous 11 blocks) from the prior block in lock-time transactions.

meeting comments
We need to make a choice between 2 implementations, namely #6312 and #7184. 
PR #7184 is a result of the CreateNewBlock optimisations not being compatible with #6312. 
jtimon thinks it could be merged relatively soon as #7184 is based on #6312 which has plenty of testing and review.

meeting conclusion
Close #6312 in favor of #7184. 
Morcos will fix the open nits on #7184 
btcdrak will update the BIP-text


## Participants

 

## Comic relief