This week’s newsletter announces a pending disclosure of minor vulnerabilities for older Bitcoin Core releases, suggests continued testing of RCs for LN software, and describes a proposed technique to make Bitcoin Core nodes a bit more resistant to eclipse attacks. Also included are our regular sections on bech32 sending support, popular StackExchange topics, and notable changes to popular Bitcoin infrastructure projects.

Action items

● Help test C-Lightning and LND RCs: both C-Lightning and LND are in the process of testing Release Candidates (RC) for their next versions. Experienced users of either program are encouraged to help test the RCs so that any remaining bugs can be identified and fixed before their final releases.

News

● Differentiating peers based on ASN instead of address prefix: an eclipse attack prevents a full node from making even one connection to another honest node, allowing the attacker to prevent the node from learning about the most-proof-of-work block chain or from broadcasting time-sensitive transactions. To help prevent eclipse attacks, a Bitcoin Core full node will ordinarily split its eight outgoing connections between nodes whose IP addresses differ in their first 16 bits (i.e. /16). Many ISPs only have IP addresses in a small number of different /16 ranges or allocate their addresses to customers in a way that makes it difficult for customers to choose which prefix they get, making it harder for an attacker to acquire a large diversity of IP addresses from which to they can perform an eclipse attack. However, there are large ISPs such as cloud computing operations that manage multiple facilities that each use different IP ranges, making it possible for customers to more easily acquire addresses from multiple prefixes. One possible solution to that problem would be to track which IP addresses are controlled by which ISPs and then partition the node’s outgoing connections among different ISPs regardless of what addresses they use. For example, this might be able to group together all IP addresses from Amazon AWS no matter what region the customer used for their servers. ISP-to-IP-address information is available from a whole-Internet routing table. Unfortunately, those tables are over a gigabyte in size—too large to practically include with full nodes. Pieter Wuille has been working on a compact encoding of just the information needed to identify different ISPs by their IP addresses (using the ISP’s Autonomous System Number, ASN). Wuille’s table reduces the extra storage requirements to about 1 MB. During this week’s IRC meeting of Bitcoin Core developers, Wuille and Matt Corallo asked whether 1 MB of extra data was small enough to distribute with Bitcoin Core in order to improve its ability to ensure connections to peers on different networks. Meeting participants expressed support for the idea before spending time debating some implementation details. Based on that feedback, we expect to see more development of this idea.

Bech32 sending support

Week 15 of 24 in a series about allowing the people you pay to access all of segwit’s benefits.

Before segwit was activated, developers discussed what format to use for native segwit addresses, with some developers suggesting that a new format was an opportunity to make addresses that were easier to read and transcribe. Developer Gregory Maxwell made this point rather effectively by asking other developers to call him up and try to successfully communicate a mixed-case legacy base58check address to him over the phone. If there was a communication error in just a single character—even just whether that character was uppercase or lowercase—both parties would need to go back and painstakingly try to locate the error.

BIP173 bech32 addresses were able to resolve both of these concerns. They use only a single case (lowercase preferred most of the time but uppercase can be used with QR codes for improved efficiency), and they use an error-correction code for a checksum so they can help users locate errors while ensuring typos will be caught an overwhelming percentage of the time.

However, as wallets and services consider upgrading to support both bech32 sending and receiving, we think it’s worth reminding any reluctant implementers about this key user-benefiting feature of bech32 addresses—so we’ve automated part of Maxwell’s old phone test to allow you to privately evaluate the relative difficulty of transcribing legacy and native segwit addresses.

If you click the following link (open it into a new tab), you’ll find a recording of two addresses paying the same hash value. You can type the addresses into the appropriate box below, which will turn red immediately if you enter any wrong character (case sensitive). Note: to help improve accuracy and eliminate problems with locale-specific letter pronunciations, we read each letter in the file using a phonetic alphabet, e.g. Alfa stands for A; bravo stands for B, etc.

NB: JavaScript recommended—if you want the input boxes to automatically change color to red when you enter a typo, you need to enable JavaScript. However, if you have JS disabled—good for you!—we suggest you enter your input as normal and then use your mouse to highlight this entire paragraph. Just after the end of this sentence in normally-invisible white text are the two addresses; when you highlight the paragraph (changing its background color), they should become visible so that you can compare them to your input manually: 1B6FkNg199ZbPJWG5zjEiDekrCc2P7MVyC and bc1qd6h6vp99qwstk3z668md42q0zc44vpwkk824zh.

Reading of base58check and bech32 addresses (1 minute, 33 seconds)

Legacy base58check address:

Native segwit bech32 address:

If you found the bech32 address much easier to transcribe accurately, then that means the designers of bech32 were successful at meeting one of their goals for the new address format. Users who discover this benefit of bech32 are more likely to want to use bech32 addresses in situations where they need to read or transcribe addresses, and so they’ll be more likely to use your software or service if it supports sending to bech32 addresses.

Selected Q&A from Bitcoin StackExchange

Bitcoin StackExchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments of time to help curious or confused users. In this monthly feature, we highlight some of the top voted questions and answers made since our last update.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, LND, C-Lightning, Eclair, libsecp256k1, and Bitcoin Improvement Proposals (BIPs).