Bitcoin Optech Newsletter #114 Bitcoin Optech

This week’s newsletter describes continued discussion about a protocol
for making routable coinswaps and includes our regular sections summarizing
a Bitcoin Core PR Review Club meeting
and notable changes to popular Bitcoin infrastructure projects.

Action items

None this week.


  • Continued coinswap discussion: in discussion continued from two weeks ago on the Bitcoin-Dev mailing list (see
    Newsletter #112), several contributors developed
    and analyzed potential attacks against a proposed routed coinswap
    protocol. The proposed attacks were:

    • Costless old state theft: after a coinswap, when the initiating
      party has the ability to spend a different UTXO than they started
      with, they could try to spend their old UTXO (which is now owned
      by their counterparty). If the counterparty, or a
      watchtower agent of theirs, is monitoring the
      block chain, this will fail—but the attempt will cost
      the attacker nothing.

    • Costless scorched earth: if fee bumping is made possible by the
      participants pre-signing a set of conflicting replacement
      transactions that signal support for opt-in Replace By Fee
      , then a counterparty may be able to broadcast
      the highest-fee replacement after they’ve finished receiving their
      new UTXO. This won’t earn them any money, but the high fees will
      be deducted from the value of the honest party’s UTXO and so there’s no cost to
      the attacker.

    • Costless pinning theft: like above, if there are multiple
      versions of the transaction with different feerates, an attacking
      counterparty can broadcast a low-feerate version and then use a
      transaction pinning method to make it
      impractical to fee bump. If the attack is successful, it would
      allow the attacker to spend the victim’s money; if it was
      unsuccessful, it might cost the attacker nothing extra if they
      were already planning to send the transactions they used for
      pinning (e.g. they were planning to consolidate UTXOs anyway).

    Several potential solutions to these attacks were discussed. The
    most promising solution was to require anyone
    spending a coinswap UTXO to spend part of the value of one of their
    other UTXOs to transaction fees. This collateral payment would
    eliminate the costless aspect of the previously described attacks.
    Fully addressing the attacks might also require some other changes
    related to timelocks, such as using a 1-block relative timelock (“1
    ”) to prevent pinning.

    In addition to the discussion helping to improve a privacy-enhancing
    coinswap protocol, at least one participant noted that
    some of the insights from the conversation might be applicable to
    other protocols, such as LN.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club
meeting, highlighting some of the important questions and answers. Click on a
question below to see a summary of the answer from the meeting.

Re-delegate absurd fee checking from mempool to clients is
a PR (#19339) by Gloria Zhao that proposes an updated
version of Bitcoin Core #15810. It adds separate fee-checking logic for
clients that need to enforce max feerates and then removes the nAbsurdFee
logic from AcceptToMemoryPool.

The review club discussion covered general concepts before diving into the
deeper technical aspects.

  • What does the AcceptToMemoryPool (ATMP) function in validation.cpp do?

    ATMP is the function that Bitcoin Core calls to determine whether a transaction is acceptable for inclusion in the mempool. In addition to enforcing consensus rules, ATMP also applies the node’s policy. 

  • What is “policy”?

    Policy is generally defined as each node’s network transaction rules. It excludes consensus rules and the preferences of end-user clients (e.g. wallets). 

  • What is the absurd fee parameter, nAbsurdFee, used for?

    nAbsurdFee is only used for locally submitted transactions, e.g. those originating from the node’s RPC interface and wallet. When a node receives a transaction from the network (which is the majority of calls to ATMP), it sets an empty value for nAbsurdFee

  • Is nAbsurdFee part of policy, or is it a client preference?

    The participants concluded that nAbsurdfFee is a wallet preference and not policy, as it is not enforced on the P2P network by Bitcoin Core and ATMP should give consistent results regardless of which client the transaction originates from. 

  • Why does the testmempoolaccept RPC accept a JSON array containing a maximum of only one raw transaction?

    It’s hoped that Bitcoin Core will one day be able to test multiple transactions in a single RPC without changing the interface, if package relay and package mempool acceptance are implemented. 

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 #19405 adds inbound and outbound connection counts to
    bitcoin-cli -getinfo and the getnetworkinfo RPC.

  • Bitcoin Core #19670 reserves inbound connection slots for block-relay-only
    and localhost peers. This change was motivated by a user who saw a
    decrease in the number of active inbound Tor connections over time. This
    behavior was due to unintentional bias that increased the chance
    localhost peers would get evicted when Bitcoin Core’s connection slots
    filled up. Since inbound Tor connections are seen as
    localhost peers, the connectivity of Tor peers can be improved by reserving slots
    for localhost peers. A similar reservation is made for block-relay-only peers
    which are disadvantaged but serve as a protection against eclipse attacks.

  • Bitcoin Core #14687 updates the ZMQ event notification service to
    allow creating connections (sockets) that enable TCP keepalive to
    help keep connections alive, especially when they pass through a
    device such as a router or a firewall. This is especially useful when
    using ZMQ to monitor for sometimes-rare events, e.g. for when there’s
    more than 30 minutes between notifications of new blocks.

  • Bitcoin Core #19671 removes the -zapwallettxes configuration
    option that would delete unconfirmed transactions from the wallet so
    that users could create and broadcast alternative transactions using
    the same inputs. This feature was long ago superseded by the
    abandontransaction RPC (or its equivalent context menu option in the
    GUI), each of which allows the user to remove specific unconfirmed
    transactions from the wallet.

  • Bitcoin Core #18244 updates the fundrawtransaction and
    walletcreatefundedpsbt RPCs’ lockunspents parameter so that it
    locks user-specified UTXOs (inputs) in addition to those
    automatically selected by the wallet itself. Locked UTXOs won’t
    automatically be chosen by the wallet for spending in other
    transactions until the wallet is restarted or they are manually
    unlocked; this prevents the user from accidentally creating
    multiple conflicting transactions that spend the same UTXOs.

  • LND #4463 adds the ability to create authentication tokens
    (“macaroons”) that only have permission to access a set of APIs
    specified by the administrator who created the macaroon. This
    provides more granular access control than LND’s existing
    category-based permissions system (see Newsletter #82). Additionally, a new listpermissions API is added that will
    list the available APIs and the permissions required to access them.

  • BIPs #983 updates the BIP325 definition of the signet
    to document an existing feature of the proposed Bitcoin
    Core implementation where a challenge that’s just
    OP_TRUE (or something else guaranteed to succeed on an empty
    witness) doesn’t need to include a signet commitment in a block’s
    coinbase transaction.

  • HWI #363 adds support for the BitBox02 hardware wallet. The
    initial support only allows signing for single-sig scripts, but
    multisig support is planned. According to the PR comments, this is
    the first merge where HWI support for a new device was contributed on
    behalf of the manufacturer themselves.

—Source link—

What do you think?

Nervos attends Grin meetup and shares Mimblewimble update Nervos Network – Medium

Perpetual Protocol Launches PERP Token with Balancer Bootstrap Pool DeFi Rate