|
| 1 | +--- |
| 2 | +title: IRC meeting summary for 2018-04-19 |
| 3 | +permalink: /en/meetings/2018/04/19/ |
| 4 | +name: 2018-04-19-meeting |
| 5 | +type: meetings |
| 6 | +layout: page |
| 7 | +lang: en |
| 8 | +version: 1 |
| 9 | +--- |
| 10 | +{% include _toc.html %} |
| 11 | +{% include _references.md %} |
| 12 | + |
| 13 | +- [Link to this week's logs](https://botbot.me/freenode/bitcoin-core-dev/msg/99172001/) |
| 14 | +- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-19-19.00.html) |
| 15 | + |
| 16 | +--- |
| 17 | + |
| 18 | +Topics discussed during this weekly meeting included a recurring problem |
| 19 | +with GitHub page loads, what pull requests members of the project would |
| 20 | +like reviewers to focus on during the upcoming week, poor dependency |
| 21 | +separation between some source code files, a design for a lightweight |
| 22 | +client mode, and an update on a post-BIP150 authentication protocol with |
| 23 | +improved privacy. |
| 24 | + |
| 25 | +## High priority for review |
| 26 | + |
| 27 | +**Background:** each meeting, Bitcoin Core developers discuss which Pull |
| 28 | +Requests (PRs) the meeting participants think most need review in the |
| 29 | +upcoming week. Some of these PRs are related to code that contributors |
| 30 | +especially want to see in the next release; others are PRs that are |
| 31 | +blocking further work or which require significant maintenance (rebasing) |
| 32 | +to keep in a pending state. Any capable reviewers are encouraged to |
| 33 | +visit the project's list of [current high-priority |
| 34 | +PRs][]. |
| 35 | + |
| 36 | +**Discussion:** prior to discussing particular issues, several team |
| 37 | +members mentioned that they are having chronic problems loading certain |
| 38 | +pages on GitHub, particularly pull requests with large amounts of |
| 39 | +discussion as reported in the previous week's meeting notes. Some |
| 40 | +of these pull requests are listed as high priority for review. GitHub |
| 41 | +support has been notified about the issue previously by several meeting |
| 42 | +participants, and several more notifications were sent during the |
| 43 | +meeting. |
| 44 | + |
| 45 | +As a potential workaround, it was suggested that perhaps the pull |
| 46 | +requests with large amount of discussion should be closed and reopened |
| 47 | +as new pull requests so that review could continue. Other workarounds |
| 48 | +were also discussed such as using web browsers with either |
| 49 | +incognito/private modes or mobile view. |
| 50 | + |
| 51 | +The only PR specifically discussed this meeting was, |
| 52 | + |
| 53 | +1. **Do not treat bare multisig outputs as IsMine unless watched |
| 54 | + ([#13002][])** nominated by Pieter Wuille. This PR removes the default |
| 55 | + support in Bitcoin Core's wallet for a rare (and rather odd) use of |
| 56 | + multisig, simplifying the wallet in preparation for future possible |
| 57 | + upgrades. Users of this feature will still be able to manually use |
| 58 | + this type of multisig and migration instructions will be provided in |
| 59 | + the release notes. |
| 60 | + |
| 61 | +## Cyclic dependencies |
| 62 | + |
| 63 | +**Background:** Bitcoin Core is written in the C++ programming language |
| 64 | +that allows separating information about how to use a function from the |
| 65 | +actual logic that makes the function work. This separation of |
| 66 | +definitions into header (.h) files and logic into C++ (.cpp) files can |
| 67 | +make it easier to divide up a project into a set of smaller independent |
| 68 | +modules that can be reviewed and reasoned about more easily. |
| 69 | + |
| 70 | +**Discussion:** Pieter Wuille requested the topic, "I was wondering if |
| 71 | +we should have a policy against the type of cyclic dependency where the |
| 72 | +.cpp files include each other's .h files (but not .h files include each |
| 73 | +other). That's not a cyclic dependency for the compiler, but it does |
| 74 | +mean those two modules can't really be used independently and is |
| 75 | +generally a sign of bad separation. [...] There are a few open PRs that |
| 76 | +introduce them, so I wanted to bring it up here to see if that should be |
| 77 | +a PR merging blocker or just a 'try to fix it up afterwards if |
| 78 | +introduced.' I'm fine with either." |
| 79 | + |
| 80 | +Cory Fields replied that "indeed sounds like likely bad design that |
| 81 | +should at least be justified in the PR." Several meeting participants |
| 82 | +agreed. |
| 83 | + |
| 84 | +**Conclusion:** general agreement to comment on the issue when |
| 85 | +discovered in PRs but not to require the issue always be resolved before |
| 86 | +merging, especially in cases of desirable PRs where resolving the issue |
| 87 | +could make an already large set of code changes even larger and harder |
| 88 | +to review. |
| 89 | + |
| 90 | +## Light client mode design |
| 91 | + |
| 92 | +**Background:** Bitcoin Core operates as a full node, meaning it follows |
| 93 | +the *valid* block chain with the most proof of work. It has been |
| 94 | +proposed that Bitcoin Core also provide a reduced capability mode where |
| 95 | +it follows the block chain with the most proof of work without checking |
| 96 | +whether every block on the chain is valid. Full node mode requires |
| 97 | +downloading every block, but a lightweight mode would require only |
| 98 | +downloading every block's header plus some data related to transactions |
| 99 | +paying the user, which would be a very large reduction in bandwidth |
| 100 | +requirements. |
| 101 | + |
| 102 | +**Discussion:** Jonas Schnelli requested the topic and referenced his PR |
| 103 | +[#10794][] that proposes to introduce a lightweight client mode without |
| 104 | +integrating it into the wallet. The proposed code allows users to |
| 105 | +disable automatic download of blocks and manually request the specific |
| 106 | +blocks that they want with a `requestblock` RPC. This can be later be |
| 107 | +extended by future PRs to allow the wallet to request download of the |
| 108 | +specific information it needs to operate. |
| 109 | + |
| 110 | +Schnelli asked, "I'd like to get some feedback about the light client |
| 111 | +mode, [in] particular the 'requestblock' design, [whether] that is |
| 112 | +something we should follow or drop." After some discussion, he |
| 113 | +clarified, "I'm only interested to know if the concept makes sense [...] |
| 114 | +of having a light client mode." |
| 115 | + |
| 116 | +Pieter Wuille said, "the idea of having a client mode---that [absolutely |
| 117 | +makes] sense to me---but it heavily depends on how and what." |
| 118 | +Samuel Dobson also approved of the concept. |
| 119 | + |
| 120 | +Luke Dashjr only supported the concept of a lightweight client mode as a |
| 121 | +step in the process of "building up to a full node in the background." |
| 122 | +The basic idea would be that Bitcoin Core could start as a lightweight |
| 123 | +client to allow users to begin receiving and spending bitcoins almost |
| 124 | +immediately and would then quietly download and validate the historic |
| 125 | +blocks necessary to become a full node. |
| 126 | + |
| 127 | +Wuille disagreed, "It's a perfectly valid usecase to have one full node |
| 128 | +you run yourself, and then have multiple client nodes [that] connect |
| 129 | +exclusively to it. But lightweight [clients] upgrading to full [nodes] |
| 130 | +in the background is also a very good usecase." |
| 131 | + |
| 132 | +Continued discussion focused on the differences and similarities between |
| 133 | +enabling a lightweight client mode and splitting up the node and wallet |
| 134 | +processes in Bitcoin Core, which is another ongoing effort. |
| 135 | + |
| 136 | +Wuille explained, "I don't think the goal should be separating the |
| 137 | +wallet from the node into different processes and then inventing a |
| 138 | +protocol between the two instead of just making the wallet run as a light |
| 139 | +client. The advantage of using [the peer-to-peer network protocol] as |
| 140 | +communication between node and wallet (which is what you get if you see |
| 141 | +wallets as just lightweight nodes) is that it actually [is] modularizing |
| 142 | +things: you can run *any* wallet software or *any* node software." |
| 143 | +(Emphasis in original.) |
| 144 | + |
| 145 | +Wuille also explained that fully implementing the lightweight client |
| 146 | +mode into Bitcoin Core is probably not as big a job as some expect, as it |
| 147 | +can "reuse all the existing full node code and P2P [network protocol] |
| 148 | +implementation, [and] just [not] do validation." |
| 149 | + |
| 150 | +Final comments on this topic indicated that |
| 151 | +[BIP150][]/[BIP151][]/[BIP158][] need to be implemented in the P2P |
| 152 | +network protocol in order for a lightweight client node to have all the |
| 153 | +features developers would like. Schnelli is planning to continue his |
| 154 | +work towards BIP151 and (not mentioned in the meeting) other developers |
| 155 | +are working on the basis for BIP158 support in Bitcoin Core. |
| 156 | + |
| 157 | +Interwoven with the rest of the discussion, Cory Fields mentioned that |
| 158 | +one blocker to him being able to review is Bitcoin Core's current |
| 159 | +download logic. "In my opinion, [the logic] is due for a bit of a |
| 160 | +cleanup/encapsulation before piling more on." Suhas Daftuar agreed, and |
| 161 | +so did Wuille (who helped write some of the current code). |
| 162 | + |
| 163 | +**Conclusion:** several participants agreed to review and comment on |
| 164 | +#10794. It's possible that more discussion will be needed to convince |
| 165 | +everyone that a lightweight client mode is a good idea, but several |
| 166 | +participants did seem enthusiastic about the basic idea. |
| 167 | + |
| 168 | +## Update on private authentication protocols |
| 169 | + |
| 170 | +**Background:** BIP150 proposes a protocol that allows two nodes to |
| 171 | +authenticate their connections with each other. As the BIP describes, |
| 172 | +this can aid in detecting man-in-the-middle attacks and permit |
| 173 | +authenticated peers to access restricted operations. |
| 174 | + |
| 175 | +**Discussion:** Pieter Wuille requested the topic, "As some know, |
| 176 | +\[Gregory Maxwell] and I have been thinking about authentication |
| 177 | +protocols that have better privacy than [BIP150][]. The goal is to have a |
| 178 | +design where one node has one or more private keys, and the other node |
| 179 | +has one or more public keys. The second node learns whether one of the |
| 180 | +[first] node's private keys matches one of [its] public keys, but |
| 181 | +*nothing* else. The node with the private keys does not even learn if |
| 182 | +authentication was successful, or doesn't learn which keys it was being |
| 183 | +queried for." |
| 184 | + |
| 185 | +After some brief answers to questions, he continued: "The idea is that |
| 186 | +most of our connections are unauthenticated anyway (and should be |
| 187 | +[because they're with random peers on a peer-to-peer network]) so, |
| 188 | +whatever privileges you give to authenticated nodes, you just don't give |
| 189 | +if authentication fails. This has a very cool property that you can |
| 190 | +*always* run this authentication protocol even if you don't care who the |
| 191 | +other party is. [...] If you always run the authentication protocol |
| 192 | +(but if you're not interested in authentication do it with just a |
| 193 | +randomly generated pubkey [that's guaranteed not to match]) a [man in the |
| 194 | +middle attacker] can't find out what you're doing---they have to assume |
| 195 | +you're trying to authenticate." |
| 196 | + |
| 197 | +A [description of a previous |
| 198 | +attempt](https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b) |
| 199 | +at designing such a protocol is available. Wuille notes that the |
| 200 | +protocol described in that document is broken but that the design |
| 201 | +rationale the document contains remains useful. |
| 202 | + |
| 203 | +"Anyway, turns out this is difficult," Wuille said. "We have a |
| 204 | +protocol that works with one [private key] and one [public key]---which |
| 205 | +means you need to run [it] many times sometimes, which doesn't lead to |
| 206 | +great fingerprinting properties. I'm talking to some people to extend |
| 207 | +it." |
| 208 | + |
| 209 | +Cory Fields expressed some confusion about the purpose of the protocol. |
| 210 | +Wuille clarified that, "the whole point [of the new protocol] is |
| 211 | +avoiding having discoverable identities for things that should be |
| 212 | +identyless, but sometimes you have a node you trust already (due to |
| 213 | +external reasons, for example you run it yourself) in which case you'd |
| 214 | +configure an addnode with a known public key [for it]." The Bitcoin Core |
| 215 | +`addnode` RPC currently lets you connect to a specific node based on its IP |
| 216 | +address. |
| 217 | + |
| 218 | +Mark Erhardt provided an additional explanation: "In the case that you, |
| 219 | +for example, want to connect with a thin client to your own node, the |
| 220 | +only valid key you query for is your home node's. If you want to defend |
| 221 | +against Sybil, you may query a list of known friends and accept any of |
| 222 | +them. If you just want to scare off a [man in the middle], you query for |
| 223 | +random keys." |
| 224 | + |
| 225 | +Jonas Schnelli asked, "I guess this protocol would require more |
| 226 | +cryptoanalysis then the [existing] BIP150?" Wuille replied that, "I'm |
| 227 | +talking to Dan Boneh about it." Boneh is a well-known cryptographer and |
| 228 | +professor of computer science at Stanford University who has previously |
| 229 | +helped research and develop cryptographic protocols related to Bitcoin. |
| 230 | + |
| 231 | +Wladimir van der Laan noted, "It'd be good as a future successor to |
| 232 | +BIP150---though I guess this research shouldn't discourage anyone from |
| 233 | +implementing BIP150 and having something working on [a] more short-term |
| 234 | +[basis]." Wuille agreed. |
| 235 | + |
| 236 | +**Conclusion:** presumably Wuille and Maxwell will continue working on |
| 237 | +the protocol, possibly with the help of Boneh and others. Work on |
| 238 | +implementing BIP150 is encouraged to continue in the meantime. |
| 239 | + |
| 240 | +## Comic relief |
| 241 | + |
| 242 | +{% highlight text %} |
| 243 | +<jonasschnelli> I guess this protocol would require more cryptoanalysis |
| 244 | + then the exiting BIP150 |
| 245 | + <sipa> jonasschnelli: that's ok, i'm talking to dan boneh about it |
| 246 | +<jonasschnelli> Good! |
| 247 | + <meshcollider> Dan is the solution to all crypto problems |
| 248 | +{% endhighlight %} |
| 249 | + |
| 250 | +## Participants |
| 251 | + |
| 252 | +| IRC nick | Name/Nym | |
| 253 | +|-----------------|---------------------------| |
| 254 | +| sipa | [Pieter Wuille][] | |
| 255 | +| jonasschenlli | [Jonas Schnelli][] | |
| 256 | +| wumpus | [Wladimir van der Laan][] | |
| 257 | +| cfields | [Cory Fields][] | |
| 258 | +| luke-jr | [Luke Dashjr][] | |
| 259 | +| instagibbs | [Gregory Sanders][] | |
| 260 | +| jnewbery | [John Newbery][] | |
| 261 | +| meshcollider | [Samuel Dobson][] | |
| 262 | +| jamesob | [James O'Beirne][] | |
| 263 | +| kanzure | [Bryan Bishop][] | |
| 264 | +| achow101 | [Andrew Chow][] | |
| 265 | +| sdaftuar | [Suhas Daftuar][] | |
| 266 | +| promag | [Joao Barbosa][] | |
| 267 | +| aj | [Anthony Towns][] | |
| 268 | +| Murch | [Mark Erhardt][] | |
| 269 | +| jtimon | [Jorge Timón][] | |
| 270 | +| ryanofsky | [Russell Yanofsky][] | |
| 271 | +| phantomcircuit | [Patrick Strateman][] | |
| 272 | + |
| 273 | + |
| 274 | +## Disclaimer |
| 275 | + |
| 276 | +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. |
| 277 | + |
| 278 | +[#10794]: https://github.com/bitcoin/bitcoin/issues/10794 |
| 279 | +[#13002]: https://github.com/bitcoin/bitcoin/issues/13002 |
| 280 | +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 |
| 281 | + |
0 commit comments