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.


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

  • 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
    , Presentation transcript, Meetup
    , 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

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.

Thank you to our members!

We also remain eternally thankful to our founding sponsors Wences
, 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—

What do you think?

Balancer Liquidity Mining

Top 5 ETHGlobal HackMoney DeFi Virtual Hackathon Winners