Bitcoin Optech Newsletter #107

129 Views

This week’s newsletter links to several discussions about activating
taproot and summarizes a proposed update to BIP173 bech32 addresses.
Also included are our regular sections summarizing interesting changes to
services and client software, releases and release candidates, and notable
changes to popular Bitcoin infrastructure software.

Action items

None this week.

News

  • ● Taproot activation discussions: several discussions were started
    or continued this week about choosing a method for activating
    taproot.

    • ● New IRC room: Steve Lee posted to the Bitcoin-Dev
      mailing list an announcement of a new ##taproot-activation IRC
      room on the Freenode network. The channel is logged and saw an impressive amount of conversation from dozens of
      participants during its first week.

    • ● Mailing list thread: Anthony Towns posted a summary of
      the recently updated BIP8 activation method (see Newsletter
      #104      ) and of his own new bip-decthresh
      activation proposal (based on Matt Corallo’s “modern soft fork
      activation” post in January, see Newsletter #80). An interesting feature of the decreasing threshold
      idea is that the amount of network hashrate needed to signal
      readiness to enforce the new soft fork rules would decrease during
      the final activation period, allowing miner activation with
      perhaps as little as 60% miner support rather than the 95% miner
      support needed during the first activation period.

  • ● Bech32 address updates: Russell O’Connor posted to
    the Bitcoin-Dev mailing list a reply to Pieter Wuille’s November post
    (see Newsletter #77) about amending BIP173 to only
    allow witness programs of either 20 or 32 bytes, minimizing the risk
    that typos would cause a user to irrecoverably send bitcoins to a
    wrong address. O’Connor made the counter-proposal that we could allow
    any witness program that had five more characters in its address than
    the next shortest address, up to the consensus-enforced length limit
    on witness programs. The counter-proposal didn’t receive any
    discussion on the mailing list, but a PR to update BIP173
    did receive several comments. As of this writing, no conclusion has
    been reached about what length restrictions to use.

Changes to services and client software

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

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.10.4 is a minor release that fixes a bug affecting backups
    on Windows.

  • ● C-Lightning 0.9.0rc2 is a release candidate for
    an upcoming major release. It adds support for the updated pay
    command and new keysend RPC described in this newsletter’s notable
    code changes     section, among several other notable changes and
    multiple bug fixes.

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 #19109 introduces further improvements to
    transaction-origin privacy. Building on
    Bitcoin Core #18861, this patch adds a
    per-peer rolling bloom filter to track which transactions were recently
    announced to the peer. When a peer requests a transaction, this upgrade
    checks the filter before fulfilling the request and relaying the
    transaction to prevent spy nodes from learning about the exact contents
    of our mempool or the precise timing of when a transaction was received.

  • ● Bitcoin Core #16525 updates several RPCs to return transaction
    version numbers as unsigned integers rather than signed integers.
    Early versions of Bitcoin interpreted version numbers as signed
    integers (and
    some
    transactions in the chain did actually set negative version numbers),
    but the introduction of BIP68 nSequence enforcement for
    transactions with version 2 or higher specified that it would match
    against transaction nVersion fields cast to unsigned integers. It’s
    expected that any other future soft forks that use transaction
    versions will specify the same rule, and so it makes sense for RPCs to
    always return unsigned numbers for transaction versions.

  • ● C-Lightning #3809 adds support to C-Lightning for effective
    sending of multipath payments—payments
    which are split into several parts, with each part routed using a
    different path. In brief, the algorithm C-Lightning uses splits
    a payment into parts approximately 0.0001 BTC in value (each part having its
    amount randomly fuzzed by plus or minus 10%). If any sent part fails,
    that part is split into two parts (roughly in half, plus or minus 10%)
    and the two parts are resent. The PR additionally adds a
    disable-mpp configuration option that will prevent sending any
    multipath payments; a parameter of the same name is also added to the
    pay command to disable sending a multipath payment for that
    particular attempt.

  • ● C-Lightning #3825 changes the recently merged
    (but never released) reserveinputs RPC so that it no longer
    generates a new PSBT. Instead, a new fundpsbt RPC is
    introduced to create a new PSBT. An existing PSBT may now be passed
    to reserveinputs to prevent the UTXO inputs to the PSBT from being
    used in other transactions until a specified block height (default, 72
    blocks in the future, about 12 hours from present) or as long as the
    daemon is running. Alternatively, fundpsbt will default to
    reserving the selected UTXOs when it creates the transaction.

  • ● C-Lightning #3826 completes a series of PRs that modify the logic
    C-Lightning uses to send payments. Most of those changes should be
    invisible to users, but in case of problems, the previous
    logic available with the pay command is available using the new
    legacypay command. Anyone using the pay command from this point
    forward will be using the new logic.

  • ● C-Lightning #3792 adds a new keysend RPC for sending
    spontaneous payments. This new RPC is different
    from the keysend plugin, described in Newsletter #94, which allows C-Lightning to receive spontaneous payments.

  • ● LND #4429 adds a --protocol.wumbo configuration option and
    enables it by default. When supported by both the local node and a
    remote peer, this option allows the opening of large channels where the total channel value exceeds 0.16 BTC.

—Source link—

What do you think?

0 points
Upvote Downvote

How to speculate on DeFi tokens with binary options

Gitcoin Grants Round 6 Retrospective