IRC meeting summary for 2018-07-19

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

Topics discussed during this weekly meeting included pull requests that need to be reviewed before Monday’s feature freeze for Bitcoin Core 0.17, whether or not Bitcoin Core’s algorithm for selection of which inputs (coins) to spend should be made available as an RPC, a new way of describing which outputs the wallet should monitor and an implementation of this method for the new scantxoutset RPC, whether Pieter Wuille’s bitcoin-seeder program should become part of the Bitcoin Core GitHub organization, whether the Bitcoin Core project should stop publishing release notes and binaries to Bitcoin.org, and information about the next CoreDev Tech meeting.

Prior to the start of discussion, Wladimir van der Laan mentioned that the executables for Bitcoin Core 0.16.2 Release Candidate (RC) 2 are available for testers.

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.

A special focus of this meeting was PRs that needed to be merged in the next few days if their features are to be included in upcoming version Bitcoin Core 0.17, so reviewers are also encouraged to check the list of PRs in the 0.17 milestone.

Discussion (log): the following PRs were discussed:

• #9662 - Add create wallet “disableprivatekeys” option: a sane mode for watchonly-wallets. Requested by Jonas Schnelli; Wladimir van der Laan said it could probably be merged soon.

• #9502 - [Qt] Add option to pause/resume block downloads. Requested by Schnelli.

• #13697 - Support output descriptors in scantxoutset. Requested by Pieter Wuille with support from Schnelli. Discussed in more detail later in the meeting.

• #13666 - Always create signatures with Low R values. Requested by Wuille.

• #13426 - [Bugfix] Add u8path and u8string to fix encoding issue for Windows. Requested by Chun Kuan Lee.

• #13712 - Wallet: Fix non-determinism in ParseHDKeypath; avoid using an uninitialized variable in path calculation. Requested by Andrew Chow.

• #8469 - [POC] Introducing property-based testing to Core. Requested to be removed from the 0.17 list by Schnelli, as it’s not ready.

• #13617 - Require MacOS 10.10+. Initially requested for removal from the list, but added back after a comment by Cory Fields.

Conclusion: there were over a dozen PRs tagged for 0.17 by the end of this segment of the meeting for a review deadline of Monday.

Exposing coin selection on RPC

Background: Coin selection is the name used for how a wallet chooses which of a user’s bitcoins to spend in a particular transaction. The selected Unspent Transaction Outputs (UTXOs), often simply called coins, become inputs in the transaction. Developers have spent a significant amount of time in the past year improving Bitcoin Core’s coin selection to be able to sometimes improve privacy and lower transaction sizes (thus reducing fees) for users of Bitcoin Core’s built-in wallet, with more improvements on the way.

Discussion (log): Andrew Chow requested the topic and introduced it: “This came up in a discussion with some companies about coin selection. Basically, some are interested in using Core’s coin selection (or someone else’s) instead of having to implement/roll their own. Currently if they wanted to use Core’s coin selection, the UTXOs need to be in the wallet—i.e., the addresses and possibly keys need to be in the wallet.”

Wladimir van der Laan and Gregory Maxwell suggested that they could use the fundrawtransaction RPC to use Bitcoin Core’s coin selection. Jonas Schnelli added, “using private key disabled dynamic wallet in conjunction with fundraw seems very efficient,” referring in part to PR #9662.

Chow said, “that is not ideal for them” and Pieter Wuille followed up with, “they’d don’t want to use the wallet; they just want to be able to run coin selection.”

Several meeting participants suggested it could be done as a library, but Maxwell argued against doing it within the project as either an RPC or a library: “I am doubtful that it is worth our effort in maintaining a stable interface for such a thing. E.g. [Kalle Alm]’s recent grouping PR would’ve obliterated the interface for coin selection […] Pressure to maintain a stable interface to [coin selection] would be harmful to the project. […] I don’t want to hear ‘we can’t implement privacy feature X because it’ll break [the coin selection] interface’.”

Wladimir van der Laan said, “I think this is not a concern for our project. Some other people want a coin selection algorithm for their own purposes. [That’s] fine, they can make a library out of it themselves, the code is open source.” Maxwell suggested, “Perhaps they should contribute to making the wallet code better so they don’t have to write their own (smiley face with tongue sticking out).”

Conclusion: although the idea of an RPC method was generally opposed, Wuille did suggest a path forward: “I think the first step for this is something we’re doing anyway: making the code itself more encapsulated. Perhaps once the code is sufficiently encapsulated, someone else can librarify that and maintain it.”

