IRC meeting summary for 2018-07-05

• View this week’s log on BotBot.me or MeetBot (part 1) and MeetBot (part 2)
• Meeting minutes by MeetBot part 1 and part 2

MeetBot minutes and logs are split into two parts this week because the initial meeting chairperson had to leave mid-meeting.

Topics discussed during this weekly meeting included what pull requests members of the project would like reviewers to focus on during the upcoming week (especially in light of the upcoming feature freeze for Bitcoin Core 0.17), alternating the time of the weekly meeting, and reducing the default minimum relay fee.

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): Wladimir van der Laan stared the discussion by saying, “looks like there is only one thing left: #12196,” which adds a scantxoutset RPC method. He then added, “reminder that the 0.17 feature freeze is 2018-07-16, so in roughly a week.” After that date, contributors are discouraged from proposing PRs containing new features for the upcoming 0.17 release so that everyone can focus on finding and eliminating any bugs or other misbehaviors prior to release.

With that deadline approaching, meeting participants suggested the following PRs be added to the high priority list:

• #13547: Make signrawtransaction give an error when amount is needed but missing. Suggested by AJ Towns and supported by Pieter Wuille.

• #12458: Enforce that amount is provided for signrawtransaction prevtxs. Suggested by Towns and supported by Wuille.

• #13072: Update createmultisig RPC to support segwit . Suggested by Towns and supported by Wuille.

• #11658: During IBD, when doing pruning, prune 10% extra to avoid pruning again soon after. Suggested by Sjors Provoost.

• #13557: BIP174 PSBT serializations and RPCs. Requested or supported by Van der Laan, Wuille, Andrew Chow, and Gregory Maxwell.

• #13298: Net: Random delays per network group to obfuscate transaction time. Suggested by Gleb Naumenko, clearly supported by Maxwell, and possibly supported by Wuille.

• #13414: Support Gitlab API in github-merge.py. Requested by r-f, but mentioned as probably not relevant to Bitcoin Core 0.17 by Van der Laan.

Conclusion: all PRs mentioned above except the last, #13414, were added to the high-priority list.

Alternating meeting time

Background: the weekly Bitcoin Core meeting is held at the same time each week, Thursdays at 19:00 UTC. Converted to local time by AJ Towns (using northern hemisphere daylight savings time), this corresponds to the local times:

Those times are particularly inconvenient for Bitcoin Core contributors located in Oceania and East Asia.

Discussion (log): Sjors Provoost requested the topic and introduced it with a suggestion, “my suggestion would be something trivial, e.g. alternate by 12 hours every week.”

Some meeting participants had concerns about that time or about the confusion resulting from alternating meeting times, although Wladimir van der Laan noted that, “The problem is that the people in favor of [a different] time will likely not be here now, [so] it’s unfair.”

Towns suggested “a three-phase cycle of 8 hours ought to make everyone able to attend 2 of 3 meetings :-/”. After the meeting, Towns would provide the following map of such a potential schedule:

Conclusion: it was ultimately suggested that someone create a poll to help find which meeting times would be acceptable to the different contributors, and Cory Fields agreed to manage the poll.

[Reducing the default] min relay fee

Background: Bitcoin Core won’t accept transactions into its memory pool (mempool) unless they pay a minimum fee of 0.00001000 BTC per virtual kilobyte (vKB), sometimes written as 1 satoshi per byte (1 sat/B). This minimum fee level was set several years ago when the price per bitcoin (in USD terms) was about 1/10th what it is now, and so it may be too high—especially since nodes have recently rarely seen more than a few blocks worth of transactions in their mempools.

Bitcoin Core also has a separate setting for minimum incremental relay fee that helps prevent abuse of the replace-by-fee mechanism but which interacts with the minimum relay fee.

Discussion (log): a discussion on Twitter was referenced that suggested the minimum relay fee should be reduced or, ideally, eliminated. Gregory Maxwell said, “our infrastructure is setup to have a minimum. The amount of relay spam per dollar tends to infinity as the fee goes to zero.”

Pieter Wuille noted that the “minimum relay fee has limited impact, because if the transaction rate goes up as a result [of low fees], dynamic feerate kicks in.” That increases the feerate up to the level where newly-received transactions are only accepted if they pay a feerate competitive with the cheapest transaction currently in the mempool.

However, Wuille mentioned that the related incremental relay fee has to be set to a sane amount to prevent node bandwidth from being abused.

IRC user Booyah mentioned that, “there are wallets like Mycelium that sometimes miscalculated and when preparing a 1 sat/B transaction, end up with 0.97.. sat/B actual transaction and can not broadcast it currently.” AJ Towns confirmed that Xapo had a similar bug and described why it happened: “the signatures were slightly bigger than [the wallet] estimated, and [so the] 1 sat/B target ended up at 0.9something sat/B and wouldn’t propagate.”

Meeting participants agreed that there’s nothing to do to fix that. As Luke Dashjr said, “if [the minimum relay fee] was 0.5 sat/B, they’d end up [paying] 0.49.”

Dashjr suggested that the developers not make any changes and instead let users campaign amongst themselves to encourage changing the value. But Wuille noted that setting the value low has a downside related to BIP152: “it reduces compact block relay efficiency, though. Node operators generally have an incentive to pick the same values as miners.”

Related to trying to develop a design that has no minimum relay fee, Maxwell said, “Trying to make things work minrelayfeeless is probably not worth the effort. There is a bunch of stupid behavior that having a low but non-zero minimum avoids.”

Conclusion: Maxwell said, “I’ll PR something around halving it.”

Comedic relief

<gmaxwell> probably rather than discussing this here 
           someone should go make some proposals (including 
           times in common timezones).
<cfields> those annoying doodle availability polls handle
          this really well.
<sipa> cfields just volunteered? :)

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. In particular, quotes taken from the discussion had their capitalization, punctuation, and spelling modified to produce consistent sentences. Bracketed words and fragments, as well as background narratives and exposition, were added by the author of this summary and may have accidentally changed the meaning of some sentences. If you believe any quote was taken out of context, please open an issue and we will correct the mistake.