This week’s newsletter summarizes a proposed design for a coinswap
implementation, describes new middleware for allowing lightweight
wallets to request information directly from a user’s own node, and highlights
two transaction size calculators. Also included are our regular
sections with descriptions of several recently transcribed talks, new
releases and release candidates, and notable changes to popular Bitcoin
infrastructure software. A special final section celebrates the
publication of Newsletter #100.
None this week.
● Design for a coinswap implementation: Chris Belcher
posted a design for a full-featured coinswap
implementation. Coinswap is a protocol that allows two users to
create a pair of transactions that look like regular payments but which
actually swap their coins with each other. This improves the privacy
of not just the coinswap users but all Bitcoin users, as anything that
looks like a payment could have instead been a coinswap.
Belcher’s post summarizes the history of the coinswap idea, suggests ways the multisig conditions needed for coinswap could be disguised as more common transaction types, proposes using a market for liquidity (like JoinMarket already does), describes splitting and routing techniques to reduce privacy losses from amount correlation or spying participants, mentions alternative coinswap protocols such as succinct atomic swaps (see Newsletter #98), suggests combining coinswap with payjoin, and discusses some of the backend requirements for the system. Additionally, he compares coinswap to other privacy techniques such as using LN, coinjoin, payjoin, and payswap.
Belcher has a history of creating and maintaining privacy-enhancing open source software for Bitcoin, such as JoinMarket and Electrum Personal Server, which gives particular weight to the conclusion of his email: “I intend to create this CoinSwap software. It will be almost completely decentralized and available for all to use for free.”
● New node-to-wallet middleware: Nadav Ivgi announced
the alpha release of Bitcoin Wallet Tracker (BWT), a program that
interacts with Bitcoin Core’s wallet using its standard RPC interface,
uses that data to build additional indexes necessary for lightweight
wallets, and then makes that data available via both the Electrum
Server protocol and BWT’s own extensive HTTP-based API.
Similar to Electrum Personal Server, this allows users who prefer the
UI of a lightweight wallet (such as Electrum) to retrieve block and
transaction data from their own full verification node for additional
security. There’s no significant overhead to BWT’s approach: its
additional indexes are stored only in memory and it can work with
pruned nodes in many cases, allowing a combined
setup to use only a few gigabytes of disk space.
Ivgi also provides a plugin that simplifies setting up BWT with an Electrum client, and it may also be possible to use BWT with other wallets that support the Electrum Server protocol, such as Edge, Blue Wallet, Eclair mobile, and Phoenix.
BWT’s HTTP protocol supports additional features beyond those available in the Electrum Server protocol, such as key origin information useful for interaction with HD wallets and wallet collaboration tools such as PSBT. His email also notes that future versions of BWT may support output script descriptors, allowing wallets to produce and consume standardized descriptions of their script templates.
● Transaction size calculators: Jameson Lopp posted to
the Bitcoin-Dev mailing list with links to a transaction size
calculator he’d developed as well as a similar calculator
developed by Optech. Neither tool claims to be complete
or bug-free, but both should be useful to developers who want to
make a quick comparison between the sizes of different types of transactions.
Recently transcribed talks and conversations
Bitcoin Transcripts is the home for transcripts of technical
Bitcoin presentations and discussions. In this monthly feature, we
highlight a selection of the transcripts from the previous month.
● LN backups: Christian Decker presented at Potzblitz on the latest
state of LN backups. He discussed the approaches of other
implementations such as Eclair and LND before explaining why
C-Lightning is using a synchronous database log plugin. Later, he
described why LN backups are more complex than onchain backups, the
prospects of adding SIGHASH_NOINPUT or
SIGHASH_ANYPREVOUTto Bitcoin to enable eltoo-based
payment channels, and the current modularity of the LN protocol.
● Payjoin/P2EP: Adam Gibson led a discussion at London BitDevs about
payjoin, a protocol that allows both the sender and
receiver of a payment to contribute inputs to the transaction. This
breaks the common wallet ownership assumption and subset sum
analysis, improving the privacy of both the sender and the receiver.
Gibson went through the history
of the concept and described the existing implementations of payjoin
in JoinMarket and Samourai before examining details of the recent
BTCPay Server implementation. He ended by outlining several different
ways a wallet can be fingerprinted, such as the number of signatures
required, what timelocks are used, and whether the opt-in
Replace-By-Fee (RBF) flag is set. (transcript, video)
● LSAT—your ticket aboard the lightning native web: Oliver Gugger
presented the Lightning Service Authentication Token (LSAT) at
Reckless VR in virtual reality. LSAT is a proposed protocol
specification combining HTTP, macaroons, and Lightning. It’s designed
to fulfill the purpose of the HTTP 402 Payment Required response code.
Gugger described the authentication flow and the role of macaroons as
pseudonymous user authentication. The question and answer session
focused on use cases and the benefits of using LSAT, such as enhanced
user privacy and improved sign-up experience.
● Sydney meetup discussion: A number of Bitcoin and LN developers
joined this Sydney meetup to discuss topics including: the scalability
issues of onboarding millions of LN clients, Rust code integration
into Bitcoin Core, dual funding in C-Lightning, and future soft fork
activation mechanisms. The history of Linux kernel development and segwit
activation were each explored for insights into when or whether the Rust
language should be introduced to Bitcoin Core and the exact mechanism
that should be used to activate proposed soft forks such as
taproot in the future. The transcript was anonymized to
encourage open discussion. (transcript)
● The Revault multiparty vault architecture: Kevin Loaec and Antoine
Poinsot presented their vault design Revault at London Bitcoin
Devs. They outlined specific details such as its reliance on
co-signing servers and how it compares to other vault designs
that require key deletion, anticipating spending amounts, or both.
Their presentation was preceded the week before by a broader discussion
on vaults, covenants, and
OP_CTV). This included the merits of the different use cases of
OP_CTVand a possible path to it being soft forked into Bitcoin.
Additional discussion focused on the current state of the mempool
policy in Bitcoin Core and how it creates challenges such as
transaction pinning that affect the
security of both vault designs and the LN protocol. (Meetup
transcript, Presentation transcript, Meetup
video, Presentation video)
Releases and release candidates
New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
● Bitcoin Core 0.20.0 has been tagged and will likely be released
around the same time this newsletter is published. We’ll describe
this new major release in more detail next newsletter.
Notable code and documentation changes
Note: the commits to Bitcoin Core mentioned below apply to its master
development branch and so those changes will likely not be released
until version 0.21, about six months after the release of the upcoming
● Bitcoin Core #19010 and Bitcoin Core #19044 are the third and fourth
steps, respectively, of a series of five pull requests
towards support for serving compact block filters on the P2P network, as specified in BIP157. The first step was
covered in Newsletter #98.
With these changes, nodes that enable the compact block filter index with the
-blockfilterindexconfiguration parameter can now respond to
getcfiltersrequests with the corresponding
cfiltersresponses. The node does not yet advertise support for BIP157 with
NODE_COMPACT_FILTERSin its version message. The final step, Bitcoin Core #19070, is under review at the time of this writing and would enable nodes to signal the ability to serve compact block filters. The feature is disabled by default and can be enabled with the
● Bitcoin Core #16939 changes how long Bitcoin Core waits until
it queries DNS seeds for the IP addresses of potential peers.
Previously, if the node had peer IP addresses in its database, it
would try opening several connections and wait 11 seconds for
successful connections before requesting new addresses. Now, if it
has more than 1,000 IP addresses in its database—which is common for
nodes that have been online more than a few hours—it’ll wait up to 5
minutes before querying. This improves the chance that a restarted
node will entirely use P2P address discovery without relying on the
centralized DNS seeds.
● LND #4228 adds a new wallet command,
labeltx, for labeling past onchain
transactions. This is a continuation of the work done in LND #4213, which
allowed setting a label when sending a payment. Labels are personal
wallet metadata that help the user remember who they paid and what
they bought; the labels aren’t part of the onchain transactions and
aren’t shared with any other user.
On the occasion of Optech Newsletter #100
“I am somewhat surprised that nobody has taken to [writing] weekly
summaries of research and development activity. Summarizing recent
work is a valuable task that others can engage in just by reading the
mailing list and aggregating multiple thoughts together.”
—Bryan Bishop, 19 August 2015
Almost five years after Bishop made the above comment, we remain
convinced that writing weekly summaries of research and development
activity is a task that’s valuable to both the open source Bitcoin
development community and to the many businesses that depend upon the
community’s work. But in the two years we’ve been producing this
newsletter, we’ve also discovered that summarizing isn’t quite as quick
and simple as we initially expected it to be. Accordingly, we’d like to
take this chance to thank the people who make this newsletter possible
by generously contributing a significant amount of their valuable time,
week after week: Adam Jonas, Carl Dong, David A. Harding,
John Newbery, Jon Atack, Mike Schmidt, and Steve Lee.
We additionally thank the experienced Bitcoin and LN contributors who
kindly provided us with special help on certain complex topics or who
contributed field reports and other additional content to the newsletter
over the past two years.
Publishing a high-quality weekly newsletter and working to fulfill other
aspects of Optech’s mission wouldn’t be possible without
the financial support of our member companies. We thank them for their
continuing commitment to improving communication between Bitcoin users,
developers, and businesses.
We also remain eternally thankful to our founding sponsors Wences
Casares, John Pfeffer, and Alex Morcos as well as to organizations such as Chaincode Labs
and Square Crypto who allow and encourage their staff to use
their work hours to contribute to Optech.