IRC meeting summary for 2018-04-26

• View this week’s logs on BotBot.me or MeetBot
• Meeting minutes by MeetBot

Topics discussed during this weekly meeting included whether or not “high priority for review” pull requests are getting enough review, what pull requests members of the project would like reviewers to focus on during the upcoming week, what to do with a particular parameter to the bumpfee RPC in an upgrade of that RPC, and whether or not to remove Bitcoin Core’s disabled-by-default “safe mode”.

High priority for review

Background: each meeting, Bitcoin Core developers discuss which Pull Requests (PRs) the meeting participants think most need review in the upcoming week. Some of these PRs are related to code that contributors especially want to see in the next release; others are PRs that are blocking further work or which require significant maintenance (rebasing) to keep in a pending state. Any capable reviewers are encouraged to visit the project’s list of current high-priority PRs.

Discussion (log): prior to discussing particular issues, Matt Corallo raised a concern, “we haven’t really been getting any review on the ‘high priority’ list, so [I’m] not sure the use of bringing it up every week.” Other contributors agreed that items on the list haven’t received much review in the past several weeks, but many comments seemed to be in favor of keeping the list. The topic was not explicitly resolved, but it seems that the list will continue to be used for at least another week.

The issue of some GitHub pages not loading (“unicorns”) as mentioned in the previous two weekly meeting summaries was briefly mentioned in this meeting again.

Specific PRs discussed during the meeting include,

1. Split validationinterface into parallel validation/mempool interfaces (#12979), which was previously added to the list. This PR splits up logic related to validating transactions coming into the mempool into separate validation and mempool interfaces, making it easier to get certain information about the mempool and laying the groundwork for potential improvements to Bitcoin Core’s fee estimator.

   Pieter Wuille noted that he “started reviewing #12979 but had difficulty following [it].” The PR author, Corallo, said that “it’s a pure refactor. All it is [doing] is moving things around.” Corallo also mentioned that it’s on the high-priority list because it’s “blocking about 10 other things.”

2. Introduce getblockstats RPC to [provide data that can be used to] plot things (#10757), previously nominated by Jorge Timón. This PR adds a new RPC that returns various details and statistics about a specified block.

   Anthony Towns noted that this PR received some review during the previous week but that it still had some minor outstanding issues.

The necessity of “totalFee” as an argument for bumpfee

Background: Bitcoin Core provides a bumpfee RPC to allow increasing (“bumping”) the transaction fee paid on any of the user’s unconfirmed transactions that signal BIP125 opt-in Replace-By-Fee (RBF) transaction replacability. By default, this RPC calculates the amount of the increase on its own, but it also allows the user to optionally specify the new fee to pay using the totalFee parameter.

Discussion (log): Gregory Sanders requested the topic and asked, “is [the totalFee parameter] needed? […] I was hoping to upgrade RBF/CPFP [Child Pays For Parent] in the not too distant future, but it complicates [the] logic to support [this parameter].”

Anthony Towns suggested the parameter (or a replacement) could be used instead as an upper bound on how much fee the user was willing to pay and the RPC could error out if the automatically-determined increase value exceeded that ceiling.

Sanders further described his motivation for wanting to drop the parameter: “I redid [bumpfee] to just use CreateTransaction so it will select more coins, which changes size.” In other words, adding more inputs (coins) to the replacement transaction makes the replacement larger than the original transaction and requires paying additional fees to cover the increased size—but the user won’t know that at the time they call bumpfee with a specific totalFee parameter.

Luke Dashjr, Suhas Daftuar, and Pieter Wuille all seemed to agree that totalFee doesn’t seem to make sense when changing the size of the transaction.

Conclusion: no explicit conclusion. Sanders closed the topic by suggesting he could design the upgraded bumpfee to use the new behavior of allowing additional inputs by default but optionally supporting the old behavior when totalFee is used where additional inputs will not be added and the RPC will fail when the current inputs aren’t sufficient to pay for the desired fee increase. That would be “backwards compatible without additional cruft.”

Remove safemode

Background: an early version of the Bitcoin Core software (when it was called “Bitcoin”) introduced a “safe mode” that disabled certain RPCs during network disruptions in order to try to prevent users from losing money. The criteria that triggered safe mode have changed over the years, new RPCs were rarely added to the list that were disabled in safe mode, and eventually Bitcoin Core 0.16 disabled safe mode by default.

Discussion (log): Wladimir van der Laan requested the topic, referenced PR #10563 by Andrew Chow which Van der Laan rebased as PR #13090, and asked, “safemode was disabled since 0.16; should we completely remove it for 0.17?”

Several contributors said they weren’t aware of anyone using it and didn’t think it’s currently useful. Pieter Wuille said, “disabling RPCs is not how the Bitcoin ecosystem will deal with an emergency anyway—a lot of infrastructure wouldn’t even notice.”

Van der Laan noted that Bitcoin Core will continue to provide an -alertnotify startup parameter which can be used to run an arbitrary script when safemode would have activated. Luke Dashjr suggested that -alertnotify could be used with a proposed upcoming RPC, walletunload, to disable the wallet during an emergency; that would be similar (and possibly superior) to the current safemode design.

Conclusion: although a few participants wished Bitcoin Core could be better at detecting disruptive network conditions and could automatically do something to help users avoid losing money, all participants seemed to be in favor of removing the current unsupported safe mode system. Subsequent to the meeting, #13090 was merged to remove safe mode from the development branch.

Note, during the discussion for removing safemode, the suggestion to combine -alertnotify with the proposed new RPC walletunload was misinterpreted as a request to discuss the work currently being done on walletunload. This is why “walletunload” shows up as a topic in the MeetBot meeting summary even though it was not directly discussed.

Mini-topics

One briefly discussed topic was an update on signing certificates for Bitcoin Core binaries since Cory Fields’s email about the subject to the mailing list in January. In that email, Fields said Gregory Maxwell was working on “establishing a new threshold signing scheme that will allow us to handle code signing without any single point of failure.” No update was available as Maxwell was not present for the meeting.

Comic relief

<wumpus>  #topic walletunload (Lukejr)
<LukeJr>  wumpus: I wasn't suggesting it as a topic
<wumpus>  LukeJr: oh...
  <sipa>  #unload walletunload
<wumpus>  #untopic

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.