|
| 1 | +--- |
| 2 | +title: IRC meeting summary for 2018-05-24 |
| 3 | +permalink: /en/meetings/2018/05/24/ |
| 4 | +name: 2018-05-24-meeting |
| 5 | +type: meetings |
| 6 | +layout: page |
| 7 | +lang: en |
| 8 | +version: 1 |
| 9 | +--- |
| 10 | +{% include _toc.html %} |
| 11 | +{% include _references.md %} |
| 12 | + |
| 13 | +- View this week's log on [BotBot.me](https://botbot.me/freenode/bitcoin-core-dev/msg/100407600/) or [MeetBot][mb log] |
| 14 | +- [Meeting minutes by MeetBot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-24-19.00.html) |
| 15 | + |
| 16 | +--- |
| 17 | + |
| 18 | +Topics discussed during this weekly meeting included what issues need to |
| 19 | +be resolved before generating the first release candidate for version |
| 20 | +0.16.1, whether transaction relay should be delayed a bit more in order |
| 21 | +to potentially increase spender privacy, how to store settings set |
| 22 | +internally by Bitcoin Core GUI and daemon so that both programs can |
| 23 | +access them, and whether Bitcoin Core should add a feature for scanning |
| 24 | +the UTXO set even though it might (hypothetically) not store the UTXO |
| 25 | +set in a scanable form in the future. |
| 26 | + |
| 27 | +## [What needs to be done for] 0.16.1 |
| 28 | + |
| 29 | +**Background:** Bitcoin Core contributors are working towards releasing |
| 30 | +Bitcoin Core 0.16.1, a [maintenance release][] that will contain |
| 31 | +bug fixes and minor improvements. |
| 32 | + |
| 33 | +**Discussion ([log][log 0.16.1 todo]):** Wladimir van der Laan proposed the topic and |
| 34 | +dove right into discussing what needed to be done, which appeared to be |
| 35 | +getting reviews on Pull Request (PR) [#13317][]. There was some |
| 36 | +discussion about whether PRs not related to 0.16.1 should be |
| 37 | +given high priority, which Van der Laan opposed "I think we should focus |
| 38 | +on 0.16.1 now; we'll get around to the other high priority stuff again |
| 39 | +next week." |
| 40 | + |
| 41 | +Two PRs were proposed for backporting, [#12172][] and [#12431][], but |
| 42 | +both were argued against as either problematic or unnecessary. |
| 43 | + |
| 44 | +**Conclusion:** reviewers are encouraged to view [#13317][]. |
| 45 | + |
| 46 | +## Random delays per network group to obfuscate transaction time |
| 47 | + |
| 48 | +**Background:** many years ago, when Bitcoin software received a |
| 49 | +transaction, it shortly thereafter attempted to relay it to its other |
| 50 | +peers. This allowed transaction analysis organizations to connect to |
| 51 | +lots of nodes and assume that the first node they received a transaction |
| 52 | +announcement from was probably the node who created it (or, at least, |
| 53 | +was one of the first to relay it). In Bitcoin version 0.2.10, a feature |
| 54 | +was added that caused nodes to wait a different amount of time for |
| 55 | +different groups of peers before relaying them new transactions; this |
| 56 | +caused transactions to spread through the network less predictably to |
| 57 | +increase spender privacy. Subsequent releases have improved upon this |
| 58 | +basic feature. |
| 59 | + |
| 60 | +PR [#13298][] describes a possible counter to the above method: |
| 61 | +transaction analysis organizations connect multiple times to each node, |
| 62 | +increasing the chance that they will hear about a transaction earlier |
| 63 | +rather than latter, and therefore increasing the chance that the first |
| 64 | +node they receive a transaction from is its original sender. That same |
| 65 | +PR also provides a method to make multiple connections more expensive |
| 66 | +for the analysis organization by causing the random delays to be based |
| 67 | +on network groups (large blocks of IP addresses) rather than individual |
| 68 | +nodes, so that analysis organizations need to get access to specific IP |
| 69 | +address ranges in order to obtain the same chance of being an early |
| 70 | +receiver |
| 71 | + |
| 72 | +**Discussion ([log][log random relay delays]):** Pieter Wuille requested |
| 73 | +the topic and described what he'd like to see: "I want to bring up |
| 74 | +[#13298][] briefly [...] It's a possibly significant effect on P2P |
| 75 | +transaction relay and it needs review beyond 'does the code work.' But |
| 76 | +it's also just local policy and not something that warrants a BIP [in my |
| 77 | +honest opinion]. Maybe there's not much more to say about that, [I'm] |
| 78 | +just hoping to get people to think about it a bit." |
| 79 | + |
| 80 | +The possibly significant effect on P2P transaction relay would |
| 81 | +lengthening the amount of time it takes a transaction (but not a block) |
| 82 | +to propagate from its originating peer to 90% or more of the other nodes. |
| 83 | + |
| 84 | +**Conclusion:** there was no discussion, just a recommendation for |
| 85 | +reviewers to visit the PR, consider its effects, and provide comments |
| 86 | +with any recommendations. |
| 87 | + |
| 88 | +## GUI prune setting and writable config files |
| 89 | + |
| 90 | +**Background:** Bitcoin Core provides command line options and a |
| 91 | +user-editable configuration file (`bitcoin.conf`) but it also allows |
| 92 | +users to change some of the same settings in the Graphical User |
| 93 | +Interface (GUI). Currently these two sets of settings are stored in |
| 94 | +different places because the GUI can't change the configuration file |
| 95 | +(on some systems, it's read-only, and in all cases it may contain user |
| 96 | +comments and formatting that an automated configuration editor might |
| 97 | +break). However, this creates several problems, where a user changes a |
| 98 | +setting in one place and it either does or doesn't apply in the other |
| 99 | +place unexpectedly. The latest case of a shared setting is PR |
| 100 | +[#13043][] adding to a GUI the ability to control the pruning previously |
| 101 | +available from the command line and configuration file. |
| 102 | + |
| 103 | +**Discussion ([log][log gui prune]):** Sjors Provoost requested the |
| 104 | +topic and suggested three solutions to the problem of where to store |
| 105 | +settings shared between different Bitcoin Core programs: |
| 106 | + |
| 107 | +1. "Ignore the problem." Continue with the current system. |
| 108 | + |
| 109 | +2. "Go the writable config file route." (Discussion goes into more |
| 110 | + detail later.) |
| 111 | + |
| 112 | +3. "Interpret a lack of `prune=` setting differently." Give an option |
| 113 | + specified in a configuration file precedence over an option |
| 114 | + configured in the GUI. |
| 115 | + |
| 116 | +Provoost added, "if we go for [option] 2, then I'd like to nominate |
| 117 | +[PR] [#11082][] for priority review." That PR adds a new |
| 118 | +`bitcoin_rw.conf` file for settings modified by the software. Unlike |
| 119 | +the Qt settings, the file can be shared between both Bitcoin Core's |
| 120 | +daemon and GUI, and the file would be explicitly marked as not intended |
| 121 | +to support comments, whitespace-based formatting, and other conveniences |
| 122 | +for human editing. |
| 123 | + |
| 124 | +Jonas Schnelli complained, "do we want four(!) levels of configuration? |
| 125 | +Conf[iguration file] <-> startup [command line interface parameters] <-> |
| 126 | +Qt Settings <-> level 4 [`bitcoin_rw.conf`]." |
| 127 | + |
| 128 | +Provoost explained, "I'd also like to get rid of Qt settings completely |
| 129 | +[...] I wrote a migration away from QTSettings [in PR] [#12833][]." |
| 130 | +Schnelli was satisfied by this option and said, "thanks [Provoost] for |
| 131 | +working on that!" |
| 132 | + |
| 133 | +Gregory Sanders suggested the "user could, by and large, be migrated |
| 134 | +over to the [`bitcoin_rw.conf`] unless they have a need for read-only." |
| 135 | +Wladimir van der Laan argued against this, "well, the `bitcoin.conf` is |
| 136 | +for human editing; the [`bitcoin_rw.conf`] is machine writable, all |
| 137 | +comments will be discarded, etc..." |
| 138 | + |
| 139 | +**Conclusion:** no explicit conclusion; meeting participants seemed to |
| 140 | +be in favor of moving forward with creating a `bitcoin_rw.conf` to store |
| 141 | +settings modified by the software. There was some unresolved discussion |
| 142 | +about whether currently-open PRs that modify settings should wait for |
| 143 | +`bitcoin_rw.conf` to become available before being merged, or should use |
| 144 | +the existing sub-optimal Qt Settings mechanism. |
| 145 | + |
| 146 | +## ScanTxOutSet RPC command |
| 147 | + |
| 148 | +**Background:** The Bitcoin Core software maintains a [key-value |
| 149 | +database][] of every Unspent Transaction Output (UTXO)---that is, every |
| 150 | +spendable group of bitcoins and the conditions that need to be fulfilled |
| 151 | +in order to spend them. The database is not designed for access by more |
| 152 | +than one program at once and is not API stable, meaning other programs |
| 153 | +can't easily read from it, and so there's currently no convenient way |
| 154 | +for other programs to retrieve information from the UTXO set. |
| 155 | + |
| 156 | +**Discussion ([log][log scantxoutset]):** Jonas Schnelli requested the |
| 157 | +topic and introduced it: "[Pieter Wuille] raised concerns about the |
| 158 | +`scantxoutset` command [proposed in PR #12196]. Before continuing on |
| 159 | +[PR] [#12196][], we may want to discuss if it makes sense[...]. The scan |
| 160 | +functionality allows UTXO sweeping (`rawsweeptransaction`) with no block |
| 161 | +scanning. You can pass in *n* pubkeys/addresses, or even [HD wallet |
| 162 | +extended public keys] with a lookup window, and it gives you back all |
| 163 | +unspent [outputs] (and even a rawsweeptransaction to a single address)." |
| 164 | + |
| 165 | +Wuille described his concerns, "I just mentioned that we preferably |
| 166 | +don't commit to having functionality that's hard to maintain in the |
| 167 | +future. [For example, in a possible future with the] [UHF model][], |
| 168 | +implementing a scan of the UTXO set without indexes requires going |
| 169 | +through the block chain." *[Note: what's labeled in the discussion as |
| 170 | +"UHF" is elsewhere called "UHS"; see [link][UHF model].]* |
| 171 | + |
| 172 | +Johnathan Corgan suggested, "If we want to encourage people to treat |
| 173 | +bitcoind as the 'ground truth', instead of baking up their own stuff, |
| 174 | +giving them easier access to the 'database' would help." |
| 175 | + |
| 176 | +Wuille conceded that the issue was "less a concern [because it's easier |
| 177 | +to] add optional indexes now with [Jim Posen's] background index work. |
| 178 | +Before, new indexes always required ugly hacks all over the validation |
| 179 | +code." |
| 180 | + |
| 181 | +**Conclusion:** "this is turning into a philosophical discussion," |
| 182 | +remarked Wuille near the end of the discussion. There was no explicit |
| 183 | +conclusion, but it seemed that if a `scantxoutset` RPC or similar RPC is |
| 184 | +added, a warning might be added to the release notes that indicating |
| 185 | +that it might require enabling an optional index in the future. |
| 186 | + |
| 187 | +## Comic relief |
| 188 | + |
| 189 | +{% highlight text %} |
| 190 | +[...Things start to break...] |
| 191 | + <mquin> [Global Notice] [...] There are ongoing issues with |
| 192 | + services that are being looked into - please bear |
| 193 | + with us |
| 194 | + <sipa> fun. |
| 195 | +<instagibbs> err what |
| 196 | + <wumpus> services massacre |
| 197 | + <cfields> irc unicorns... |
| 198 | + let's move to slack! |
| 199 | + (/s) |
| 200 | + <wumpus> :-( |
| 201 | +{% endhighlight %} |
| 202 | + |
| 203 | + |
| 204 | +## Participants |
| 205 | + |
| 206 | +| IRC nick | Name/Nym | |
| 207 | +|-----------------|---------------------------| |
| 208 | +| wumpus | [Wladimir van der Laan][] | |
| 209 | +| jonasschnelli | [Jonas Schnelli][] | |
| 210 | +| sipa | [Pieter Wuille][] | |
| 211 | +| provoostenator | [Sjors Provoost][] | |
| 212 | +| jcorgan | [Johnathan Corgan][] | |
| 213 | +| jimpo | [Jim Posen][] | |
| 214 | +| achow101 | [Andrew Chow][] | |
| 215 | +| MarcoFalke | [Marco Falke][] | |
| 216 | +| instagibbs | [Gregory Sanders][] | |
| 217 | +| cfields | [Cory Fields][] | |
| 218 | +| jamesob | [James O'Beirne][] | |
| 219 | +| jtimon | [Jorge Timón][] | |
| 220 | +| echeveria | Echeveria | |
| 221 | +| jnewbery | [John Newbery][] | |
| 222 | +| promag | [Joao Barbosa][] | |
| 223 | +| kanzure | [Bryan Bishop][] | |
| 224 | +| Murch | [Mark Erhardt][] | |
| 225 | + |
| 226 | +## Disclaimer |
| 227 | + |
| 228 | +This summary was compiled without input from any of the participants in |
| 229 | +the discussion, so any errors are the fault of the summary author and |
| 230 | +not the discussion participants. In particular, quotes taken from the |
| 231 | +discussion had their capitalization, punctuation, and spelling modified |
| 232 | +to produce consistent sentences. Bracketed words and fragments, as well |
| 233 | +as background narratives and exposition, were added by the author of |
| 234 | +this summary and may have accidentally changed the meaning of some |
| 235 | +sentences. If you believe any quote was taken out of context, please |
| 236 | +[open an issue](https://github.com/bitcoin-core/bitcoincore.org/issues/new) |
| 237 | +and we will correct the mistake. |
| 238 | + |
| 239 | +[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8 |
| 240 | +[maintenance release]: /en/lifecycle/#maintenance-releases |
| 241 | +[key-value database]: https://en.wikipedia.org/wiki/Key-value_database |
| 242 | +[UHF model]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015967.html |
| 243 | + |
| 244 | +{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-24-19.00.log.html" %} |
| 245 | +[mb log]: {{log}} |
| 246 | +[log 0.16.1 todo]: {{log}}#l-14 |
| 247 | +[log random relay delays]: {{log}}#l-51 |
| 248 | +[log gui prune]: {{log}}#l-66 |
| 249 | +[log scantxoutset]: {{log}}#l-136 |
| 250 | + |
| 251 | +{% include link-to-issues.md issues="13317,12172,12431,13298,13043,11082,12833,12196" %} |
0 commit comments