Bitcoin Optech Newsletter #112 Bitcoin Optech

169 Views

This week’s newsletter links to a discussion about routed coinswaps and
includes our regular sections with summaries of questions and answers
from the Bitcoin StackExchange, releases and release candidates, and
notable changes to popular Bitcoin infrastructure software.

Action items

None this week.

News

  • ● Discussion about routed coinswaps: Chris Belcher posted a design document for a routed multi-transaction coinswap
    implementation to the Bitcoin-Dev mailing list as a follow-up to his
    previous post in May (see Newsletter #100).
    Comments focused on checking that the
    protocol was safe both in its use of cryptography and in ensuring that
    the expected transactions would be confirmed (rather than alternative
    transactions attempting theft). Discussion was still ongoing at the
    time of this writing.

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.0-beta is now released. This new major
    version allows accepting large channels (by
    default, this is off) and contains numerous improvements to its
    backend features that may be of interest to advanced users (see the
    release notes).

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 #14582 and #19743 add a new
    maxapsfee (“max avoid partial spends fee”) configuration option to
    specify the maximum amount of extra fee you’re willing to pay to avoid
    partial spends when the existing avoidpartialspends configuration
    option is disabled.

    Enabling avoidpartialspends improves privacy by spending from
    addresses only once (see Newsletter #6), but it
    may result in slightly higher fees due to spending all inputs received
    to the same address when only a subset of those inputs might be needed.
    For this reason, avoidpartialspends is disabled by default unless
    the avoid_reuse flag is enabled for the wallet (see Newsletter
    #52    ). It is for this default case that maxapsfee
    was conceived—its addition gives users a choice between three
    configurations:

    1. -maxapsfee=-1: partial spend avoidance is completely
      disabled to optimize for faster fee calculations, which may be
      useful for very large wallets with many UTXOs.

    2. -maxapsfee=0 (the default value): fee calculations are
      made using both coin selection algorithms. Whichever result is
      cheaper is used; if they both result in the same cost, partial
      spend avoidance is used.

    3. maxapsfee set to greater than 0: partial spend avoidance is
      used whenever the maximum additional cost it adds to the
      transaction is the passed amount. For example,
      -maxapsfee=0.00001000 means the wallet will avoid partial
      spends if the absolute fee difference is up to 1,000 sats.

  • ● Bitcoin Core #19550 adds a new getindexinfo RPC that lists each
    optional index that has been enabled, how many blocks have been
    indexed so far, and whether those blocks constitute syncing all the way
    to the tip of the block chain.

  • ● C-Lightning #3954 updates both the fundpsbt and utxopsbt RPCs
    so that they can each take a locktime parameter that specifies the
    nLockTime of the transaction to create. The PR notes that this is
    “required for dual funding, where the opener sets [the
    locktime]”.

  • ● BIPs #955 updates BIP174 to standardize supplying hash preimages in
    PSBT input records. The standardization of these preimage fields
    was found to be necessary for miniscript-aware finalizers, though
    they can be used by any PSBT finalizer needing to satisfy hash preimage
    challenges (e.g. for onchain LN commitment transactions).

  • ● BOLTs #688 adds support for anchor outputs
    to the LN specification. This extends commitment transactions with
    two extra outputs—one for each counterparty—which can be used for
    Child Pays For Parent (CPFP) fee bumping. With this
    change, it becomes possible to fee bump commitment transactions that
    may have been signed days or weeks earlier, when the current feerates
    would’ve been hard to predict. In practice, LN nodes using anchor
    outputs should normally pay lower fees because there’s no longer any
    incentive to overestimate fees. Anchor outputs also provide greater security
    because, if feerates do increase beyond what was predicted, the node
    can fee bump its commitment transaction. Various degrees of support
    for anchor outputs have already been merged into several LN
    implementations.

  • ● BOLTS #785 updates the minimum CLTV expiry delta to 18 blocks. To
    ensure that the latest state is recorded onchain, a channel should
    be unilaterally closed when there are only this many blocks until an
    LN payment has to be settled. However, the higher the expiry is, the
    more time a payment could become temporarily stuck in an open channel
    (either by accident or deliberately). This has led some LN
    implementations to use route-finding algorithms that optimize for
    routes with low CLTV expiry deltas, which has in turn led some users
    to set their deltas to values that are especially unsafe. This new
    minimum should help prevent inexperienced users from naively setting
    an unsafe value.

—Source link—

What do you think?

0 points
Upvote Downvote

Hack the Rainbow 🌈 – ETHNEAR Bridge Hackathon Gitcoin’s Blog

The Rebirth of bZx Protocol Token Tuesdays