IRC meeting summary for 2018-06-21

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

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 to disclose known DoS vulnerabilities for versions of Bitcoin Core 0.12.0 and earlier related to the signed alerts system along with the mechanism to initiate the DoS attacks (Nakamoto’s alert signing key), changes to hosting for the bitcoin-dev mailing list, how inputs are chosen to be included in new transactions by default, dealing with the loading of new wallets in multiwallet mode, improved private key backup and recovery, and continuing work towards creating a machine-writeable configuration file.

Review blockers [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): Pieter Wuille listed the three PRs currently on the list (#13062, #12196, and #13425) and asked if anyone wanted to nominate additional PRs. João Barbosa suggested #13100, which adds a menu entry to open a wallet, but it’s not quite ready yet, so Wuille will wait until it is before adding it.

Alert key [public disclosure]

Background: In 2010, someone created a protocol-valid block that created over 184 billion bitcoins. Satoshi Nakamoto encouraged users to stop mining and soon published an updated version of Bitcoin that corrected the behavior in a retroactive soft fork, but he subsequently added a mechanism to the Bitcoin software that allowed him to sign “alert” messages that could directly notify node operators of problems and even, by default, shut down some node functions that might cause monetary loss. In Nakamoto’s last post to the BitcoinTalk.org forum, he wrote,

“safe mode” alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with “-disablesafemode”, but it’s better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.

Over time, subsequent Bitcoin Core developers steadily deprecated, disabled, and removed the alert feature, turning it off by default in version 0.12.1, removing it entirely in version 0.13.0, hard coding a final alert into version 0.14.0, and (in November 2016) announcing the pending public disclosure of the alert-signing key created by Nakamoto. The disclosure was delayed indefinitely upon discovery of Denial-of-Service (DoS) vulnerabilities related to the alert mechanism in versions of Bitcoin Core below 0.12.1, as discussed in the 9 March 2017 weekly meeting, that affected approximately 2,600 nodes at the time.

Discussion (log): Bryan Bishop requested and introduced the topic, “I’m thinking of releasing the private [alert signing] key. [It] would be nice to get that out there and remove that liability. I’m particularly interested in hearing from others who have good reason not to reveal the key. In the year-plus since [planned public disclosure] was announced, I don’t think much has been raised.”

Gregory Maxwell said, “All supported versions [of Bitcoin Core] have [the signed alert system] gone completely, so that sounds pretty good for a release now—unless pre-0.12 nodes are still popular, and I don’t believe they are.”

Luke Dashjr cited his node scanning system to say that 3% of nodes were running version 0.12 and “0.61% ‘other’ versions, which includes everything before 0.12.” Pieter Wuille found similar statistics using the Bitnodes scanning system, which uses a different scanning method.

Regarding the vulnerabilities related to the signed alert messages in old versions of Bitcoin Core, Maxwell said, “I doubt we know all the vulnerabilities. I know of at least two, but I stopped looking.” Andrew Chow said he knew of three.

The DoS vulnerabilities affect not just Bitcoin but also altcoins that have copied Bitcoin Core’s code and are currently using old versions. When the vulnerabilities are disclosed, anyone with the alert-signing key for an altcoin will be able to execute those DoS attacks. In discussing this, Chow said, “[but] if the altcoins have better control of their alert key, publishing the Bitcoin one and the related vulnerabilities shouldn’t be a problem.”

Conclusion: no explicit conclusion. Bishop seems likely to continue to work towards responsibly disclosing the alert key and (probably) vulnerabilities related to it. No one objected to this, although Matt Corallo did say he thought there was “limited utility to releasing the alert key.”

Bitcoin-dev mailing list

Background: the bitcoin-dev (Bitcoin development) mailing list has been hosted at lists.linuxfoundation.org for the past several years.

Discussion (log): Bryan Bishop requested and introduced the topic: “Linux Foundation is migrating away from the email protocol and will no longer be hosting the bitcoin-dev mailing list. There is a migration plan, but it’s under investigation still.”

There was some brief discussion about current delivery problems with the list, an expression of hope that existing URLs to old posts remain valid, and other migration concerns.

Conclusion: Bishop will send an email to the mailing list, hopefully before migration to a new host domain, with additional details once he has them.

Coin selection

Background: several developers have been working on improving Bitcoin Core’s coin selection—how it chooses which bitcoins (inputs) to spend—to simultaneously improve privacy, reduce transaction size, and reduce fees. The current selection protocol starts with a Branch-and-Bound (BnB) algorithm that tries to find a match between the inputs available and the amount being sent. If that doesn’t work, a fallback algorithm is needed. A Single-Random-Draw (SRD) algorithm randomly adds additional inputs to a partial transaction until the sum of the inputs is equal to or greater than the amount being spent (including fees).

This week’s discussion is a continuation of last week’s discussion about the same topic.

Discussion (log): Andrew Chow requested and introduced the topic, “I did a bunch of simulations of the [single random draw] fallback stuff (link). There are two problems that I see with this strategy: change can be incredibly small and the mean number of UTXOs in the wallet is quite high. The question is whether we can accept these tradeoffs or whether we need to find a better algorithm.”

Gregory Maxwell said, “[If I recall correctly], there is nothing fundamental about [single random draw] that makes it good for making [branch and bound] work better, but rater it was the first alternative [Mark Erhardt] tried there.”

Chow added, “well, and in [Erhardt]’s simulations, [single random draw] performed reasonably well and was extremely simple. Though I guess we may be seeing different results now.”

Various additional strategies and their tradeoffs were discussed, but the topic was starting to become complicated for a short segment of a time-limited text-only meeting.

Conclusion: Chow suggested, “perhaps this coin selection discussion would be better done in person with whiteboards,” ending the meeting discussion, although Maxwell noted, “that leaves out people who can’t attend.” Presumably discussion will continue on PR #13307 and perhaps elsewhere.

Multiwallet session persistence

Background: the development branch (“master” branch) of Bitcoin Core includes code that allows users to dynamically load and unload individual wallets in multiwallet mode. For example, you can have a “personal” wallet and a “business” wallet that can each be opened or closed separately.

Discussion (log): Jonas Schnelli requested and introduced the topic, “I guess it’s not ideal that loaded wallets need to be re-loaded after a Bitcoin Core restart—especially in pruning mode.” That is, a user who creates or loads a wallet and then restarts Bitcoin Core without changing the configuration file will have to rescan the latest parts of the block chain the next time they do load that wallet. Worse, if some of the blocks the rescan needs have been pruned, the user will be unable to use the wallet.

Several meeting participants suggested that this is what the writable Bitcoin config file (rwconf) is being developed for. See PR #11082 and weekly meeting notes for 24 May 2018 and 7 June 2018 for background.

Conclusion: “Okay, guess rw/config solves this, so /topic,” said Schnelli.

Bech32x

Background: several Bitcoin Core contributors have been working to create a new serialization format for backing up and recovering Bitcoin private keys, HD-wallet seeds, HD-wallet extended private keys, and HD-wallet extended public keys. The primary goal is to replace the current popular standards of base58check and BIP39 with a new standard that not only detects errors but can also automatically correct several of those errors for the user. Current ideas for this proposed format reuse some of the work that was performed to create the bech32 native segwit address format, so work is proceeding under the name “bech32x” (but this may later change).

Discussion (log): Jonas Schnelli requested and introduced the topic, “Bech32x currently has the distance 27 BCH with correction to 7 characters, thanks to [Pieter Wuille]. The idea is now to have three ‘levels’ of correction. […] Seven characters is not much more than 5% correction for 512-bit key material [so more is wanted for that case, at least].”

Wuille offered to provide three codes that user could choose from. Gregory Maxwell said, “I think it is not good to make it generally user selectable. The user generally has no way to make a useful decision—but making the format support multiple codes seems okay to me, though it might lower the odds that fancy decoders get written because it’ll be more work.”

Wuille said, “we can make sure they use the same field and extension so that the majority of the recovery code can be shared.” Wuille and Maxwell continued talking about details of choosing optimal BCH codes for this purpose.

Conclusion: the time for the meeting to end occurred during the discussion and Maxwell said, “will continue later.”

RWConf [writeable Bitcoin configuration file]

This topic was requested during the meeting but not enough time was available. Still, some participants stayed late to discuss it immediately after the meeting.

Background: as discussed in the 24 May 2018 meeting, several contributors are working towards creating a machine-writeable configuration file that will be shared between Bitcoin Core’s daemon and GUI so that when users change a setting in one program, it’ll be set the same way in the other program. A particular problem with creating the new configuration file was raised in the 7 June 2018 meeting but the person most familiar with the subject was not present; he was present for this after-meeting discussion.

Discussion (log rwconf): Luke Dashjr had requested the topic and introduced it post meeting by asking whether AJ Towns had any objection to Dashjr reverting one of Towns’s commits that changed how command-line and configuration file parameters were handled when Bitcoin Core is started. This would resolve an issue Dashjr was having creating the writeable configuration file.

Pieter Wuille suggested an additional mechanism and Towns pointed out a potential problem with Dashjr’s proposal related to network configuration. However, Towns said, “anyway, I don’t object to changing around the map stuff, [it] was just the simplest way I could see of getting relatively sane behavior.”

Conclusion: no explicit conclusion. Presumably Dashjr will continue working on creating a machine-writable configuration file.

Comic relief

<gmaxwell>  I doubt we know all the vulnerabilities.
            I know of at least two but I stopped looking.
<achow101>  gmaxwell: I believe I know of three
<gmaxwell>  Also depends on how you count. :)
<achow101>  that too
    <sipa>  i tend to count using the ring of integers

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.