IRC meeting summary for 2018-05-31

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, when the project should upgrade the codebase and build system to use the C++14 standard, what design considerations to account for in an extended addr message for the peer-to-peer network protocol, and how to filter out altcoin nodes claiming to be Bitcoin nodes for those who host Bitcoin DNS seeders.

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 PRs were nominated for the high-priority list. All were added.

  • #13062: Make script interpreter independent from storage type CScript (requested by Pieter Wuille)

  • #13111: Add unloadwallet RPC (requested by Joao Barbosa)

  • #11082: Add new bitcoin_rw.conf file that is used for settings modified by this software itself (requested by Luke Dashjr)

  • #13058: [wallet] createwallet RPC - create new wallet at runtime (requested by Jonas Schnelli, but may have already been on the list)

C++14

Background: the C++ programming language Bitcoin Core is written in is defined by a specification and implemented by multiple different compilers and standard libraries. Periodically, new specifications are issued, compilers and standard libraries are updated, and projects such as Bitcoin Core need to decide when they’re going to upgrade from using the old compilers and standard libraries to the newer versions. The C++ specification currently used by Bitcoin Core is known as C++11; a more recent specification is C++14.

Discussion (log): Pieter Wuille requested the topic and introduced it: “Given that [the testing and build infrastructure] will be built on [Ubuntu] Bionic, that may open the door to using more modern compilers which support C++14.”

Wladimir van der Laan referenced the project’s tracking issue for the subject, #13356.

Discussion revolved around which operating systems supported which versions of C++, but also discussed the last time the project changed major C++ versions, where at least one large miner didn’t upgrade for a long time because they were running an old operating system that didn’t support the new C++ version and were compiling their old binaries.

Conclusion: no changes are being made now. Wuille suggested, “how about we see after [version] 0.17 branches off, or even later in the 0.18 cycle. There’s nothing we can decide here right now—just bringing up potential issues is good in advance.”

New “addr” P2P message to support 256-bit IP addresses

Background: Bitcoin’s peer-to-peer network protocol uses an addr message to allow nodes to tell their peers about any nodes that may be accepting incoming connections; this allows nodes to find new peers without centralized coordination. The current addr message only supports address up to 128 bits, which is enough for legacy IP addresses (IPv4), modern IP addresses (IPv6), and older-style Tor .onion hidden services—but it doesn’t support newer-style Tor hidden services nor peers on the I2P anonymity network, both of which require 256 bits.

Discussion (log): Wladimir van der Laan requested the topic and said, “I’d like to work on this. First a BIP, of course. [Is there] anything special I should take into account? My idea would be to introduce a new addr message with more space for the network address, […] to support I2P and the new TorV3 hidden services.”

Luke Dashjr suggested adding “8 bits to select a network schema.” Van der Laan agreed. Dashjr also suggested adding multi-bit service flags, but Van der Laan was opposed to that, “I don’t want too much scope creep.”

Olaluwa Osuntokun, Pieter Wuille, and others discussed distributing a node’s public key along with its IP address in the new addr message. Osuntokun was in favor of the idea, but others were opposed, saying that it “leaked identity” and that “most connections don’t need [man in the middle] protection, as there is no identity of the peer they’re connecting to. […] The issue is being able to correlate multiple IP addresses belonging to the same node.”

Suhas Daftuar asked if the new messages could advertise what blocks the node was willing to serve to its peers and clients. This was discussed without resolution.

Conclusion: Van der Laan will write and circulate a proposal for discussion. Subsequent to the meeting, he published the document and linked to it from tracking issue #2091.

Seeder hardening

Background: for nodes connecting to the network for the first time and light clients who use the peer-to-peer protocol, several well-known community members host DNS seeders that distribute a list of IP addresses for nodes they know about. Three of the people hosting seeds were in the meeting: Pieter Wuille, Jonas Schnelli, and Matt Corallo. Wuille and Corallo are also, separately, authors of software used for seeding.

Discussion (log): Jonas Schnelli requested the topic and introduced it, “It seems like most active DNS seeds pass around ABC/BCash peers. It’s a cat and mouse game, but we could tighten the screws by checking for a recent block during crawling (expensive) or avoid protocol version >80000.”

Pieter Wuille checked his seeder and found “I don’t seem to have many ABC nodes: thirty in my top 100,000 IPs; thirteen in my top 10,000, and one in my top 1,000.” Schnelli had fifty-eight in his top 1,000, but he suggested that maybe the problem he’s seeing is the result of a configuration difference, and several possible configuration settings were discussed.

Conclusion: Schnelli will continue adjusting his configuration in an attempt to eliminate the peers who don’t serve current Bitcoin blocks. Other seeders may wish to monitor the peers they’re serving a bit more closely than normal.

Mini topics

  • Cory Fields asked, “any update on the GitHub unicorns [where pages on GitHub wouldn’t load and instead displayed an illustration of a unicorn]? I don’t remember seeing any this week, though something about my browser must make them rare for me.” Several meeting participants replied that the non-loading pages have been fixed, and Fields replied, “Woohoo!”

Participants

IRC nick Name/Nym
wumpus Wladimir van der Laan
sipa Pieter Wuille
jonasschnelli Jonas Schnelli
BlueMatt Matt Corallo
luke-jr Luke Dashjr
cfields Cory Fields
gmaxwell Gregory Maxwell
roasbeef Olaoluwa Osuntokun
promag Joao Barbosa
jimpo Jim Posen
sdaftuar Suhas Daftuar
MarcoFalke Marco Falke
ajtowns[m] Anthony Towns
kanzure Bryan Bishop
morcos Alex Morcos

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.