This week’s newsletter notes a proposed BIP that would allow nodes to
implement the Erlay transaction relay protocol, announces full
disclosure of vulnerabilities that affected earlier versions of LN
implementations, links to a transcript from a recent Optech schnorr
and taproot workshop, and includes a field report about some of the
technology Bitcoin exchange BTSE uses to conserve block chain
space while ensuring the safety of user deposits. We also
describe several notable changes to popular Bitcoin infrastructure
None this week.
Draft BIP for enabling Erlay compatibility: a draft BIP for
transaction relay through set reconciliation has been
posted to the Bitcoin-Dev mailing list by Erlay
co-author Gleb Naumenko. Currently, Bitcoin nodes send each of their
peers the txids for all newly-seen transactions, resulting in each
node receiving many duplicate txid announcements. This can be quite
bandwidth inefficient for Bitcoin’s tens of thousands of nodes and
several hundred thousand transactions a day. Alternatively, as described
previously, minisketch-based set reconciliation allows
nodes to send a sketch of a set of short txids that can be combined
with the short txids the receiving peer already knows about to allow the
receiver to recover the short txids it hasn’t seen yet. The size of the
sketch is roughly equal to the expected size of the short txids that need to
be recovered, reducing txid-announcement bandwidth. Erlay is a
proposal that suggests how to use this mechanism to achieve the best
mix of bandwidth efficiency and network robustness. This draft BIP
describes the proposed implementation of the minisketch-based set
reconciliation between nodes, laying the foundation for the
implementation of Erlay. We encourage anyone with feedback to contact
the BIP authors either privately or on the mailing list.
Full disclosure of fixed vulnerabilities affecting multiple LN implementations:
several weeks ago, the developers of C-Lightning,
Eclair, and LND announced the previous discovery of an undisclosed
issue in each of their implementations, which they had each fixed in a
recent release. At that time, they strongly encouraged their users to
upgrade (a message which Optech relayed) and
promised a full disclosure in the future, which they have now done
with an email by vulnerability discoverer and
C-Lightning developer Rusty Russell and a blog post
by LND developers Olaoluwa Osuntokun and Conner Fromknecht.
Briefly, the issue appears to have been that the implementations did not
confirm that channel open transactions paid the correct script,
amount, or both. Because of this, the implementations would accept
payments within the channel which they would later be unable to get
confirmed onchain, allowing them to be defrauded. As of this writing,
Optech is not aware of any reports that this issue was exploited
prior to the warning last month. Now that the issue has
been disclosed, a PR has been opened to update the
specification to note that this check is needed.
Optech taproot and schnorr workshop: last week, Optech held workshops in
both San Francisco and New York City teaching developers about the
schnorr signature scheme and other parts of the proposed
taproot soft fork. We thank Bryan Bishop for typing an
excellent transcript of the NYC workshop. We
are preparing videos and other educational material for release via a
blog post in the near future.
Field report: exchange operation using Bitcoin technologies at BTSE
BTSE uses segwit, BIP32 HD wallets, and multisig key management to reduce their operational burdens and improve fund safety. For this Optech field report, we interviewed BTSE staff to learn how their exchange operations have benefited from these Bitcoin technologies.
BIP32 is a widely-implemented standard that describes how to deterministically derive arbitrarily-many new public keys from a single extended public key, even if the corresponding private key is kept offline. Without BIP32, the burden of securely storing private keys would incentivize reuse of public keys and addresses, leading to problems that include exchange front-running and user loss of privacy. Speaking about the operational advantages of cold wallet deposits for users, BTSE’s CEO Jonathan Leong notes that “if the hot wallet keys are compromised, addresses for all users would have to be re-generated, and inevitably some users would continue to send funds to their old addresses.”
Although exchanges using BIP32 can keep their private key offline, that private key is still a single point of failure. Happily, they can lessen the impact of compromise of any one single key by constructing a k-of-n multisig address with each of the n public keys derived from a different extended public key. What BTSE achieves with this combination is on-the-fly generation of arbitrarily-many addresses that all deposit straight into a multisig cold wallet without needing to touch the private keys.
Aside from BIP32 and multisig, BTSE also uses P2SH-P2WSH (P2SH-wrapped segwit) for their deposit addresses. Segwit allows BTSE to reduce the fee of spending transactions by reducing their weight, such as for moving to hot wallets or UTXO consolidation. As an example, spending from a P2SH-P2WSH 2-of-3 multisig address saves 44% when compared to spending from a legacy P2SH one. As adoption of sending to native segwit P2WSH addresses rises (tracked on Optech’s compatibility matrix), businesses should also consider using these addresses for deposits to unlock 14% additional savings and increase security for their multisig scripts (256-bits rather than 160-bits). You can learn about adoption speed, address security, and much more in our Bech32 Sending Support series.
Segwit, BIP32, and multisig work together to ease the burden of operating a secure, usable, and low-fee exchange for BTSE. Optech encourages new exchanges to consider these technologies when designing their infrastructure. For existing exchanges, as noted in a previous field report, a good time to consider adopting these technologies and reducing your technical debt is when you’re also consolidating UTXOs.
Bitcoin Core #15558 changes the number of DNS seeds Bitcoin Core
typically queries. DNS seeds are servers hosted by well-known
contributors that return the IP addresses of listening peers (peers
that accept incoming connections). Newly-started nodes query the DNS
seeds to find an initial set of peers; then those peers tell the node
about other possible peers, with the node saving this information to
disk for use later (including after restarts). Ideally, nodes only
ever query DNS seeds once—when they’re first started. Practically,
though, they may also query on subsequent startups if none of the
saved peers they select responds quickly enough.
This merge causes Bitcoin Core to only query three DNS seeds at a
time rather than all of them. Three seeds should be enough
diversity in sources to ensure the node connects to at least one
honest peer (a requirement for Bitcoin security), but it’s few enough
that not every seed will learn about the querying node if it uses
direct DNS resolution. Which seeds to query are selected randomly
from the list hardcoded into Bitcoin Core.
LND #3523 allows users to update the maximum millisat value of
HTLCs they’ll accept in a particular open channel or across all of
their open channels.
LND #3505 limits invoices to 7,092 bytes, the maximum size that
will fit in a single QR code. Larger invoices could cause large
amounts of memory to be allocated. For example, a 1.7 MB invoice
tested by the patch author produced about 38.0 MB in allocations.
Eclair #1097 begins deriving channel keys from the funding pubkey,
allowing Eclair to use the Data Loss Protection (DLP) scheme described
in Newsletter #31 even if all data has been lost.
This does require the user recall the node they opened their channel
with and find the channel id (which is public information for public
This only applies to new channels
opened after updating to a version of the software implementing this
change; old channels are unaffected. (Note: an earlier version of
this bullet mistakenly claimed this merged PR would make it possible
for Eclair to add DLP support. Instead, Eclair already had DLP
support and this PR changed how the channel keys are derived in order
to make that support useful even if all data is lost. Optech thanks
Fabrice Drouin for reporting our error.)
C-Lightning #3057 makes it possible to use postgres as
C-Lightning’s database manager.
C-Lightning #3064 makes the changes described in Newsletter
#63 for reducing how often a C-Lightning node will
relay channel update announcements from other nodes. This reduces the
amount of gossip bandwidth a node uses.