IRC meeting summary for 2016-10-20
Overview
Notes / short topics
- Bitcoin Core 0.13.1 Release candidate 2 is out, currently without any reported issues.
- Wumpus has been asking around in regards to killing off windows 32 bit builds, possibly in 0.15. He got back 2 responses of people still using windows 32-bit, both expecting only to last 6 more months on it.
- Jonasschnelli noticed the GUI default confirmation target is 25 blocks, which is really high, while the default RPC target is only 2 blocks. Those should be the same value. As there’s little progress in improving fee estimation, the bumpfee PR should get some more review.
Main topics
- libconsensus
libconsensus
background
Ideally consensus layer should decoupled from other parts of the Bitcoin software. The long term goal is to extract a separate “libconsensus” library. This way people can more easily make changes in the non-consensus part without fear of consensus incompatibility. This however is a slow and dangerous project of moving lot’s of code around. In the last few major releases, there’s been an effort to work towards this consensus library.
Recently Jorge Timón made a mailinglist post proposing a more detailed plan on how to proceed. He has his own branch where he’s working on all the changes.
meeting comments
Currently it’s possible to pass non-consensus flags into libconsensus. PR #8976 tries to fix this. Sipa thinks there should be a translation layer.
Jtimon would like to expose a “GetConsensusFlags” call in libconsensus, to hide BIP9 and previous development stuff similar to “expose VerifyHeader”. Sipa doesn’t like turning the internal representation for headers into an interface and would just have an API where you can create a blockindexstore and you give it headers. That would mean libconsensus remains coupled with Bitcoin Core’s storage, which is sipa’s preference. Wumpus notes the previous conclusion was that libconsensus should remain coupled with the current caching layer, but not with levelDB so that memory storage is part of libconsensus but not disk storage. Jtimon would be fine with having one with storage included and one without it, for example libbitcoin would likely never use a libconsensus that’s coupled to bitcoin’s storage and concurrency. Others might just want to use core’s current storage implementation to cut down on work. Sipa argues not abstracting out data structures leaves more opportunities for future optimizations.
meeting conclusion
- Focus on separation of units and removing dependencies, further optimizations can happen later.
- Discuss further after the meeting
Participants
| IRC nick | Name/Nym |
|---|---|
| sipa | Pieter Wuille |
| gmaxwell | Gregory Maxwell |
| wumpus | Wladimir van der Laan |
| btcdrak | BtcDrak |
| instagibbs | Gregory Sanders |
| cfields | Cory Fields |
| Chris_Stewart_5 | Chris Stewart |
| jl2012 | Johnson Lau |
| CodeShark | Eric Lombrozo |
| Michagogo | Michagogo |
| paveljanik | Pavel Janik |
| achow101 | Andrew Chow |
| morcos | Alex Morcos |
| MarcoFalke | Marco Falke |
| jtimon | Jorge Timón |
| BlueMatt | Matt Corallo |
| kanzure | Bryan Bishop |
| jonasschnelli | Jonas Schnelli |
| jeremyrubin | Jeremy Rubin |
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.