IRC meeting summary for 2018-07-19
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.
#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
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
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.”
|wumpus||Wladimir van der Laan|
|ken2812221||Chun Kuan Lee|
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.