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.
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 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.
● 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?
StackExchange 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
- ● 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
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
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
avoid_reuseflag is enabled for the wallet (see Newsletter
#52). It is for this default case that
was conceived—its addition gives users a choice between three
-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
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
● 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
● 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.