IRC meeting summary for 2018-04-26
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,
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.”
getblockstatsRPC 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
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
bumpfee with a specific
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
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.”
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
-alertnotify with the proposed new RPC
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.
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.
|wumpus||Wladimir van der Laan|
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.