Meetings: add 2018-06-28

Author: harding

_includes/references.md

@@ -72,6 +72,7 @@
 [BIP34]: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
 [BIP35]: https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki
 [BIP37]: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
+[BIP39]: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
 [BIP42]: https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki
 [BIP50]: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
 [BIP61]: https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki

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

@@ -0,0 +1,231 @@
+---
+title: IRC meeting summary for 2018-06-28
+lang: en
+permalink: /en/meetings/2018/06/28/
+name: 2016-06-28-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, a draft specification for a new [BIP39][]-like seed
+format, documenting how Bitcoin Core uses the [BIP32][] HD wallet
+standard, an update on progress towards implementing [BIP151][]
+encrypted peer-to-peer connections, and discussion surrounding a new way
+to describe to wallet software what output scripts they should consider
+part of the user's wallet.
+
+## 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]):** the only PR specifically discussed
+was [#12196][], which adds a `scantxoutset` RPC to allow applications to
+search all current Unspent Transaction Outputs (UTXOs) for those that match a
+particular address, public key, private key, or HD wallet extended
+public key (xpub).
+
+Pieter Wuille suggested that the PR's author, Jonas Schnelli, remove
+xpub support from `scantxoutset` for now and Wuille would later PR an
+update to `scantxoutset` that adds support for the output script
+descriptors described later in these meeting notes.  If Wuille is
+delayed in doing so, Schnelli can just add the previously-written xpub
+support back in before the Bitcoin Core 0.17 feature freeze.  Schnelli
+agreed.
+
+*Note: extended discussion of output script descriptors during this part
+of the meeting has been moved to a [separate section](#output-script-descriptors).*
+
+## Cipherseed
+
+**Background:** (Part of the discussion.)
+
+**Discussion ([log][log cipherseed]):** Jonas Schnelli requested and
+introduced the topic, "I have a [specification draft][draft bip
+cipherseed] for a new seed format similar to BIP39 with some neat
+properties and---before sending [it] to the mailing list---would
+appreciate feedback."
+
+**Conclusion:** Schnelli said it was "more an announcement than a topic"
+and so discussion was deferred until people had a chance to read the
+draft.
+
+## Core's BIP32 derivation "standard"
+
+**Background:** the HD wallet specification, [BIP32][], defines how a
+set of private keys and public keys (and, therefore, addresses) can be
+derived from a 128-bit to 512-bit random seed.  
+
+**Discussion ([log][log core hd]):** Jonas Schnelli requested and
+introduced the topic, "It came up today in a discussion [that] Core's
+BIP32 derivation scheme is not specified in a BIP.  Some people think
+it's vanilla/native BIP32, but it's not, while other [wallets] do native
+BIP32."
+
+Wladimir van der Laan agreed "it would be good if the difference would
+be documented somewhere."  Luke Dashjr opposed it being a BIP and Pieter
+Wuille agreed, with Andrew Chow suggesting that "just documenting the
+derivation in the [documentation repository][docs repo] is sufficient."
+
+*Note: extended discussion of output script descriptors during this part
+of the meeting has been moved to a [separate section](#output-script-descriptors).*
+
+## P2Plink ephemeral encryption
+
+**Background:** [BIP151][] specifies a method to allow Bitcoin nodes
+and clients to send their data over encrypted connections to prevent
+eavesdroppers from directly monitoring which particular transactions and
+blocks are being transmitted.  This can enhance certain aspects of
+privacy, such as by making it harder for someone to determine which
+IP address was the first to transmit a particular transaction (maybe
+indicating that someone at that IP address created the transaction).  In
+the BIP151 specification, both parties to the connection generate keys
+for just that connection and that session---destroying the keys after
+the connection is closed; these keys are described as "ephemeral".
+Since ephemeral keys are not reused, it's not possible to use them to
+identify the same node operating on different networks (e.g. Tor) or
+after the node changes IP addresses.
+
+**Discussion ([log][log link encryption]):** Gregory Maxwell requested
+the topic and opened discussion with a question, "Has there been any
+progress towards implementing P2P link ephemeral encryption lately?  I
+know we were kinda waiting for some other networking refactors."
+
+Jonas Schnelli said, "Armory has implemented it and has plans to PR it
+to Core (not sure how soon and in what quality)."
+
+Cory Fields said, "I've had to put the network [refactor] stuff on the
+back burner for now, so certainly don't wait for that.  I'm happy to
+help with the implementation [of BIP151].  I was thinking we were
+waiting on the authentication stuff."
+
+Schnelli, Maxwell, and Pieter Wuille all agreed that BIP151
+implementation shouldn't be waiting on a proposal for authentication.
+
+Further discussion focused on whether or not the setup protocol for the
+encryption (the initial handshake) should be made harder to detect and
+so also harder to block.  However, Maxwell said, "I think we thought the
+benefits [of the approach considered] were too dubious, especially since
+traffic patterns will identify Bitcoin peer-to-peer links very clearly.
+[...] So I think we're good to implement, and the only changes that
+might be proposed would be ones that arose as a side effect of
+implementing and benchmarking."
+
+**Conclusion:** Schnelli said, "If no one else wants to work on the
+implementation, I will continue then with [my] BIP151 implementation."
+
+[draft bip cipherseed]: https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991
+
+## Output script descriptors
+
+*Note: this was not a tagged topic, but it was discussed during two
+other topics in the meeting.  For easier reading, those separate
+discussions have been extracted from where they occurred and unified
+into a single topic here.*
+
+**Background:** Pieter Wuille has been working on a [redesign][gist
+wallet redesign] of how the Bitcoin Core wallet identifies which
+transactions belong to a particular user's wallet.
+
+**Discussion ([log part 1][log out desc scantxoutset], [log part 2][log
+out desc bip32]):** As part of his wallet redesign, Pieter Wuille said
+that he has been working on a related [design][gist output script
+descriptors] for human-readable descriptions of sets of scriptPubKeys
+that provides "a general language that encodes all information about how
+to spend a whole set of keys with associated addresses/scripts/private
+keys/... into one string, including support for multisig etc..."
+
+This supports the proposed wallet redesign by allowing "import/export
+[to] operate at the level of those descriptors, instead of individual
+keys/scripts/pubkeys/HD [wallet key] chains.  [The] importmulti [RPC] is
+already compatible with that design, for a large extent. The entirety of
+that idea is certainly not for [the next major Bitcoin Core version,]
+0.17, but that doesn't mean it can't be used already in relatively small
+scoped things [like] `scantxoutset`."
+
+This lead Wuille to suggest that PR [#12196][] temporarily remove its
+extended public key support so that Wuille can allow the new `scantxoutset`
+RPC to use the output script descriptors instead.
+
+Jonas Schnelli asked, "how would [output script descriptors] interact
+with the keypool, flexible keypaths, and extended public keys?"  The
+keypool is a set of keys belonging to the user's wallet; Bitcoin Core
+looks for transactions affecting those keys and adds them to the user's
+wallet.  Flexible keypaths refers to the [BIP32][] key derivation path
+for an HD wallet.
+
+Wuille said that the "keypool goes away [...] In practice, [the
+descriptor] contains the expanded pubkeys.  [For] flexible keypath, the
+descriptor just contains the path; you can change it to whatever you'd
+like (but default wallets would, of course, pick some standard scheme)."
+
+**Conclusion:** Wuille will continue working on output script
+descriptors, including a plan to open a PR adding them to the
+`scantxoutset` RPC.
+
+[gist wallet redesign]: https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2
+[gist output script descriptors]: https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82
+
+## Participants
+
+| IRC nick        | Name/Nym                  |
+|-----------------|---------------------------|
+| jonasschnelli   | [Jonas Schnelli][]        |
+| sipa            | [Pieter Wuille][]         |
+| wumpus          | [Wladimir van der Laan][] |
+| gmaxwell        | [Gregory Maxwell][]       |
+| cfields         | [Cory Fields][]           |
+| promag          | [Joao Barbosa][]          |
+| luke-jr         | [Luke Dashjr][]           |
+| achow101        | [Andrew Chow][]           |
+| meshcollider    | [Samuel Dobson][]         |
+| instagibbs      | [Gregory Sanders][]       |
+| kanzure         | [Bryan Bishop][]          |
+| jnewbery        | [John Newbery][]          |
+
+## 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/101580174/
+[mb minutes]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-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-28-19.00.log.html" %}
+[mb log]: {{log}}
+[log hipri]: {{log}}#l-15
+[log cipherseed]: {{log}}#l-85
+[log core hd]: {{log}}#l-92
+[log link encryption]: {{log}}#l-149
+[log out desc scantxoutset]: {{log}}#l-33
+[log out desc bip32]: {{log}}#l-124
+
+[docs repo]: https://github.com/bitcoin-core/docs
+
+{% include link-to-issues.md issues="12196" %}