Bitcoin Optech Newsletter #120 Bitcoin Optech

169 Views

This week’s newsletter provides an overview of the new MuSig2 paper,
summarizes additional discussion about upfront fees in LN, and describes
a proposal to simplify management of LN payments. Also included are our
regular sections with summaries of notable improvements to clients and
services, announcements of releases and release candidates, and changes
to popular Bitcoin infrastructure software.

Action items

None this week.

News

  • ● MuSig2 paper published: Jonas Nick, Tim Ruffing, and Yannick Seurin
    published the MuSig2 paper describing a new variant of the
    MuSig signature scheme with a two round signing protocol.

    MuSig is a signature scheme that allows multiple signers to create an aggregate public key derived from their individual private keys, and then collaborate to create a single valid signature for that public key. The aggregate public key and signature are indistinguishable from any other schnorr public key and signature.

    The original version of MuSig required a three round signing protocol: first, the co-signers exchange commitments to nonce values, then they exchange the nonce values themselves, and finally, they exchange the partial signatures. Without this three round protocol, an attacker could interact with an honest signer in multiple concurrent signing sessions to obtain a signature on a message that the honest signer did not want to sign.

    Using deterministic nonces, which is very common practice in single-signer schemes, is unsafe for multi-signer schemes, as described in the original MuSig blog post. Precomputing the nonces in advance and exchanging them at key setup time is also unsafe, as described in a blog post by Jonas Nick. It is, however, safe to precompute the nonces and exchange the nonce commitments early, moving one of the three rounds to the key setup stage.

    Removing the requirement to exchange nonce commitments has been an active area of research, and last month the MuSig-DN paper was published, demonstrating how nonce commitment exchange could be removed by generating the nonce deterministically from the signers’ public keys and the message, and providing a non-interactive zero-knowledge proof that the nonce was generated deterministically along with the nonce. This removed the requirement of exchanging nonce commitments at the cost of a more expensive signing operation.

    The new MuSig2 scheme achieves a simple two round signing protocol without the need for a zero-knowledge proof. What’s more, the first round (nonce exchange) can be done at key setup time, allowing two different variants:

    • interactive setup (key setup and nonce exchange) and non-interactive signing

    • non-interactive setup (address computed from public keys) and interactive
      signing (nonce exchange followed partial signature exchange)

    The non-interactive signing variant could be particularly useful for cold storage schemes and offline signers, and also for offchain contract protocols such as LN, where the nonces could be exchanged at channel setup time.

  • ● More LN upfront fees discussion: after last week’s
    discussion    , Joost Jager asked developers on the
    Lightning-Dev mailing list to again consider how to
    charge fees for attempting to route payments—fees that would have to
    be paid even if the attempt failed. This could help mitigate both jamming
    attacks     that can prevent nodes from earning routing fees and probing
    attacks     that allow third parties to track other people’s channel balances.
    Unfortunately, developers have not yet found a satisfactory way to
    trustlessly charge upfront fees, so recent discussion has focused on
    trust-based methods that may involve such small amounts of fee that
    users will find them acceptable.

    Unfortunately, none of the methods discussed this week seemed to meet with widespread acceptance. Several developers expressed concern that methods could be abused to penalize small honest nodes. Other developers noted that the alternative to upfront payment is an increased reliance on reputation—which likely disproportionately benefits larger nodes. We’re sure developers will continue working on this important issue and we’ll report on any notable progress in future newsletters.

  • ● Simplified HTLC negotiation: Rusty Russell posted to the Lightning-Dev mailing list about simplifying how
    payments are made and resolved in LN channels. Currently, both sides
    of a channel can each propose relaying or settling a payment, which
    requires creating or removing an HTLC from the offchain
    commitment transaction. Sometimes both sides propose a change at the
    same time and so there are conflicting commitment transactions. These
    potential conflicts may get more complicated if dynamic changes to the
    commitment transaction format and settings are allowed (see
    Newsletter #108). One proposal to
    eliminate that complication is to only allow dynamic changes when all
    HTLCs have been resolved and the channel is quiet—that improves
    safety but is more restrictive than desired.

    Russell’s proposal this week was to allow only one party in a channel to propose HTLC changes. This eliminates the risk of conflicting proposals but it increases the average network communication overhead by half a round trip (assuming each party proposes an equal number of HTLC changes). Responsibility for proposing changes can be transferred from one party to the other as needed, allowing each party to propose channel updates at different times.

    As of this writing, the proposal received only a small amount of discussion from other LN implementation maintainers, so its future remains uncertain.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin
wallets and services.

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 #19953 implements schnorr signature
    verification     (BIP340), taproot verification (BIP341), and tapscript
    verification (BIP342). The new soft fork rules are currently only
    used in the private test mode (“regtest”); they are not
    enforced in mainnet, testnet, or the default signet. The plan is to
    release the code in Bitcoin Core 0.21.0 and then prepare a subsequent
    release (e.g. 0.21.1) that can begin enforcing the soft fork’s new
    rules when an activation signal is detected. The particular
    activation signal or signals to use are still being discussed in the
    ##taproot-activation IRC chatroom (logs).

    The code consists of about 700 lines of consensus-related changes (500 excluding comments and whitespace) and 2,100 lines of tests. Over 30 people directly reviewed this PR and its predecessor, and many others participated in developing and reviewing the underlying research, the BIPs, the related code in libsecp256k1, and other parts of the system. There is still more work to do, but getting the code properly reviewed was arguably the most critical step—so we extend our most grateful appreciation to everyone who helped achieve this milestone.

  • ● Bitcoin Core #19988 redesigns the logic Bitcoin Core uses to
    request transactions from its peers. The major changes described by
    the PR description include: Bitcoin Core will now more strongly prefer
    requesting transactions from outbound peers—peers where the
    connection was opened by the local node; Bitcoin Core will now request
    an unlimited number of transactions from a peer rather than stopping
    at 100 (though slow responders won’t be preferred); and Bitcoin Core
    won’t keep track of as many pending transaction requests as before,
    the previous limit being seen as excessive. The change also greatly
    improves the readability of the code and the ability to test that the
    transaction request logic is working as expected. This testing may
    help reduce the chance that a flaw can be exploited against
    users of time-sensitive transactions (such as in LN and many other
    contract protocols).

  • ● Bitcoin Core #19077 adds a new SQLite database backend for wallet records.
    Unlike the existing Berkeley DB database backend, SQLite is designed and
    tested to be resilient against corruption from crashes and power losses.
    In the upcoming v0.21 release, legacy wallets
    will keep using the Berkeley DB backend, whereas the newly introduced
    descriptor wallets     will default to using this new
    SQLite backend. Work on developing a migration path and tentative
    timelines to deprecate and remove legacy wallets and
    the Berkeley DB wallet backend are being discussed in Bitcoin Core #20160.

  • ● Bitcoin Core #19770 deprecates the whitelisted field returned from the
    getpeerinfo RPC, which previously had its scope expanded by more granular permissioning
    (see Newsletter #60). whitelisted is set to be
    deprecated in v0.21 and is planned to be removed in v0.22.

  • ● Bitcoin Core #17428 writes a file at shutdown with the network
    addresses of the node’s two outbound block-relay-only peers. The next
    time the node starts, it reads this file and attempts to reconnect to
    those same two peers. This prevents an attacker from using node
    restarts to trigger a complete change in peers,
    which would be something they could use as part of an eclipse
    attack     that could potentially trick
    the node into accepting invalid bitcoins.

  • ● LND #4688 adds a new --duration parameter that can be used to
    indicate how long until LND stops making additional attempts to send a
    payment. The default remains 60 seconds.

  • ● Libsecp256k1 #830 enables GLV endomorphism, which allows verifying
    signatures with up to 33% fewer operations (see a comment to the PR
    with actual performance test results). The PR
    also removes the slower code for operating without endomorphism as
    there’s no reason to use it now that the patent on the GLV technique
    has expired (see Newsletter #117). This PR also
    implements an independent memcmp (memory compare) function to avoid
    the problems with GCC’s internal version of that function (see
    another section in Newsletter #117). These changes
    were subsequently pulled into Bitcoin Core.

—Source link—

What do you think?

0 points
Upvote Downvote

Bitpie builds stablecoin bridge between Ethereum and CKB Nervos Network – Medium

Update To Dharma Gas Policy Dharma Blog