This week’s newsletter describes a compiler bug that casts doubt on the safety of secure systems and explains a technique that can be used to more efficiently verify ECDSA signatures in Bitcoin. Also included are our regular sections with popular questions and answers from the Bitcoin StackExchange, announcements of releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure software.

Action items

None this week.

News

• ● Discussion about compiler bugs: a test written last week by Russell O’Connor for libsecp256k1 failed due to a bug in the GNU Compiler Collection’s (GCC’s) built-in version of the standard C library’s memcmp (memory compare) function. This function takes two regions of memory, interprets them as integer values, and returns whether the first region is less than, equal to, or greater than the second region. This is a commonly used low-level function. Programs are almost never designed to verify such fundamental operations were performed correctly, so bugs of this type can easily result in a program producing incorrect results. Those incorrect results are possible even if the program’s code was well reviewed, strongly tested, formally verified, and otherwise built with the utmost care. A single incorrect result in the execution of cryptographic or consensus code could result in serious consequences for the users of that code—or anyone who depends on remaining in consensus with users of that code.

  The potential issues affect not only software written in C and compiled with GCC, but any software or library that depends on software or libraries compiled with the affected versions of GCC. It also includes programs written in other languages whose compilers or interpreters were built using GCC. Although the full extent of the issue is still unknown, Russell O’Connor has run an analysis of an entire Linux system and found only a handful of instances where this bug causes a miscompilation, suggesting that it’s fairly rare for code to be miscompiled due to the bug.

  Issues were opened in both the libsecp256k1 and Bitcoin Core repositories to find and mitigate any effects of this bug. The topic was also discussed during the weekly Bitcoin Core Developers Meeting.

  As of this writing, developers have tested Bitcoin Core 0.20.1 and not found any direct problems. If any noteworthy problems are found in other software, we’ll provide an update in a future newsletter.

• ● US Patent 7,110,538 has expired: Bitcoin transactions are secured using ECDSA (the Elliptic Curve Digital Signature Algorithm). Verifying signatures involves multiplying points on the elliptic curve by scalars. Typically, each transaction input requires one or more signature verifications, meaning that syncing the Bitcoin block chain can require many millions of these elliptic curve point multiplications. Any technique to make point multiplications more efficient therefore has the potential to significantly speed up Bitcoin Core’s initial sync.

  In a 2011 bitcointalk post, Hal Finney described a method by Gallant, Lambert and Vanstone (GLV) to efficiently compute elliptic curve point multiplications using an endomorphism on the curve (a mapping from the curve to itself which preserves all relationships between points). By using this GLV endomorphism, the multiplication can be broken into two parts, which are calculated simultaneously to arrive at the solution. Doing this can reduce the number of expensive computations by up to 33%. Finney wrote a proof-of-concept implementation of the GLV endomorphism, which he claimed sped up signature verification by around 25%.

  Pieter Wuille separately implemented the GLV endomorphism algorithm in the libsecp256k1 library, which is used to verify signatures in Bitcoin Core. However, the algorithm was encumbered by U.S. Patent 7,110,538 and so to avoid any legal uncertainty, the implementation has not previously been distributed to users. On September 25, the patent expired, removing that legal uncertainty. A PR has been opened in the libsecp256k1 repo to always use the GLV endomorphism algorithm, which is expected to decrease Bitcoin Core’s initial sync time significantly.

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 to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

• ● What is the history of nLockTime in Bitcoin Core? Reviewing older versions of Bitcoin Core’s source code, Martin Harrigan asks for clarification on whether height-based or time-based nLockTime features were added first and what fork implications that had. Pieter Wuille and David A. Harding confirm height-based logic came first and give some interesting historical insights.

• ● Is there any other P2P protocol in use besides a “Gossip protocol”? Murch outlines the different communication protocols used in the Bitcoin ecosystem including Bitcoin’s P2P protocol, mining protocols like FIBRE and stratum, LN-related protocols, as well as multiparty coordination protocols like payjoin.

• ● Why do Anchor Outputs need to enforce an nSequence of 1? Dalit Sairio asks about anchor outputs and the necessity of the OP_CHECKSEQUENCEVERIFY (CSV) addition to LN scripts. User darosior describes the concerns around CPFP carve-out and why the delay of 1 block is needed.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

• ● LND 0.11.1-beta.rc4 is the release candidate for a minor version. Its release notes summarize the changes as “a number of reliability improvements, some macaroon [authentication token] upgrades, and a change to make our version of anchor commitments spec compliant.”

Notable code and documentation changes

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

• ● Bitcoin Core #18267 and #19993 add support for signet. If Bitcoin Core is started with -signet (or -chain=signet), it’ll connect to either the default signet or the signet defined by the -signetchallenge and -signetseednode parameters.

• ● Bitcoin Core #19572 adds a new “sequence” ZMQ topic that notifies subscribers when blocks are connected/disconnected and when transactions are added/removed from the mempool. Transaction addition/removal notification messages include a “mempool sequence number” that subscribers can use to determine the order in which these additions/removals occurred and to cross-reference with getrawmempool RPC results, which now also include this new field.

• ● C-Lightning #4068 and #4078 update C-Lightning’s signet implementation to be compatible with the final parameters chosen in BIP325 and Bitcoin Core’s default signet.

• ● Eclair #1501 adds support for unilateral closes of channels using anchor outputs, completing Eclair’s basic implementation of this new LN protocol feature. According to the PR, Eclair still needs to add the features necessary to fee bump commitment transactions and HTLCs, but this is coming next.

• ● LND #4576 is the first in a planned series of PRs adding support for anchor outputs to LND’s watchtower implementation. This PR, in particular, adds a flag indicating that anchor outputs were used in the channel being closed so that the watchtower can respond appropriately. The PR notes, “[the] changes require no modification of the encrypted payload format. The anchor payloads are equal size and contain exactly the same witness info as the legacy payloads, only requiring light modifications to the reconstruction logic.”

• ● BIPs #907 updates the BIP155 specification of version 2 addr messages to allow addresses up to 512 bytes and adds a new sendaddrv2 message that nodes can use to signal that they want to receive addrv2 messages.