IRC meeting summary for 2018-04-19

• Link to this week’s logs
• Meeting minutes by meetbot

Topics discussed during this weekly meeting included a recurring problem with GitHub page loads, what pull requests members of the project would like reviewers to focus on during the upcoming week, poor dependency separation between some source code files, a design for a lightweight client mode, and an update on a post-BIP150 authentication protocol with improved privacy.

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: prior to discussing particular issues, several team members mentioned that they are having chronic problems loading certain pages on GitHub, particularly pull requests with large amounts of discussion as reported in the previous week’s meeting notes. Some of these pull requests are listed as high priority for review. GitHub support has been notified about the issue previously by several meeting participants, and several more notifications were sent during the meeting.

As a potential workaround, it was suggested that perhaps the pull requests with large amount of discussion should be closed and reopened as new pull requests so that review could continue. Other workarounds were also discussed such as using web browsers with either incognito/private modes or mobile view.

The only PR specifically discussed this meeting was,

1. Do not treat bare multisig outputs as IsMine unless watched (#13002) nominated by Pieter Wuille. This PR removes the default support in Bitcoin Core’s wallet for a rare (and rather odd) use of multisig, simplifying the wallet in preparation for future possible upgrades. Users of this feature will still be able to manually use this type of multisig and migration instructions will be provided in the release notes.

Cyclic dependencies

Background: Bitcoin Core is written in the C++ programming language that allows separating information about how to use a function from the actual logic that makes the function work. This separation of definitions into header (.h) files and logic into C++ (.cpp) files can make it easier to divide up a project into a set of smaller independent modules that can be reviewed and reasoned about more easily.

Discussion: Pieter Wuille requested the topic, “I was wondering if we should have a policy against the type of cyclic dependency where the .cpp files include each other’s .h files (but not .h files include each other). That’s not a cyclic dependency for the compiler, but it does mean those two modules can’t really be used independently and is generally a sign of bad separation. […] There are a few open PRs that introduce them, so I wanted to bring it up here to see if that should be a PR merging blocker or just a ‘try to fix it up afterwards if introduced.’ I’m fine with either.”

Cory Fields replied that “indeed sounds like likely bad design that should at least be justified in the PR.” Several meeting participants agreed.

Conclusion: general agreement to comment on the issue when discovered in PRs but not to require the issue always be resolved before merging, especially in cases of desirable PRs where resolving the issue could make an already large set of code changes even larger and harder to review.

Light client mode design

Background: Bitcoin Core operates as a full node, meaning it follows the valid block chain with the most proof of work. It has been proposed that Bitcoin Core also provide a reduced capability mode where it follows the block chain with the most proof of work without checking whether every block on the chain is valid. Full node mode requires downloading every block, but a lightweight mode would require only downloading every block’s header plus some data related to transactions paying the user, which would be a very large reduction in bandwidth requirements.

Discussion: Jonas Schnelli requested the topic and referenced his PR #10794 that proposes to introduce a lightweight client mode without integrating it into the wallet. The proposed code allows users to disable automatic download of blocks and manually request the specific blocks that they want with a requestblock RPC. This can be later be extended by future PRs to allow the wallet to request download of the specific information it needs to operate.

Schnelli asked, “I’d like to get some feedback about the light client mode, [in] particular the ‘requestblock’ design, [whether] that is something we should follow or drop.” After some discussion, he clarified, “I’m only interested to know if the concept makes sense […] of having a light client mode.”

Pieter Wuille said, “the idea of having a client mode—that [absolutely makes] sense to me—but it heavily depends on how and what.” Samuel Dobson also approved of the concept.

Luke Dashjr only supported the concept of a lightweight client mode as a step in the process of “building up to a full node in the background.” The basic idea would be that Bitcoin Core could start as a lightweight client to allow users to begin receiving and spending bitcoins almost immediately and would then quietly download and validate the historic blocks necessary to become a full node.

Wuille disagreed, “It’s a perfectly valid usecase to have one full node you run yourself, and then have multiple client nodes [that] connect exclusively to it. But lightweight [clients] upgrading to full [nodes] in the background is also a very good usecase.”

Continued discussion focused on the differences and similarities between enabling a lightweight client mode and splitting up the node and wallet processes in Bitcoin Core, which is another ongoing effort.

Wuille explained, “I don’t think the goal should be separating the wallet from the node into different processes and then inventing a protocol between the two instead of just making the wallet run as a light client. The advantage of using [the peer-to-peer network protocol] as communication between node and wallet (which is what you get if you see wallets as just lightweight nodes) is that it actually [is] modularizing things: you can run any wallet software or any node software.” (Emphasis in original.)

Wuille also explained that fully implementing the lightweight client mode into Bitcoin Core is probably not as big a job as some expect, as it can “reuse all the existing full node code and P2P [network protocol] implementation, [and] just [not] do validation.”

Final comments on this topic indicated that BIP150/BIP151/BIP158 need to be implemented in the P2P network protocol in order for a lightweight client node to have all the features developers would like. Schnelli is planning to continue his work towards BIP151 and (not mentioned in the meeting) other developers are working on the basis for BIP158 support in Bitcoin Core.

Interwoven with the rest of the discussion, Cory Fields mentioned that one blocker to him being able to review is Bitcoin Core’s current download logic. “In my opinion, [the logic] is due for a bit of a cleanup/encapsulation before piling more on.” Suhas Daftuar agreed, and so did Wuille (who helped write some of the current code).

Conclusion: several participants agreed to review and comment on #10794. It’s possible that more discussion will be needed to convince everyone that a lightweight client mode is a good idea, but several participants did seem enthusiastic about the basic idea.

Update on private authentication protocols

Background: BIP150 proposes a protocol that allows two nodes to authenticate their connections with each other. As the BIP describes, this can aid in detecting man-in-the-middle attacks and permit authenticated peers to access restricted operations.

Discussion: Pieter Wuille requested the topic, “As some know, [Gregory Maxwell] and I have been thinking about authentication protocols that have better privacy than BIP150. The goal is to have a design where one node has one or more private keys, and the other node has one or more public keys. The second node learns whether one of the [first] node’s private keys matches one of [its] public keys, but nothing else. The node with the private keys does not even learn if authentication was successful, or doesn’t learn which keys it was being queried for.”

After some brief answers to questions, he continued: “The idea is that most of our connections are unauthenticated anyway (and should be [because they’re with random peers on a peer-to-peer network]) so, whatever privileges you give to authenticated nodes, you just don’t give if authentication fails. This has a very cool property that you can always run this authentication protocol even if you don’t care who the other party is. […] If you always run the authentication protocol (but if you’re not interested in authentication do it with just a randomly generated pubkey [that’s guaranteed not to match]) a [man in the middle attacker] can’t find out what you’re doing—they have to assume you’re trying to authenticate.”

A description of a previous attempt at designing such a protocol is available. Wuille notes that the protocol described in that document is broken but that the design rationale the document contains remains useful.

“Anyway, turns out this is difficult,” Wuille said. “We have a protocol that works with one [private key] and one [public key]—which means you need to run [it] many times sometimes, which doesn’t lead to great fingerprinting properties. I’m talking to some people to extend it.”

Cory Fields expressed some confusion about the purpose of the protocol. Wuille clarified that, “the whole point [of the new protocol] is avoiding having discoverable identities for things that should be identyless, but sometimes you have a node you trust already (due to external reasons, for example you run it yourself) in which case you’d configure an addnode with a known public key [for it].” The Bitcoin Core addnode RPC currently lets you connect to a specific node based on its IP address.

Mark Erhardt provided an additional explanation: “In the case that you, for example, want to connect with a thin client to your own node, the only valid key you query for is your home node’s. If you want to defend against Sybil, you may query a list of known friends and accept any of them. If you just want to scare off a [man in the middle], you query for random keys.”

Jonas Schnelli asked, “I guess this protocol would require more cryptoanalysis then the [existing] BIP150?” Wuille replied that, “I’m talking to Dan Boneh about it.” Boneh is a well-known cryptographer and professor of computer science at Stanford University who has previously helped research and develop cryptographic protocols related to Bitcoin.

Wladimir van der Laan noted, “It’d be good as a future successor to BIP150—though I guess this research shouldn’t discourage anyone from implementing BIP150 and having something working on [a] more short-term [basis].” Wuille agreed.

Conclusion: presumably Wuille and Maxwell will continue working on the protocol, possibly with the help of Boneh and others. Work on implementing BIP150 is encouraged to continue in the meantime.

Comic relief

<jonasschnelli>  I guess this protocol would require more cryptoanalysis
                 then the exiting BIP150
         <sipa>  jonasschnelli: that's ok, i'm talking to dan boneh about it
<jonasschnelli>  Good!
 <meshcollider>  Dan is the solution to all crypto problems

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.