Newsletters: add 58 (2019-08-07) #176
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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 | ||
|
Collaborator
There was a problem hiding this comment. Curious shift here, and a second time in line 72, from third-person to first-person narrative and back. Particularly this first one as the case study begins in the third person. |
||
| 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: | ||
|
|
||
| <pre>OP_DUP OP_HASH160 OP_PUSH20 <b>6eafa604a503a0bb445ad1f6daa80f162b5605d6</b> OP_EQUALVERIFY OP_CHECKSIG</pre> | ||
|
|
||
| - Native segwit (bech32) P2WPKH scriptPubKey for address bc1qd6h6vp99qwstk3z668md42q0zc44vpwkk824zh: | ||
|
|
||
| <pre>OP_0 OP_PUSH20 <b>6eafa604a503a0bb445ad1f6daa80f162b5605d6</b></pre> | ||
|
|
||
| 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/ | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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 | ||
|
Contributor
There was a problem hiding this comment. Are we planning on emphasizing the sections moving forward? Was not sure if this was intentional.
Collaborator
Author
There was a problem hiding this comment. No, this was a special case requested by @moneyball https://github.com/bitcoinops/bitcoinops.github.io/pull/176/files/07e854c6acc8aaf9ccbce9a7b16972d0ed040833#diff-ef4489117fbc2501b497cd6ec1feb572 (which I agree with). The code changes section is only emphasized because it sounded weird to me to only emphasize the bech32 section (and because it really was a week with lots of changes). |
||
| developments. | ||
|
|
||
| {% comment %}<!-- include references.md below the fold but above any Jekyll/Liquid variables-->{% 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 | ||
|
Collaborator
There was a problem hiding this comment. IIUC the link here points to https://bitcoincore.org/bin/bitcoin-core-0.18.1/. Perhaps a link to the release notes, e.g. behind "bug fixes and improvements" or "(release notes here)" etc., would be handy if not already present. |
||
| 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 | ||
|
Collaborator
There was a problem hiding this comment. Perhaps a more general "enabling users to access..." esp. if the audience includes wallet providers.
Collaborator
Author
There was a problem hiding this comment. That would be more general but it'd also be a bit less clear that this section is meant to be focused on getting wallets to do that bare minimum of work to accept bech32 addresses and generate native segwit scriptPubKeys. "Enabling users to access all of segwit's benefits" sounds like we're advocating full segwit support, which (of course) we do, but at a lower priority than trying to get near-universal support for the ability to pay bech32 addresses. (We used to have a longer introduction that spelled all that out, but at least one reader mistook its length for us repeating the whole section each week.) |
||
| 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 | ||
|
Collaborator
There was a problem hiding this comment. Suggestion: s/changes/improves/ to change things up with the changes in the next item
Collaborator
Author
There was a problem hiding this comment. Repeated phrasing in paragraph text (such as the "and so" you identified earlier) can indeed be jarring to read and so should be avoided, but in lists, I think it's beneficial as the parallelism makes reading (and particularly skimming) faster. My usual template for Bitcoin Core RPC changes is to say adds, removes, or changes followed by the RPC name(s) followed by the actual changes. Since most people only use a few RPCs, that puts the information they need to quickly figure out whether this change affects them near the start of the list item, making skimming more effective. (As a general rule, I will quite often use somewhat odd phrasing near the start of a list item so that it's easier to skim because it starts by mentioning the systems affected.) |
||
| [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). | ||
|
Contributor
There was a problem hiding this comment. I suggest reversing the order of these (new |
||
| 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/ | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are still a lot of instances of 'BRD' in this field report. I think it'd sound more natural if some of them were replaced by we/us.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm changing this to consistently use pronouns for things their development team did and to use BRD for the software itself. Hopefully that resolves this concern and @jonatack's concern here: #176 (comment)