#13697 which changes the API for scantxoutset

Background: recently-merged PR #12196 adds a scantxoutset RPC that allows the user to search the set of currently-spendable bitcoins (UTXO set) for any outputs that correspond to one or more specified addresses, public keys, private keys, or set of HD keys. As discussed in the June 28th meeting, Pieter Wuille is working on a new way to specify what outputs (scriptPubKeys) a wallet should look for, called Output Script Descriptors, and he has PR #13697 open to add support for that to scantxoutset instead of the current ways keys and scripts are described to the wallet.

Discussion (log): Wuille requested and introduced the topic, “first of all, this is part a bigger effort to combine keys and scripts and [HD wallet] chains into one concept. There’s a mini language to specify (sets of) scriptPubKeys, so I’d very much first want to hear comments on that language. The other question is [whether] scantxoutset [is] experimental or not, and [is it so] with descriptor support in 0.17 or not?”

Wladimir van der Laan and Jonas Schnelli both said they liked the idea of output script descriptors, and they also both supported marking scantxoutset as experimental for the 0.17 release, which will allow the project to freely change its API for subsequent releases and make it easy to incorporate feedback from users of the new RPC and new output script descriptors language.

Luke Dashjr asked, “Should [output script descriptors] be a BIP? Seems potentially useful outside Core.” Wuille replied, “potentially yes, but not in the first instance. I expect that this will evolve rather quickly.”

Conclusion: No objections were raised to the idea of marking scantxoutset experimental for the 0.17 release, or to using output script descriptors if #13697 passes review.

Bitcoin-seeder under bitcoin-core GitHub organization

Background: although Bitcoin uses a peer-to-peer protocol, nodes started for the first time don’t know the IP addresses of any peers to connect to (except for some fallback addresses for last-ditch use), so they request a list of IP address for recently-active notes from a program called a Bitcoin seeder. The node then connects to those peers and those peers can tell the new node about other peers, so all future connections can often be made completely decentralized—but a node can use the seeder again if decentralized peer finding isn’t working for it.

There are several seeder programs written by different authors. One of them is maintained by Pieter Wuille and is simply called bitcoin-seeder.

Discussion (log): Lucas Betschart requested and introduced the topic: “I thought because there are a few open issues and simple PRs for bitcoin-seeder [that] it might make sense that several Bitcoin maintainers have merge rights.”

Wuille replied, “No problem as far as I’m concerned, but I’m not sure it’s the right message.” Luke Dashjr echoed that sentiment.

Conclusion: Sjors Provoost suggested, “another approach could be for [Wuille] to give more people access to that repository?” Wuille replied, “I’m fine with that!” Betschart said, “That’s also fine with me.”

Moving away from Bitcoin.org

Background: since the 2009 release of the original Bitcoin software, Bitcoin (and later Bitcoin Core) resources have been hosted on Bitcoin.org. Over time, this was augmented with additional resources about the increasingly diverse Bitcoin network.

In December 2015 Bitcoin Core began using its own domain to host its resources, and later also to host its software releases. Release announcements and software continue to be mirrored to Bitcoin.org.

Discussion: Andrew Chow introduced the topic by suggesting “moving away from Bitcoin.org”. He added “we still link to bitcoin.org for things like downloads. [We] should probably change those”. See the log for the full discussion. Some discussion also occurred after the meeting.

Conclusion: no explicit conclusion. Post-meeting discussion seemed to indicate no significant changes to the current process.

Next CoreDev tech meeting

Background: periodically, some members of the Bitcoin Core team hold an invitation-only event mainly for contributors to Bitcoin Core to allow everyone to review and discuss various projects in person. For more information, see the CoreDev.Tech website.

Discussion (log): Steve Lee requested and introduced the topic, “I’ve volunteered to organize the next Core Dev Tech meetup. The current thinking is to have it in Tokyo in October after Scaling Bitcoin, October 8-10, and to organize it in a similar fashion as the last one in NYC.”

Several people thanked Lee.

Conclusion: Lee said, “I plan to send out a survey to collect some feedback. If anyone has specific ideas or suggestions, please feel free to contact me.”

Humor

          <sipa> what about #13666 ?
<provoostenator> What's in a number?
          <sipa> 13 and 666, can't beat those odds
        <wumpus> niice
      <achow101> it was completely planned, obviously
          <sipa> in some timezones it was also opened on
                 friday the 13th
                 oh, no
 <jonasschnelli> I hope no black cat was sitting on the
                 keyboard during coding

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.