From 82a7452dbe54d8eadc97ffd491e513b1f91a2f76 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Sun, 4 Aug 2019 13:42:51 -1000 Subject: [PATCH] Newsletters: add 58 (2019-08-07) --- _includes/specials/bech32/21-brd.md | 83 ++++++++++ .../en/2019-03-19-bech32-sending-support.md | 6 + .../en/newsletters/2019-08-07-newsletter.md | 149 ++++++++++++++++++ 3 files changed, 238 insertions(+) create mode 100644 _includes/specials/bech32/21-brd.md create mode 100644 _posts/en/newsletters/2019-08-07-newsletter.md diff --git a/_includes/specials/bech32/21-brd.md b/_includes/specials/bech32/21-brd.md new file mode 100644 index 0000000000..2e5c165031 --- /dev/null +++ b/_includes/specials/bech32/21-brd.md @@ -0,0 +1,83 @@ +*The following case study contributed by Optech member company [BRD][] +describes what they learned implementing bech32 and other segwit +technology for their wallet.* + +We began implementing bech32 support in BRD wallet in January 2018 with the +[addition of bech32 decoding and encoding support][brd pr1] to +[breadwallet-core][], an MIT-licensed cross-platform C library +with no external dependencies. All of our software avoids +third-party library dependencies as much as possible, with it currently +using only Pieter Wuille's [libsecp256k1][]. Minimizing dependencies is +typical for a high-security crypto project. For the bech32 +implementation, we found that bech32's [BIP173][] is pretty well +documented, so there were no specific issues that were complex to +deal with. + +In March 2018, breadwallet-core was [updated][brd pr2] to automatically parse +anything provided as a Bitcoin address to determine whether it was a +legacy P2PKH, legacy P2SH, or segwit bech32 and to automatically +generate the appropriate scriptPubKey in each case. This allowed BRD to +begin sending to bech32 addresses. Finally in October 2018, we +implemented full segwit support across the library backend and mobile +app frontends, allowing users to begin receiving to bech32 addresses and +making the default that all change addresses were now bech32. + +One thing we never implemented was support for receiving to +P2SH-wrapped segwit addresses, instead going straight to bech32. This +was a deliberate design optimization to make the best use of the bloom +filter mechanism BRD uses to scan for transactions affecting user +wallets. To allow users to track when they've been paid, bloom filters +are matched against each data element in a scriptPubKey. For a given +public key, the data element in the scriptPubKey is identical for both +legacy P2PKH and native segwit (bech32) P2WPKH. Here's an example +[previously used][identical spk data] by Optech: + +- Legacy P2WPKH scriptPubKey for address 1B6FkNg199ZbPJWG5zjEiDekrCc2P7MVyC: + + 
OP_DUP OP_HASH160 OP_PUSH20 6eafa604a503a0bb445ad1f6daa80f162b5605d6 OP_EQUALVERIFY OP_CHECKSIG
+ +- Native segwit (bech32) P2WPKH scriptPubKey for address bc1qd6h6vp99qwstk3z668md42q0zc44vpwkk824zh: + + 
OP_0 OP_PUSH20 6eafa604a503a0bb445ad1f6daa80f162b5605d6
+ +Because a bloom filter for a given element will match both P2PKH and +P2WPKH addresses for the same public key, BRD is able to scan for either +type of payment with zero additional overhead. It also makes the +implementation much cleaner and doesn't increase the resource use of +public nodes that serve bloom filters. This may be a worthwhile +optimization for wallets and services using other types of scanning as +well, as it may produce less overhead than the separate HD derivation +path recommended by [BIP84][]. + +ScriptPubKeys generated from bech32 addresses vary in length, affecting +the amount of transaction fee that needs to be paid. +Fee calculation on Bitcoin is hideous---feerates spike multiple +orders of magnitude in a 24 hour period sometimes---but that was already +true before segwit so we previously spent a lot of time on fee +calculation and made it as flexible as possible. That means +the variability in size of scriptPubKeys +generated from bech32 addresses doesn't change anything for BRD. + +We want today's app to be future-proof so the code supports +sending to future segwit versions (see [Optech's description][bech32 +future]). That means, for example, BRD will support paying to +[taproot][bip-taproot] addresses automatically if Bitcoin users choose +to make that soft fork change to the consensus rules. + +Once real momentum is established and most other wallets and services +support sending to bech32 addresses, BRD's bech32 receiving support will +be rolled out to our entire user base as the default setting. In +preparation of this transition, it is important to get as many companies +and services as possible to voluntarily start supporting bech32 sending +capability. To help encourage adoption, we created the [WhenSegwit][] +website and became a member company of Optech. We hope that other wallets +and services will make their own transitions to full segwit support soon while +fees are still relatively low. + +[BRD]: https://brd.com/ +[brd pr1]: https://github.com/breadwallet/breadwallet-core/commit/2b17fe44619442c31f8a47c175f84b8992933346 +[brd pr2]: https://github.com/breadwallet/breadwallet-core/commit/fd0abb92b07e41429e1170fb56716965cc7b64ab +[breadwallet-core]: https://github.com/breadwallet/breadwallet-core/ +[identical spk data]: https://bitcoinops.org/en/bech32-sending-support/#sending-to-a-legacy-address +[bech32 future]: https://bitcoinops.org/en/bech32-sending-support/#automatic-bech32-support-for-future-soft-forks +[whensegwit]: https://whensegwit.com/ diff --git a/_posts/en/2019-03-19-bech32-sending-support.md b/_posts/en/2019-03-19-bech32-sending-support.md index ac7f14050c..b171099d7d 100644 --- a/_posts/en/2019-03-19-bech32-sending-support.md +++ b/_posts/en/2019-03-19-bech32-sending-support.md @@ -147,5 +147,11 @@ on bech32 sending support, from March 19th to August 28th, 2019. {% include specials/bech32/20-percentage-loss.md %} +## BRD field report + +*Originally published in [Newsletter #58][].* + +{% include specials/bech32/21-brd.md %} + ## Footnotes {:.no_toc} diff --git a/_posts/en/newsletters/2019-08-07-newsletter.md b/_posts/en/newsletters/2019-08-07-newsletter.md new file mode 100644 index 0000000000..4ba3ffd069 --- /dev/null +++ b/_posts/en/newsletters/2019-08-07-newsletter.md @@ -0,0 +1,149 @@ +--- +title: 'Bitcoin Optech Newsletter #58' +permalink: /en/newsletters/2019/08/07/ +name: 2019-08-07-newsletter +slug: 2019-08-07-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter announces the maintenance release of Bitcoin Core +0.18.1, summarizes a discussion about BIP174 extensions, and notes a +proposal for LN trampoline payments. Our *bech32 sending support* +section this week features a special case study contributed by BRD and +our *notable changes* section highlights several possibly significant +developments. + +{% comment %}{% endcomment %} +{% include references.md %} + +## Action items + +- **Upgrade to Bitcoin Core 0.18.1:** this maintenance [release][0.18.1 notes] makes + available several bug fixes and other improvements. [Upgrading][bitcoin + core 0.18.1] is recommended. + +## News + +- **BIP174 extensibility:** the author of the Partially-Signed Bitcoin + Transactions (PSBTs) specification, Andrew Chow, [proposed][psbt + extensions] a few minor changes for general adoption: + + - *Reserved types for proprietary use:* some applications are + already including data in PSBTs using types that aren't specified + in [BIP174][]. It's proposed that one type byte or a range of + type bytes be reserved for private PSBT extensions, similar to + reserved IP address ranges for private networks. The exact + construction of this mechanism was a particular focus of + discussion this week. + + - *Global version number:* although the goal is to design enhancements + to PSBTs so that they're backwards compatible, Chow proposed to + add a version byte to PSBTs indicating the most advanced feature + they use so that older parsers can detect when they're being given + a PSBT they might not understand. PSBTs without an explicit + version number would be considered to use version 0. + + - *Multi-byte types:* To allow more types, multi-byte types are + proposed. Mailing list discussion seems to favor using the same + CompactSize unsigned integers used in the Bitcoin protocol. + +- **Trampoline payments:** Bastien Teinturier opened a [PR][trampoline + pr] in the BOLTs repository and started a [discussion][trampoline + discussion] on the Lightning-Dev mailing list about adding support to + the protocol for the trampoline payments described in [Newsletter + #40][news40 trampoline payments] where the spender sends the payment + to an intermediate node who calculates the path either to another + intermediate node (for privacy) or to the receiving node. This can be + very beneficial to low-bandwidth LN clients (such as on mobile + devices) that don't want to keep up with gossip traffic and so only + know how to route to a small number of nodes. Sending a trampoline + payment will require coordination between multiple nodes, so it + should be documented in the Lightning specification. + +## Bech32 sending support + +*Week 21 of 24 in a [series][bech32 series] about allowing the people +you pay to access all of segwit's benefits.* + +{% include specials/bech32/21-brd.md %} + +## Notable code and documentation changes + +*Notable changes this week in [Bitcoin Core][bitcoin core repo], +[LND][lnd repo], [C-Lightning][c-lightning repo], [Eclair][eclair repo], +[libsecp256k1][libsecp256k1 repo], [Bitcoin Improvement Proposals +(BIPs)][bips repo], and [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #15911][] changes the `walletcreatefundedpsbt` to signal + [BIP125][] Replace-by-Fee (RBF) if the wallet is configured to use RBF + (the configuration option `walletrbf`). + +- [Bitcoin Core #16394][] changes the `createwallet` RPC so that if an + empty string is passed for the passphrase parameter, an unencrypted + wallet will be created (and a warning printed). + +- [LND #3184][] adds a watchtower client sub-server to LND that replaces + the private watchtower implementation added for the most recent + release. + +- [LND #3164][] creates a new database into which information about the + past 1,000 payments is stored. (The default of 1,000 can be changed.) + This is meant for use with LND's Mission Control feature that + tries to better use information from past payment attempts (especially + failures) to choose better routes for subsequent payment attempts. + During the first upgrade to a version including this change, details about previous payments will be populated into + this database from LND's lower-level HTLC-tracking database. + +- [LND #3359][] adds an `ignore-historical-filters` configuration option + that will cause LND to ignore a `gossip_timestamp_filter` sent from + a peer. That filter allowed peers to request all announcements that would've + been gossiped during an earlier date range. By ignoring requests for + the filter, LND uses less memory and bandwidth. + The ignore option currently defaults to False, so there's no + change in default LND behavior, but a commit comment notes "down the + road, the plan is to make this default to True." + +- [C-Lightning #2771][] allows plugins to indicate whether or not they + can be started and stopped during runtime rather than just being + started on init and stopped on shutdown. This information is used by + a new `plugin` command that allows users to perform these runtime + stops and starts. + +- [C-Lightning #2892][] now always runs plugins from the Lightning + configuration directory, reducing inconsistencies between different + installs and making it easy for plugins to store and access data + within that directory. + +- [C-Lightning #2799][] provides a new `forward_event` + notification for plugins that alerts when an HTLC has been offered, + settled, failed by both parties, or failed locally (unilaterally). + Additionally, the PR extends the `listforwards` RPC with a + `payment_hash` field to allow the user to find additional information + about the HTLC. + +- [C-Lightning #2885][] spaces out reconnections to channel peers on + startup in order to reduce the chance that a traffic flood causes + C-Lightning to take more than 30 seconds to re-establish a channel + after connecting to a peer. This was the problem that was causing LND + to send sync error messages as described in [last week's + newsletter][news57 sync error]. + +- [BOLTs #619][] adds support for variable-sized payloads in + LN onion routing. Combined with Type-Length-Value (TLV) encoded + fields, which was merged into the specification three weeks ago (see + [Newsletter #55][tlv merge]), this makes it much easier to place + extra data into the encrypted packets that relay payments, enabling + the addition of several features (including the trampoline payments + discussed earlier in this week's newsletter). + +{% include linkers/issues.md issues="15911,16394,3184,3164,3359,2892,2799,2885,2771,619" %} +[bech32 series]: /en/bech32-sending-support/ +[bitcoin core 0.18.1]: https://bitcoincore.org/bin/bitcoin-core-0.18.1/ +[news40 trampoline payments]: {{news40}}#trampoline-payments-for-ln +[news57 sync error]: {{news57}}#c-lightning-2842 +[psbt extensions]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017188.html +[trampoline pr]: https://github.com/lightningnetwork/lightning-rfc/pull/654 +[trampoline discussion]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-August/002100.html +[tlv merge]: {{news55}}#bolts-607 +[0.18.1 notes]: https://bitcoincore.org/en/releases/0.18.1/