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.
Update Bitcoin Core to at least 0.17.1: two minor vulnerabilities
that affect older releases of Bitcoin Core are
scheduled to be disclosed around August
1st. Neither vulnerability affects version 0.17.1 (released 25
December 2018) or later versions. We express our gratitude to Bitcoin
Core contributor practicalswift for reporting the vulnerabilities.
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.
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
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.
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.
How can I mitigate concerns around the gap limit? Enrique
inquires about potential loss of funds when using an HD wallet and exceeding
the address gap limit. Andrew Chow and Bitcoin Holder explain that, while there
are no loss of funds when exceeding the gap limit, the limit should be
considered when restoring from backup or generating addresses outside of the
Bitcoin Core #13756 adds a setwalletflags RPC that can be used
to toggle flags for the wallet, including a new avoid_reuse flag
that (when enabled) will prevent the wallet from spending bitcoins
received to an address that the wallet has already used for spending.
This prevents block chain analysts from being able to associate
multiple spends with the same wallet through spending address
reuse—an attack on privacy often exploited using dust attacks.
This new flag is disabled by default but, when enabled, it can be combined with the
avoidpartialspends configuration option described in Newsletter
#6 to ensure that all bitcoins received to the same address so far
are spent at the same time, ensuring that there are none left over in
a balance that requires passing a special option to spend.
Bitcoin Core #15651 causes Bitcoin Core to always bind to the
default port when listening on Tor (e.g. port 8333 for mainnet) even
if it is configured to listen on another port for normal clearnet
traffic. The previous behavior where it listened on the custom port
on all interfaces made it easy to find the clearnet identify of any Tor
node that used a custom Bitcoin port.
Bitcoin Core #16171 removes the mempoolreplacement configuration
option. This option configured whether or not the node would accept
replacements of transactions into its mempool according to the
BIP125 opt-in Replace-by-Fee (RBF) rules. This option was added
at the last moment during the 0.12 release cycle
and developers have argued that it’s almost never what miners or
node operators want—miners because it reduces their profitability
and node operators because, even if the operator doesn’t like opt-in
RBF, disabling this option prevents them from receiving warnings about
replacements. Users who don’t like RBF are better off ignoring
transactions that opt-in to RBF until they’ve been confirmed (as described in
BIP125). It’s believed almost all nodes
are currently using the default option and the only miner known to be
using the option recently confirmed that was a misconfiguration on
their part, so the option is being removed for lack of use and because
there’s no reason to recommend anyone use it.
Bitcoin Core #16026 makes the createmultisig and
addmultisigaddress RPCs always return a legacy P2SH multisig address
if any of public keys used are uncompressed pubkeys. Per
BIP143, uncompressed pubkeys must not be used with the current
version of segwit (version 0). Bitcoin Core won’t relay spends from segwit outputs
that use uncompressed pubkeys and it’s possible that a future soft
fork will make them permanently unspendable.