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.

News

• ● 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 (RBF), 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 OP_CSV”) 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 (BIPs), 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 protocol 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.