IRC meeting summary for 2016-07-14
Overview
Notes / short topics
- Better documentation for the -blockmaxcost option was needed, but it’s been pointed out it’s an awful name as users think the ‘max cost’ is about the monetary cost. Translators also translate it in this way. The term ‘block cost’ is also used in the segwit BIP, sdaftuar proposes to change the description in the BIP. Participants agreed to rename blockmaxcost to blockmaxweight.
- Gmaxwell notes he got some replies on reddit stating that bitcoin core’s wallet was unusable for commercial use and most use centralized API providers. Commercial users unfortunately don’t report issues they encounter often and he doesn’t know how to improve this.
- Bsm117532 asks if anyone is working on the removal of “accounts”. Wumpus tried to introduce a label API for 0.13 to replace it, but it didn’t get enough review.
Main topics
- 0.13.0 rc1
- Segwit backport
0.13.0 rc1
background
The Bitcoin Core team is working towards 0.13.0 RC1. (full schedule)
meeting comments
Most of the remaining pull requests are merged, but there are still a few open PRs that need to be fixed for 0.13.0. Jonasschnelli opened up PR #8323 that he recommends to get into 0.13.0 to avoid problems identifying which are HD/non-HD keys.
The release notes are not urgent, since they need to be done for final, but not RC1.
meeting conclusion
- review #8323 (Add HD keypath to CKeyMetadata, report metadata in validateaddress)
- review #8305 (Improve handling of unconnecting headers)
- review #8295 (Mining-related fixups for 0.13.0)
Segwit backport
background
Developers are working on a soft fork to introduce segregated witness onto Bitcoin mainnet. Segregated witness (segwit) allows transaction signature data to be stored outside of the data hashed to produce transaction identifiers, removing all known forms of third-party malleability, allowing full nodes to compile the current UTXO set without downloading all signatures, and laying the groundwork for fraud proofs that can allow lightweight (SPV) clients to help enforce more of the consensus rules. The segwit soft fork also allows miners to substitute 1 byte of block space with 4 bytes of segwit data, increasing transaction capacity for wallets that use segwit. segregated witness BIPs: BIP141, BIP142, BIP143, BIP144 and BIP145
meeting comments
Some people have raised concerns about backporting segwit to 0.12. Morcos, jl2012 and btcdrak argue the benefits don’t outweigh the cost in developer time and increased risk for bugs in the backport. If the backport doesn’t get enough review and testing there won’t be a release, however it would be a shame for some people to sacrifice time backporting and reviewing if it’s not going to pass the bar.
The concern is that we don’t want to force people to quickly adopt 0.13 derived code just to catch up with segwit.
The priority now is the 0.13 release and virtually no one is using backports.
Petertodd suggest asking people to let developers know if they’d like a 0.12.2 release with segwit in the release notes of 0.13.0. He also points out people can run a 0.12 node behind a 0.13+segwit node, however miners can’t mine any segwit transaction with that setup. Gmaxwell notes it might be useful to have a deployment guide that shows things like such layering and test infrastructure, as it’s good practice to have a 2 layer setup as a way not to expose your production node to the internet.
meeting conclusion
- Wait for user feedback before doing a segwit 0.12 backport release.
Comic relief
Participants
IRC nick | Name/Nym |
---|---|
petertodd | Peter Todd |
sipa | Pieter Wuille |
gmaxwell | Gregory Maxwell |
wumpus | Wladimir van der Laan |
btcdrak | BtcDrak |
achow101 | Andrew Chow |
cfields | Cory Fields |
sdaftuar | Suhas Daftuar |
jonasschnelli | Jonas Schnelli |
MarcoFalke | Marco Falke |
luke-jr | Luke Dashjr |
jtimon | Jorge Timón |
morcos | Alex Morcos |
instagibbs | Gregory Sanders |
maaku | Mark Friedenbach |
jeremyrubin | Jeremy Rubin |
CodeShark | Eric Lombrozo |
jl2012 | Johnson Lau |
bsm117532 | Bob McElrath |
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.