IRC meeting summary for 2018-06-28

Overview

Topics discussed during this weekly meeting included what pull requests members of the project would like reviewers to focus on during the upcoming week, a draft specification for a new BIP39-like seed format, documenting how Bitcoin Core uses the BIP32 HD wallet standard, an update on progress towards implementing BIP151 encrypted peer-to-peer connections, and discussion surrounding a new way to describe to wallet software what output scripts they should consider part of the user’s wallet.

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 only PR specifically discussed was #12196, which adds a scantxoutset RPC to allow applications to search all current Unspent Transaction Outputs (UTXOs) for those that match a particular address, public key, private key, or HD wallet extended public key (xpub).

Pieter Wuille suggested that the PR’s author, Jonas Schnelli, remove xpub support from scantxoutset for now and Wuille would later PR an update to scantxoutset that adds support for the output script descriptors described later in these meeting notes. If Wuille is delayed in doing so, Schnelli can just add the previously-written xpub support back in before the Bitcoin Core 0.17 feature freeze. Schnelli agreed.

Note: extended discussion of output script descriptors during this part of the meeting has been moved to a separate section.

Cipherseed

Background: (Part of the discussion.)

Discussion (log): Jonas Schnelli requested and introduced the topic, “I have a specification draft for a new seed format similar to BIP39 with some neat properties and—before sending [it] to the mailing list—would appreciate feedback.”

Conclusion: Schnelli said it was “more an announcement than a topic” and so discussion was deferred until people had a chance to read the draft.

Core’s BIP32 derivation “standard”

Background: the HD wallet specification, BIP32, defines how a set of private keys and public keys (and, therefore, addresses) can be derived from a 128-bit to 512-bit random seed.

Discussion (log): Jonas Schnelli requested and introduced the topic, “It came up today in a discussion [that] Core’s BIP32 derivation scheme is not specified in a BIP. Some people think it’s vanilla/native BIP32, but it’s not, while other [wallets] do native BIP32.”

Wladimir van der Laan agreed “it would be good if the difference would be documented somewhere.” Luke Dashjr opposed it being a BIP and Pieter Wuille agreed, with Andrew Chow suggesting that “just documenting the derivation in the documentation repository is sufficient.”

Note: extended discussion of output script descriptors during this part of the meeting has been moved to a separate section.

Background: BIP151 specifies a method to allow Bitcoin nodes and clients to send their data over encrypted connections to prevent eavesdroppers from directly monitoring which particular transactions and blocks are being transmitted. This can enhance certain aspects of privacy, such as by making it harder for someone to determine which IP address was the first to transmit a particular transaction (maybe indicating that someone at that IP address created the transaction). In the BIP151 specification, both parties to the connection generate keys for just that connection and that session—destroying the keys after the connection is closed; these keys are described as “ephemeral”. Since ephemeral keys are not reused, it’s not possible to use them to identify the same node operating on different networks (e.g. Tor) or after the node changes IP addresses.

Discussion (log): Gregory Maxwell requested the topic and opened discussion with a question, “Has there been any progress towards implementing P2P link ephemeral encryption lately? I know we were kinda waiting for some other networking refactors.”

Jonas Schnelli said, “Armory has implemented it and has plans to PR it to Core (not sure how soon and in what quality).”

Cory Fields said, “I’ve had to put the network [refactor] stuff on the back burner for now, so certainly don’t wait for that. I’m happy to help with the implementation [of BIP151]. I was thinking we were waiting on the authentication stuff.”

Schnelli, Maxwell, and Pieter Wuille all agreed that BIP151 implementation shouldn’t be waiting on a proposal for authentication.

Further discussion focused on whether or not the setup protocol for the encryption (the initial handshake) should be made harder to detect and so also harder to block. However, Maxwell said, “I think we thought the benefits [of the approach considered] were too dubious, especially since traffic patterns will identify Bitcoin peer-to-peer links very clearly. […] So I think we’re good to implement, and the only changes that might be proposed would be ones that arose as a side effect of implementing and benchmarking.”

Conclusion: Schnelli said, “If no one else wants to work on the implementation, I will continue then with [my] BIP151 implementation.”

Output script descriptors

Note: this was not a tagged topic, but it was discussed during two other topics in the meeting. For easier reading, those separate discussions have been extracted from where they occurred and unified into a single topic here.

Background: Pieter Wuille has been working on a redesign of how the Bitcoin Core wallet identifies which transactions belong to a particular user’s wallet.

Discussion (log part 1, log part 2): As part of his wallet redesign, Pieter Wuille said that he has been working on a related design for human-readable descriptions of sets of scriptPubKeys that provides “a general language that encodes all information about how to spend a whole set of keys with associated addresses/scripts/private keys/… into one string, including support for multisig etc…”

This supports the proposed wallet redesign by allowing “import/export [to] operate at the level of those descriptors, instead of individual keys/scripts/pubkeys/HD [wallet key] chains. [The] importmulti [RPC] is already compatible with that design, for a large extent. The entirety of that idea is certainly not for [the next major Bitcoin Core version,] 0.17, but that doesn’t mean it can’t be used already in relatively small scoped things [like] scantxoutset.”

This lead Wuille to suggest that PR #12196 temporarily remove its extended public key support so that Wuille can allow the new scantxoutset RPC to use the output script descriptors instead.

Jonas Schnelli asked, “how would [output script descriptors] interact with the keypool, flexible keypaths, and extended public keys?” The keypool is a set of keys belonging to the user’s wallet; Bitcoin Core looks for transactions affecting those keys and adds them to the user’s wallet. Flexible keypaths refers to the BIP32 key derivation path for an HD wallet.

Wuille said that the “keypool goes away […] In practice, [the descriptor] contains the expanded pubkeys. [For] flexible keypath, the descriptor just contains the path; you can change it to whatever you’d like (but default wallets would, of course, pick some standard scheme).”

Conclusion: Wuille will continue working on output script descriptors, including a plan to open a PR adding them to the scantxoutset RPC.

Participants

IRC nick Name/Nym
jonasschnelli Jonas Schnelli
sipa Pieter Wuille
wumpus Wladimir van der Laan
gmaxwell Gregory Maxwell
cfields Cory Fields
promag Joao Barbosa
luke-jr Luke Dashjr
achow101 Andrew Chow
meshcollider Samuel Dobson
instagibbs Gregory Sanders
kanzure Bryan Bishop
jnewbery John Newbery

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.