IRC meeting summary for 2018-06-14

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

Topics discussed during this weekly meeting included what pull requests members of the project would like reviewers to focus on during the upcoming week, whether Bitcoin Core should optimize selecting which inputs to spend based on generating transactions that don’t have change (better for privacy and fees) or transactions that only spend well-confirmed inputs (less likely to result in payment failures), and a few mini-topics mostly focused on optimizing SHA256d functions for various computer processor architectures.

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): the following pending PRs were mentioned this week:

• #12136: Implement BIP174 Partially Signed Bitcoin Transactions serialization and RPCs. Removed from the list at the request of its author, Andrew Chow, who said “It depends on #13425.”

• #13425: Moving final scriptSig construction from CombineSignatures to ProduceSignatures. Pieter Wuille commented, “#13425 is pretty much all of the [Partially-Signed Bitcoin Transactions] internal changes that are needed, excluding serialization and RPCs.”

• #13111: Add unloadwallet RPC. Meeting comments indicated this was close to being merged, after a final issue is addressed.

• #13160: Unlock spent outputs. Suggested for the high-priority list, but refused because its author already had an entry on the list. Nevertheless, Wladimir van der Laan suggested it should receive more attention.

• #13439: RPC: Avoid “duplicate” return value for invalid submitblock.

SRD [Single Random Draw] fallback coin selection

Background: several developers have been working on improving Bitcoin Core’s coin selection—how it chooses which bitcoins (inputs) to spend—to simultaneously improve privacy, reduce transaction size, and reduce fees. The current selection protocol starts with a Branch-and-Bound (BnB) algorithm that tries to find a match between the inputs available and the amount being sent. If that doesn’t work, a fallback algorithm is needed. A Single-Random-Draw (SRD) algorithm randomly adds additional inputs to a partial transaction until the sum of the inputs is equal to or greater than the amount being spent (including fees).

Discussion (log): Andrew Chow requested and introduced the topic, “I think we should discuss [Gregory Sanders’s] point here.” The cited comment says, “This new logic means that non-BnB will be tried more often. Instead of trying all variants of BnB (6 confirms, 1 confirm, small chain, etc…), we seem to be [switching to] trying 6 confirms for BnB, then 6 confirms for non-BnB. […] I prefer the [previous] behavior in master due to privacy reasons of change-less transactions.”

Pieter Wuille asked, “So this is a bit of a question on what our coin selection algorithm should prioritize: confirmed coins or (immediate) fee [reduction]?”

Sanders agreed and added, “and privacy. […] Change-less outputs mess with coin analysis to a large degree.”

Chow, and perhaps others, have performed simulations of the new behavior, the behavior from earlier versions of Bitcoin Core, and various alternatives. The conversation then briefly discussed those results and what they implied, with at least two participants indicating they wanted to see more simulations performed.

Conclusion: no explicit conclusion. Chow is running more simulations and he, Wuille, and Sanders mentioned discussing them on the PR when they’re available.

Mini-topics

• Pieter Wuille said, “I have 4 PRs open relating to optimized hardware SHA256. Should I combine them into 1 [PR], or leave like this? #13471, #13386, #13442, #13438” Wladimir van der Laan was opposed to #13438 being combined, and suggested it could be merged soon, but neither Van der Laan nor anyone else offered comment on whether or not the remaining PRs should be combined.

• Regarding #13442, this PR introduced optimized code that initially ran slower than before the optimization. Its author, Wuille, has since improved it to be faster, but he notes that it’s “very heavily compiler dependent: rearranging two lines can have 5% effect on speed, or making a constant static, […] or with particular GCC versions.” Van der Laan said, “If it becomes faster with new compilers, it’s good; if slower, not. :)”

• Some brief discussion about managing release signatures for Bitcoin Core 0.16.1.

Comic relief

<ryanofsky> cd
  <cfields> ~$

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.