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 Stack Exchange, releases and release candidates, and notable changes to popular Bitcoin infrastructure software.
None this week.
- ● 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 Stack Exchange
Bitcoin Stack Exchange 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.
● What is the motivation for separating Bitcoin Core into independent node, wallet, and GUI processes? Michael Folkson outlines the benefits of Russell Yanofsky’s efforts to separate Bitcoin Core into different
bitcoin-guiprocesses. Modularity would allow users more flexibility in their setups and developers maintainability and security benefits.
● What’s the most efficient way to create a raw transaction with a specific fee rate? Stack Exchange user Darius asks about the interplay between UTXO selection and feerate when constructing a transaction. Murch provides an overview of the effective value approach to coin selection, consideration of change avoidance, and attention to signature length.
● Will there be a testnet4? Or do we not need a testnet reset once we have Signet? Michael Folkson explains the considerations involving a potential testnet reset or introduction of a new signet network. A related Stack Exchange question this month also summarizes two options for working with signet.
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
● 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
avoidpartialspendsconfiguration option is disabled.
avoidpartialspendsimproves 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,
avoidpartialspendsis disabled by default unless the
avoid_reuseflag is enabled for the wallet (see Newsletter #52). It is for this default case that
maxapsfeewas conceived—its addition gives users a choice between three configurations:
-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.
-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.
maxapsfeeset 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.00001000means the wallet will avoid partial spends if the absolute fee difference is up to 1,000 sats.
● Bitcoin Core #19550 adds a new
getindexinfoRPC 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
utxopsbtRPCs so that they can each take a
locktimeparameter 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.