IRC meeting summary for 2017-05-25

• Link to this week logs
• Meeting minutes by meetbot

Notes / short topics

• Bitcoin Core 0.14.2 should be released with a security fix for users who manually enable the UPnP option, as well as other smaller bugfixes.

Main topics

• multiwallet concept
• variable naming style
• BIP 148

multiwallet concept

background

A new feature for Bitcoin Core that is aimed to be included in 0.15 is the ability to handle multiple separate wallets at the same time. There’s a project page on github for all PR’s and issues related to multiwallet support.

meeting comments

Jonasschnelli has some questions to think about, namely whether we want the wallet creation/loading to be while the software is running or per startup. Long term we should want both, but as a first step for 0.15 the latter is more realistic.

Another question is what should happen with the -rescan/-zapwallettxes/-salvagewallet/-upgradewallet commands. Sipa would just disable -rescan when more than one wallet is configured initially. Ideally we move it to runtime over RPC so the commands would become wallet-specific. Gmaxwell thinks -zapwallettxes and -salvagewallet should go away ultimately, or be moved to another tool. Sipa suggests removing -zapwallettxes in favor of abandontransaction, replacing -salvagewallet with a standalone tool and leaving -upgradewallet to apply to all wallets. Jonasschnelli has started working on a standalone wallet tool in the past, but had problems with circular dependencies. Cfields thinks we could get that worked out though.

We should also consider wallet flags combined with the new wallet database, Jonasschnelli has implemented wallet flags here. Flags could be used to indicate the use of HD, chain split, etc. As the HD chain-split is not backwards compatible in 0.15, ideally we’d put in everything we’d need further on to avoid breaking backwards compatibility in 0.16.

meeting conclusion

• Make sure to get a least basic multiwallet support in 0.15

variable naming style

background

Various coding styles have been used during the history of the Bitcoin Core codebase, and the result is not very consistent. There’s been an effort to make it more uniform with some developer guidelines so the coding style will slowly converge to a single style.

meeting comments

Sipa noticed several people writing patches with variable names that look like they’re hungarian, but aren’t. Currently there isn’t any convention specified in the developer notes, so people copy the style around the code. In order to make people stop mimicking the style there should be a style prescribed in the developer notes. Luke-jr likes the idea of only making style changes when there’s new code, avoiding loads of PRs that only rename variables. One choice to make is to have either camelCase or under_score. The downside of camelCase is that it’s easily confused with the hungarian notation.

Most developers want something to identify global and local variables. Sipa proposes to have lowercase and underscore for local variables, ‘m_’ for members and ‘g_’ for globals. Wumpus notes method names should stick to camelCase.

meeting conclusion

• Sipa will write up a PR to add to the developer notes explaining the new style guidelines for variable names.
• “Do not attempt to match nearby code” should be explicitly mentioned in the notes.

BIP 148

background

BIP148 is a proposal to activate segwit by having a flagday on August 1st 2017 which will reject blocks that don’t signal for segwit, thereby forcing activation of segwit via the BIP9 mechanism. This proposal is a response to the inaction of miners who block the activation of segwit, despite broad support from the technical community, industry and users.

meeting comments

Sipa thinks it would go against the principles of the Core project to merge BIP148 into Core as it encourages forks in the network and it’s not our place to push for consensus changes. There’s already been a lot of discussions going on around BIP148 in the relevant PRs, namely #10417, #10428 and #10442 as well as the mailinglist. Luke-Jr argues not including it puts users at risk as there will be a fork created by alternative clients which might end up replacing the chain when successful. Gmaxwell argues there isn’t broad support for it which would justify that position.

Wumpus, BlueMatt, Jtimon, Gmaxwell and Morcos would favor BIP149 over BIP148.

Sipa hopes there will be enough economical support, but expects that every economically relevant full node will revert away from bip148 code hours after the hashrate fails to adopt it.

meeting conclusion

• Only merge BIP148 if there is enough economical support for it.

Comic relief

wumpus           #topic variable naming style
cfields  would kill for m_ == member
luke-jr          pls don't kill


sipa             i'll write up a PR, and we discuss there further?
morcos           sounds good
gmaxwell         sipa to do all the work, agreed.

Participants

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.