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 projects.

Action items

None this week.

News

• ● 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.

Notable code and documentation changes

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

• ● 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 channels). 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.