This week’s newsletter summarizes a post about ways of integrating discreet log contracts with LN channels, links to a detailed summary of the recent LN developer conference, and describes ideas for performing additional verification of compact block filters. Also included are our regular sections with the summary of a Bitcoin Core PR Review Club meeting, our final column about preparing for taproot activation, descriptions of new releases and release candidates, and a list of notable changes to popular infrastructure software.

News

  • ● DLCs over LN: Thibaut Le Guilly started a thread on the DLC-Dev mailing list about integrating Discreet Log Contracts (DLCs) with LN. The initial post describes several possible constructions for including DLCs in the transactions between two direct LN peers, e.g. Alice and Bob who jointly operate a channel. The post also describes some of the challenges in creating DLCs that are routed across the LN network.

  • ● LN summit 2021 notes: Olaoluwa Osuntokun posted an extensive summary from the recent virtual and in-person LN developers meeting in Zurich. The summary includes notes about using taproot in LN, including PTLCs, MuSig2 for multisignatures, and eltoo; moving specification discussion from IRC to video chats; changes to the current BOLTs specification model; onion messages and offers; stuckless payments (see Newsletter #53); channel jamming attacks and various mitigations; and trampoline routing.

  • ● Additional compact block filter verification: The Neutrino lightweight included a heuristic for detecting when a compact block filter might not include correct data, and this heuristic incorrectly reported an error on correctly-generated filters for a block on testnet containing a taproot transaction. The problem has been patched in the Neutrino source code and other implementations of compact block filters are not affected, but Olaoluwa Osuntokun started a thread on the Bitcoin-Dev and LND-Dev mailing lists about the problem—and about possible future improvements to compact block filters, such as:

    • ● New filters: creating additional optional filter types to allow lightweight clients to search for other types of data.

    • ● New P2P protocol message: adding a new P2P protocol message for retrieving block undo data. Block undo data includes the previous outputs (and related information) for each input spent in a block, which can be combined with a block to fully verify a filter was generated from that data. Undo data can itself be verified in the case of discrepancies between peers.

    • ● Multi-block filters: these could further reduce the data lightweight clients will need to download.

    • ● Committed block filters: requiring miners commit to the filter for their blocks, reducing the amount of data lightweight clients need to download to monitor for discrepancies between the filters being served by different peers.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

Add ChainstateManager::ProcessTransaction is a PR by John Newbery to add a new ChainstateManager::ProcessTransaction() interface function responsible for processing transactions as candidates to the mempool and performing mempool consistency checks. The review club discussed the current interface for adding transactions to the mempool.

  • What is cs_main? Why is it called cs_main?

    cs_main is a mutex intended to synchronize multi-threaded access to validation state. In reality, it also guards non-validation data, including data used in P2P logic; multiple contributors wish to minimize the usage of cs_main. The variable was named when validation functionality was housed in a main.cpp file. The prefix, cs, stands for critical section. ➚

  • Which components currently call AcceptToMemoryPool? Which of the ATMP calls are from external client code and which are from inside validation?

    Excluding calls from tests, there are four call sites:

    1. When the node starts, it loads transactions from mempool.dat and calls ATMP to re-validate the transactions and restore mempool contents. This is an internal validation call.
    2. Transactions received from peers on the P2P network are validated and submitted to the mempool through ATMP. This call originates from a component ‘external’ to validation.
    3. During a reorg, any transactions that were present in the disconnected block(s) but not included in the new chain tip are resubmitted to the mempool using ATMP. This is an internal validation call.
    4. Clients such as RPC (e.g. sendrawtransaction) and the wallet (e.g. sendtoaddress) submit their transactions to the node using BroadcastTransaction(), which calls ATMP. The testmempoolaccept RPC also calls ATMP with test_accept set to true. These are examples of calls from components ‘external’ to validation. ➚
  • What does CTxMemPool::check() do? Whose responsibility is it to call that function?

    CTxMemPool::check() checks that all transactions’ inputs correspond to available UTXOs and performs internal consistency checks over the entire mempool. For example, it counts the ancestors and descendants of each mempool entry to ensure the cached ancestorsize, ancestorcount, descendantsize, and descendantcount values are accurate. Currently, callers of ATMP are responsible for calling check() afterwards. However, the participants discussed that it should be the ChainstateManager’s responsibility to perform its own internal consistency checks. ➚

  • What does the bypass_limits argument do? In which circumstances is ATMP called with it set to true?

    When bypass_limits is true, the mempool maximum size and minimum feerate are not enforced. For example, if the mempool is full and its dynamic mempool minimum feerate is 3 sat/vB, an individual transaction with a 1 sat/vB feerate may be accepted. ATMP is called with bypass_limits during a reorg; these transactions may have low individual feerates but high descendant feerates. The total size of the transactions to re-add to the mempool is limited to MAX_DISCONNECTED_TX_POOL_SIZE, or 20 MB. ➚

Preparing for taproot #21: thank you!

The final entry in a weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.

Taproot will activate at block 709,632, which is anticipated a few days after the publication of this column. As the final entry in this series, we would like to thank some of the many people who helped develop and activate taproot—and who will soon begin enforcing it. Many others not mentioned below are also deserving of thanks—we apologize for all such omissions.

Bitcoin-dev mailing list discussions

The key idea behind taproot originated on the morning of 22 January 2019 at a meeting between several cryptographers. It was posted to the Bitcoin-Dev mailing list later the same day. Each of the people named below contributed to a thread with “taproot” in its name.

Adam Back, Andrea Barontini, Andreas Schildbach, Andrew Chow, Andrew Poelstra, Anthony Towns, Antoine Riard, Ariel Lorenzo-Luaces, Aymeric Vitte, Ben Carman, Ben Woosley, Billy Tetrud, BitcoinMechanic, Bryan Bishop, Carlo Spiller, Chris Belcher, Christopher Allen, Clark Moody, Claus Ehrenberg, Craig Raw, Damian Mee, Daniel Edgecumbe, David A. Harding, DA Williamson, Elichai Turkel, Emil Pfeffer, Eoin McQuinn, Eric Voskuil, Erik Aronesty, Felipe Micaroni Lalli, Giacomo Caironi, Gregory Maxwell, Greg Sanders, Jay Berg, Jeremy Rubin, John Newbery, Johnson Lau, Jonas Nick, Karl-Johan Alm, Keagan McClelland, Lloyd Fournier, Luke Dashjr, Luke Kenneth Casson Leighton, Mark Friedenbach, Martin Schwarz, Matt Corallo, Matt Hill, Michael Folkson, Natanael, Oleg Andreev, Pavol Rusnak, Pieter Wuille, Prayank, R E Broadley, Riccardo Casatta, Robert Spigler, Ruben Somsen, Russell O’Connor, Rusty Russell, Ryan Grant, Salvatore Ingala, Samson Mow, Sjors Provoost, Steve Lee, Tamas Blummer, Thomas Hartman, Tim Ruffing, Vincent Truong, vjudeu, yancy, yanmaani—, and ZmnSCPxj.

However, many of the ideas included in taproot, such as schnorr signatures and MAST, predate taproot by years or even decades. It’s beyond our capacity to list the many contributors to those ideas, but we owe them our thanks nonetheless.

Taproot BIP review

Starting in November 2019, a large number of users and developers participated in an organized review of taproot and related developments.

achow101, afk11, aj, alec, amiti, _andrewtoth, andytoshi, ariard, arik, b10c, belcher, bjarnem, BlueMatt, bsm1175321, cdecker, chm-diederichs, Chris_Stewart_5, cle1408, CubicEarth, Day, ddustin, devrandom, digi_james, dr-orlovsky, dustinwinski, elichai2, evoskuil, fanquake, felixweis, fjahr, ghost43, ghosthell, gmaxwell, harding, hebasto, instagibbs, jeremyrubin, jnewbery, jonatack, justinmoon, kabaum, kanzure, luke-jr, maaku, mattleon, michaelfolkson, midnight, mol, Moller40, moneyball, murch, nickler, nothingmuch, orfeas, pinheadmz, pizzafrank13, potatoe_face, pyskell, pyskl, queip, r251d, raj_149, real_or_random, robert_spigler, roconnor, sanket1729, schmidty, sipa, soju, sosthene, stortz, taky, t-bast, theStack, Tibo, waxwing, xoyi-, and ZmnSCPxj.

GitHub pull requests

The main implementation of taproot in Bitcoin Core was submitted for review starting in January 2020 in two pull requests. The following people left a GitHub review on those PRs.

Andrew Chow (achow101), Anthony Towns (ajtowns), Antoine Riard (ariard), Ben Carman (benthecarman), Ben Woosley (Empact), Bram (brmdbr), Cory Fields (theuni), Dmitry Petukhov (dgpv), Elichai Turkel (elichai), Fabian Jahr (fjahr), Andreas Flack (flack), Gregory Maxwell (gmaxwell), Gregory Sanders (instagibbs), James O’Beirne (jamesob), Janus Troelsen (ysangkok), Jeremy Rubin (JeremyRubin), João Barbosa (promag), John Newbery (jnewbery), Jon Atack (jonatack), Jonathan Underwood (junderw), Kalle Alm (kallewoof), Kanon (decryp2kanon), kiminuo, Luke Dashjr (luke-jr), Marco Falke (MarcoFalke), Martin Habovštiak (Kixunil), Matthew Zipkin (pinheadmz), Max Hillebrand (MaxHillebrand), Michael Folkson (michaelfolkson), Michael Ford (fanquake), Adam Ficsor (nopara73), Pieter Wuille (sipa) Sjors Provoost (Sjors), Steve Huguenin-Elie (StEvUgnIn), Tim Ruffing (real-or-random), and Yan Pritzker (skwp).

This doesn’t count several other related PRs to Bitcoin Core as well as the work of implementing taproot in other software, including schnorr support in libsecp256k1 (used by Bitcoin Core) or alternative node software.

Taproot activation discussion

As the taproot implementation was merged into Bitcoin Core, it fell on the community to decide how it would be activated. This led to several months of discussion, with the most active conversations on the taproot activation IRC channel between the following users, developers, and miners:

6102bitcoin, AaronvanW, achow101, aj, alec, Alexandre_Chery, Alistair_Mann, amiti, andrewtoth, andytoshi, AnthonyRonning, ariel25, arturogoosnargh, AsILayHodling, averagepleb, bcman, belcher, benthecarman, Billy, bitcoinaire, bitentrepreneur, bitsharp, bjarnem, blk014, BlueMatt, bobazY, brg444, btcactivator, btcbb, cato, catwith1hat, cguida, CodeShark__, conman, copumpkin, Crash78, criley, CriptoLuis, CubicEarth, darbsllim, darosior, Day, DeanGuss, DeanWeen, debit, Decentralizedb, devrandom, DigDug, dome, dr_orlovsky, duringo, dustinwinski, eeb77f71f26eee, eidnrf, elector, elichai2, Emcy, emzy, entropy5000, eoin, epson121, erijon, eris, evankaloudis, faketoshi, fanquake, fedorafan, felixweis, fiach_dubh, fjahr, friendly_arthrop, GeraldineG, gevs, gg34, ghost43, ghosthell, giaki3003, gloved, gmaxwell, graeme1, GreenmanPGI, gr-g, GVac, gwillen, gwj, gz12, gz77, h4shcash, harding, hebasto, hiro8, Hotmetal, hsjoberg, huesal, instagibbs, Ironhelix, IT4Crypto, ja, jaenu, JanB, jeremyrubin, jimmy53, jnewbery, jonatack, jonny100051, jtimon, kallewoof, kanon, kanzure, Kappa, keblek, ksedgwic, landeau, lucasmoten, luke-jr, maaku, Majes, maybehuman, mblackmblack, mcm-mike, Memesan, michaelfolkson, midnight, MikeMarzig, mips, mol, molz, moneyball, mrb07r0, MrHodl, murch, naribia, newNickName, nickler, nikitis, NoDeal, norisgOG, nothingmuch, occupier, OP_NOP, OtahMachi, p0x, pinheadmz, PinkElephant, pox, prayank, prepaid, proofofkeags, provoostenator, prusnak, qubenix, queip, r251d, rabidus, Raincloud, raj, RamiDz94, real_or_random, rgrant, riclas, roasbeef, robert_spigler, rocket_fuel, roconnor, rovdi, rubikputer, RusAlex, rusty, sanket1729, satosaurian, schmidty, sdaftuar, setpill, shesek, shinobiusmonk, snash779, solairis, somethinsomethin, stortz, sturles, sugarpuff, taPrOOteD, TechMiX, TheDiktator, thomasb06, tiagocs, tomados, tonysanak, TristanLamonica, UltrA1, V1Technology, vanity, viaj3ro, Victorsueca, virtu, walletscrutiny, wangchun, warren, waxwing, Whatisthis, whuha, willcl_ark, WilliamSantiago, windsok, wumpus, xxxxbtcking, yanmaani, yevaud, ygrtiugf, Yoghurt11411, zmnscpxj, and zndtoshi.

Miner signaling

We also thank all of the miners since block 681,408 that have signaled their readiness to enforce taproot’s rules.

Side projects

Activation of taproot is only the start. It will now be up to developers and users to begin using the new features made available. Some have been preparing for this for years, working on projects such as MuSig and others. There’s no convenient way to get a list of such developers, but we thank all of them any way.

Node operators

Most importantly, we all owe thanks to the thousands of operators of Bitcoin full verification nodes that have upgraded to Bitcoin Core 0.21.1 or later (or compatible software) and who use their nodes for receiving payments, ensuring that they will only accept transactions in blocks that obey taproot’s rules starting with block 709,632. This provides an economic incentive for every other Bitcoin user to also only accept taproot-compliant blocks, making it safe for everyone to use taproot’s features.

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.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • ● Rust-Lightning #1078 adds channel_type negotiation as defined in BOLTs #880 and covered in Newsletter #165. This implementation does not currently send the proposed feature bit from BOLTs #906. BOLTs #880 is required for anchor channels and may also be needed to support zero-conf channels.

  • ● Rust-Lightning #1144 adds a penalization mechanism to the route scoring logic. The penalty is applied to failed channels between payment retries to inform the pathfinding algorithm of potentially faulty channels.

  • ● BIPs #1215 makes several updates to the OP_CHECKTEMPLATEVERIFY proposal in BIP119:

    • Specifying that the soft fork would be deployed using a speedy trial activation, similar to taproot activation.
    • Documenting the rationale for using non-tagged SHA256 hashes.
    • Adding more comparison between the OP_CHECKTEMPLATEVERIFY proposal and the SIGHASH_ANYPREVOUT proposal.
    • Explaining the interactions between OP_CHECKTEMPLATEVERIFY and other potential future consensus changes.