Bitcoin Optech Newsletter #100

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.

Action items

None this week.

News

• ● 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 bitcoind and bwt
  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_ANYPREVOUT to Bitcoin to enable eltoo-based
  payment channels, and the current modularity of the LN protocol.
  (transcript, video)

• ● 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.
  (transcript,
  video)

• ● 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_CHECKTEMPLATEVERIFY
  (OP_CTV). This included the merits of the different use cases of
  OP_CTV and 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
release candidates.

• ● 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.

• ● LND 0.10.1-beta.rc3 is the latest release candidate for the next
  maintenance release of LND.

Notable code and documentation changes

Notable changes this week in Bitcoin Core,
C-Lightning, Eclair, LND,
Rust-Lightning, libsecp256k1,
Bitcoin Improvement Proposals (BIPs), and Lightning
BOLTs.

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
version 0.20.

• ● 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 -blockfilterindex configuration parameter can now respond to getcfcheckpt, getcfheaders, and getcfilters requests with the corresponding cfcheckpt, cfheaders, and cfilters responses. The node does not yet advertise support for BIP157 with NODE_COMPACT_FILTERS in 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 -peerblockfilters configuration parameter.

• ● 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.

—Source link—