Bitcoin Optech Newsletter #117 Bitcoin Optech

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.


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

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
, 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

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

—Source link—

What do you think?

How to trade DeFi tokens with Matcha Bankless

NEO Flamingo Finance Attracts $1.6B in TVL for DeFi Swiss Army Knife DeFi Rate