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

<sipa>        well, any reason not use vsize?
<petertodd>   sipa: vsize is fine
<wumpus>      yes vsize is fine
<gmaxwell>    V means validation?
<sipa>        virtual
<btcdrak>     v for vendetta

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.