Merge #567: Meetings: add 2018-06-14

ce0fc2d 2018-06-21 meeting: add some additional content (David A. Harding)
fc90f77 Meetings: add 2018-06-14 (David A. Harding)

Pull request description:

  Preview: http://dg0.dtrt.org/en/meetings/2018/06/21/

Tree-SHA512: 828620ab731b3e6ef0414c5258967e9edf26d052df80d57f2bd6b12a8a1874110aea61cb9e86b68b351363d33971c1badb82db15dc6b83af80a192f70a244276

Author: harding

_posts/en/meetings/2018-06-14-meeting.md

@@ -67,7 +67,7 @@ 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
+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).

_posts/en/meetings/2018-06-21-meeting.md

@@ -0,0 +1,341 @@
+---
+title: IRC meeting summary for 2018-06-21
+lang: en
+permalink: /en/meetings/2018/06/21/
+name: 2016-06-21-meeting
+layout: page
+type: meetings
+version: 1
+---
+{% include _toc.html %}
+{% include _references.md %}
+
+- View this week's log on [BotBot.me][bbm log] or [MeetBot][mb log]
+- [Meeting minutes by MeetBot][mb minutes]
+
+---
+
+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][log hipri]):** 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][value overflow incident].  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][nakamoto 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][alerts off] in version 0.12.1, [removing it entirely][alerts
+removed] in version 0.13.0, hard coding a [final alert][final alert]
+into version 0.14.0, and (in November 2016) announcing the [pending
+public disclosure][alert key 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][log alert]):** 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][dashjr addr scanner] 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][log dev ml]):** 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][srd
+2018-06-14] about the same topic.
+
+**Discussion ([log][log coin selection]):** Andrew Chow requested and
+introduced the topic, "I did a bunch of simulations of the
+[single random draw] fallback stuff
+([link](https://gist.github.com/achow101/242470486265d3f21adab08f65b9102c)).
+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][log multiwallet persistence]):** 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][rwconf meeting
+2018-05-24] and [7 June 2018][rwconf meeting 2018-06-07] for background.
+
+[rwconf meeting 2018-05-24]: /en/meetings/2018/05/24/#gui-prune-setting-and-writable-config-files
+[rwconf meeting 2018-06-07]: /en/meetings/2018/06/07/#command-line-argument-mapping
+
+**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][bip173] native segwit address format, so work is
+proceeding under the name "bech32x" (but this may later change).
+
+**Discussion ([log][log bech32x]):** Jonas Schnelli requested and introduced
+the topic, "Bech32x currently has the distance 27 [BCH][wikipedia 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][rwconf meeting
+2018-05-24], 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][rwconf meeting 2018-06-07] 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
+
+{% highlight text %}
+<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
+{% endhighlight %}
+
+## Participants
+
+| IRC nick        | Name/Nym                  |
+|-----------------|---------------------------|
+| sipa            | [Pieter Wuille][]         |
+| gmaxwell        | [Gregory Maxwell][]       |
+| kanzure         | [Bryan Bishop][]          |
+| achow101        | [Andrew Chow][]           |
+| luke-jr         | [Luke Dashjr][]           |
+| jonasschnelli   | [Jonas Schnelli][]        |
+| Murch           | [Mark Erhardt][]          |
+| BlueMatt        | [Matt Corallo][]          |
+| meshcollider    | [Samuel Dobson][]         |
+| promag          | [Joao Barbosa][]          |
+| aj              | [Anthony Towns][]         |
+| jnewbery        | [John Newbery][]          |
+| instagibbs      | [Gregory Sanders][]       |
+| jtimon          | [Jorge Timón][]           |
+
+## 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](https://github.com/bitcoin-core/bitcoincore.org/issues/new)
+and we will correct the mistake.
+
+[bbm log]: https://botbot.me/freenode/bitcoin-core-dev/msg/101362379/
+[mb minutes]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-21-19.00.html
+[current high-priority PRs]: https://github.com/bitcoin/bitcoin/projects/8
+
+
+{% assign log = "http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-21-19.00.log.html" %}
+[mb log]: {{log}}
+[log hipri]: {{log}}#l-14
+[log alert]: {{log}}#l-30
+[log dev ml]: {{log}}#l-120
+[log coin selection]: {{log}}#l-155
+[log multiwallet persistence]: {{log}}#l-219
+[log bech32x]: {{log}}#l-239
+[log rwconf]: https://botbot.me/freenode/bitcoin-core-dev/msg/101364609/
+
+[dashjr addr scanner]: http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
+[value overflow incident]: https://en.bitcoin.it/wiki/Value_overflow_incident
+[nakamoto last post]: https://bitcointalk.org/index.php?topic=2228.msg29479#msg29479
+[alerts off]: /en/releases/0.12.1/#miscellaneous
+[alerts removed]: /en/releases/0.13.0/#low-level-p2p-changes
+[final alert]: /en/releases/0.14.0/#final-alert
+[alert key disclosure]: https://bitcoin.org/en/alert/2016-11-01-alert-retirement
+[9 march 2017 weekly meeting]: /en/meetings/2017/03/09/#alert-key-disclosure-timeline
+[bitnodes scanning system]: https://bitnodes.earn.com/
+[srd 2018-06-14]: /en/meetings/2018/06/14/#srd-single-random-draw-fallback-coin-selection
+[wikipedia bch]: https://en.wikipedia.org/wiki/BCH_code
+
+{% include link-to-issues.md issues="13062,12196,13425,13100,13307,11082" %}