IRC meeting summary for 2018-05-24

• View this week’s log on BotBot.me or MeetBot
• Meeting minutes by MeetBot

Topics discussed during this weekly meeting included what issues need to be resolved before generating the first release candidate for version 0.16.1, whether transaction relay should be delayed a bit more in order to potentially increase spender privacy, how to store settings set internally by Bitcoin Core GUI and daemon so that both programs can access them, and whether Bitcoin Core should add a feature for scanning the UTXO set even though it might (hypothetically) not store the UTXO set in a scanable form in the future.

[What needs to be done for] 0.16.1

Background: Bitcoin Core contributors are working towards releasing Bitcoin Core 0.16.1, a maintenance release that will contain bug fixes and minor improvements.

Discussion (log): Wladimir van der Laan proposed the topic and dove right into discussing what needed to be done, which appeared to be getting reviews on Pull Request (PR) #13317. There was some discussion about whether PRs not related to 0.16.1 should be given high priority, which Van der Laan opposed “I think we should focus on 0.16.1 now; we’ll get around to the other high priority stuff again next week.”

Two PRs were proposed for backporting, #12172 and #12431, but both were argued against as either problematic or unnecessary.

Conclusion: reviewers are encouraged to view #13317.

Random delays per network group to obfuscate transaction time

Background: many years ago, when Bitcoin software received a transaction, it shortly thereafter attempted to relay it to its other peers. This allowed transaction analysis organizations to connect to lots of nodes and assume that the first node they received a transaction announcement from was probably the node who created it (or, at least, was one of the first to relay it). In Bitcoin version 0.2.10, a feature was added that caused nodes to wait a different amount of time for different groups of peers before relaying them new transactions; this caused transactions to spread through the network less predictably to increase spender privacy. Subsequent releases have improved upon this basic feature.

PR #13298 describes a possible counter to the above method: transaction analysis organizations connect multiple times to each node, increasing the chance that they will hear about a transaction earlier rather than latter, and therefore increasing the chance that the first node they receive a transaction from is its original sender. That same PR also provides a method to make multiple connections more expensive for the analysis organization by causing the random delays to be based on network groups (large blocks of IP addresses) rather than individual nodes, so that analysis organizations need to get access to specific IP address ranges in order to obtain the same chance of being an early receiver

Discussion (log): Pieter Wuille requested the topic and described what he’d like to see: “I want to bring up #13298 briefly […] It’s a possibly significant effect on P2P transaction relay and it needs review beyond ‘does the code work.’ But it’s also just local policy and not something that warrants a BIP [in my honest opinion]. Maybe there’s not much more to say about that, [I’m] just hoping to get people to think about it a bit.”

The possibly significant effect on P2P transaction relay would lengthening the amount of time it takes a transaction (but not a block) to propagate from its originating peer to 90% or more of the other nodes.

Conclusion: there was no discussion, just a recommendation for reviewers to visit the PR, consider its effects, and provide comments with any recommendations.

GUI prune setting and writable config files

Background: Bitcoin Core provides command line options and a user-editable configuration file (bitcoin.conf) but it also allows users to change some of the same settings in the Graphical User Interface (GUI). Currently these two sets of settings are stored in different places because the GUI can’t change the configuration file (on some systems, it’s read-only, and in all cases it may contain user comments and formatting that an automated configuration editor might break). However, this creates several problems, where a user changes a setting in one place and it either does or doesn’t apply in the other place unexpectedly. The latest case of a shared setting is PR #13043 adding to a GUI the ability to control the pruning previously available from the command line and configuration file.

Discussion (log): Sjors Provoost requested the topic and suggested three solutions to the problem of where to store settings shared between different Bitcoin Core programs:

1. “Ignore the problem.” Continue with the current system.

2. “Go the writable config file route.” (Discussion goes into more detail later.)

3. “Interpret a lack of prune= setting differently.” Give an option specified in a configuration file precedence over an option configured in the GUI.

Provoost added, “if we go for [option] 2, then I’d like to nominate [PR] #11082 for priority review.” That PR adds a new bitcoin_rw.conf file for settings modified by the software. Unlike the Qt settings, the file can be shared between both Bitcoin Core’s daemon and GUI, and the file would be explicitly marked as not intended to support comments, whitespace-based formatting, and other conveniences for human editing.

Jonas Schnelli complained, “do we want four(!) levels of configuration? Conf[iguration file] <-> startup [command line interface parameters] <-> Qt Settings <-> level 4 [bitcoin_rw.conf].”

Provoost explained, “I’d also like to get rid of Qt settings completely […] I wrote a migration away from QTSettings [in PR] #12833.” Schnelli was satisfied by this option and said, “thanks [Provoost] for working on that!”

Gregory Sanders suggested the “user could, by and large, be migrated over to the [bitcoin_rw.conf] unless they have a need for read-only.” Wladimir van der Laan argued against this, “well, the bitcoin.conf is for human editing; the [bitcoin_rw.conf] is machine writable, all comments will be discarded, etc…”

Conclusion: no explicit conclusion; meeting participants seemed to be in favor of moving forward with creating a bitcoin_rw.conf to store settings modified by the software. There was some unresolved discussion about whether currently-open PRs that modify settings should wait for bitcoin_rw.conf to become available before being merged, or should use the existing sub-optimal Qt Settings mechanism.

ScanTxOutSet RPC command

Background: The Bitcoin Core software maintains a key-value database of every Unspent Transaction Output (UTXO)—that is, every spendable group of bitcoins and the conditions that need to be fulfilled in order to spend them. The database is not designed for access by more than one program at once and is not API stable, meaning other programs can’t easily read from it, and so there’s currently no convenient way for other programs to retrieve information from the UTXO set.

Discussion (log): Jonas Schnelli requested the topic and introduced it: “Pieter Wuille raised concerns about the scantxoutset command [proposed in PR #12196]. Before continuing on [PR] #12196, we may want to discuss if it makes sense[…]. The scan functionality allows UTXO sweeping (rawsweeptransaction) with no block scanning. You can pass in n pubkeys/addresses, or even [HD wallet extended public keys] with a lookup window, and it gives you back all unspent [outputs] (and even a rawsweeptransaction to a single address).”

Wuille described his concerns, “I just mentioned that we preferably don’t commit to having functionality that’s hard to maintain in the future. [For example, in a possible future with the] UHF model, implementing a scan of the UTXO set without indexes requires going through the block chain.” [Note: what’s labeled in the discussion as “UHF” is elsewhere called “UHS”; see link.]

Johnathan Corgan suggested, “If we want to encourage people to treat bitcoind as the ‘ground truth’, instead of baking up their own stuff, giving them easier access to the ‘database’ would help.”

Wuille conceded that the issue was “less a concern [because it’s easier to] add optional indexes now with [Jim Posen’s] background index work. Before, new indexes always required ugly hacks all over the validation code.”

Conclusion: “this is turning into a philosophical discussion,” remarked Wuille near the end of the discussion. There was no explicit conclusion, but it seemed that if a scantxoutset RPC or similar RPC is added, a warning might be added to the release notes that indicating that it might require enabling an optional index in the future.

Comic relief

[...Things start to break...]
     <mquin> [Global Notice] [...] There are ongoing issues with
             services that are being looked into - please bear
             with us
      <sipa> fun.
<instagibbs> err what
    <wumpus> services massacre
   <cfields> irc unicorns...
             let's move to slack!
             (/s)
    <wumpus> :-(

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. 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.