This week’s newsletter announces the release of C-Lightning 0.8.1, requests help testing a Bitcoin Core maintenance release, summarizes a discussion about taproot versus implementing MAST and schnorr signatures separately, describes new ideas for using PoDLEs in LN channel construction, and highlights a new implication of work on privacy-enhanced payments to unannounced LN channels. Also included are our regular sections about notable changes to popular services, client software, and infrastructure projects.

Action items

• ● Upgrade to C-Lightning 0.8.1: this release adds several new features (including those described in the notable changes section below) and provides multiple bug fixes. See the changelog for a detailed list of updates.

• ● Help test Bitcoin Core 0.19.1rc2: this upcoming maintenance release includes several bug fixes. Experienced users are encouraged to help test for any regressions or other unexpected behavior.

News

• ● Discussion about taproot versus alternatives: a group of developers who prefers to remain anonymous (so we’ll call them Anon) wrote a criticism of taproot in comparison to alternative approaches for enabling MAST and schnorr signatures in Bitcoin. Anon concludes their criticism with five questions which we use below to organize our summary of Anon’s concerns and the replies posted by several Bitcoin contributors.

  1. Anon asks, “Is taproot actually more private than bare MAST and schnorr separately? What are the actual anonymity set benefits compared to doing them separately?”

     Anthony Towns replies, “Yes [it is more private], presuming single-pubkey-single-signature remains a common authorization pattern.” Towns shows that single-sig spends currently represent more than 57% of all transaction outputs (and possibly much more, given the frequent use of P2SH-wrapped P2WPKH). The number of people able to use single-sig will only increase if schnorr becomes available because it simplifies using interactive n-of-n multisig, interactive k-of-n threshold signing, and adaptor signatures (scriptless scripts) that look like single-sig spends onchain.

     Yet as more people turn to multisig and advanced contracts, there’s an increasing number of practical use cases that can be satisfied by a single signature most of the time but which still require the use of scripts sometimes. With just MAST—and not taproot—those use cases would need to always use MAST. MAST could also be used for single-sig spends but it would require larger transactions and more fees than a pure single-sig construction, so single-sig users would probably not use MAST. That would create a clear divide for chain analysis between spends that use MAST and spends that don’t.

     Taproot eliminates that divide by allowing cheap single-sig spends that are identical in appearance to those of users who can use single-sig but who also have fallback scripts (though actually spending using a fallback script will be identifiable onchain). This creates a larger anonymity set than doing MAST and schnorr separately as long as there really is a group of people who sometimes spend using a single signature and other times spend using a script.

  2. Anon asks, “Is taproot actually cheaper than bare MAST and schnorr separately?” Earlier in the email, Anon claimed that taproot saves 67 bytes compared to MAST+schnorr for key-path spending but adds 67 bytes for script-path spending.

     Towns points out a redundant data field in Anon’s calculation and shows that taproot actually only adds about 33 bytes in the script-path spending case, making the cost-benefit analysis asymmetric in favor of taproot. David Harding notes that the extra size (which translates to 8.25 vbytes) is quite small compared to all the other data a script-path spender would need to provide to spend a UTXO (e.g. 41 vbytes of input data, 16-vbyte signatures or other witnesses of various sizes, one or more 8-vbyte merkle nodes, and the script to execute).

  3. Anon asks, “Is taproot riskier than bare MAST and schnorr separately given the new crypto?”

     Towns replies that he “doesn’t think so; most of the risk for either of those is in getting the details right. […] Most of the complicated crypto parts are at the application layer: MuSig, threshold signatures, adaptor signatures, scriptless scripts, etc.” He also links several resources for those wanting to learn more (1, 2, 3).

  4. Anon asks, “couldn’t we forego the [Nothing Up My Sleeve] NUMS point requirement and be able to check if it’s a hash root directly?” This is a requirement that wallets create and later publish a taproot internal key even if it’s just a random curve point because they never intended to use a key-path spend. Anon essentially proposes allowing the spender to skip publishing an internal key and go straight to script-path verification.

     Towns replies, “That would decrease the anonymity set by a lot.” The reason is that a non-present internal key would reveal at spend time that the spender never had any intention of using a key-path spend, distinguishing their spends from other spends where using a key-path was an option. Towns further notes that not publishing an internal key would only save 8 vbytes.

     Jonas Nick and Jeremy Rubin each provide their own analysis. Nick concludes that “[because] anonymity sets in Bitcoin are permanent and software tends to be deployed longer than anyone would expect […] realistically taproot is superior to [Anon’s proposed] optimization.” Rubin concludes the opposite, favoring either Anon’s proposal or Rubin’s own proposed alternative (which would still result in the same privacy loss).

  5. Anon asks, “Is the development model of trying to jam a bunch of features into Bitcoin all at once good for Bitcoin development?”

     Towns replies that “bundling these particular changes together [gives] the advantages of taproot”—the flexibility to use either key-path or script-path spending, that “key-path comes at no cost compared to not using taproot”, that “adding a script-path comes at no cost if you don’t end up using it,” and that “if you can interactively verify the script conditions off-chain, you can always use the key path”.

  The discussion did not reach an obvious conclusion. If there are any additional notable developments, we’ll report on them in a future newsletter.

• ● Using PoDLE in LN: as described in Newsletter #83, LN developers are working to specify a protocol for the interactive construction of funding transactions as a step towards dual-funded payment channels and channel splicing. One problem for dual-funded channel setup is that someone can propose opening a channel with you, learn one or more of your UTXOs, and then abandon the channel setup process before signing a transaction and paying any fees. A proposed solution to this problem is to require channel open proposals contain a Proof of Discrete Logarithm Equivalence (PoDLE) which JoinMarket uses to avoid the same type of costless UTXO disclosure attacks.

  This week, Lisa Neigut published her analysis of the PoDLE idea for interactive funding. She also separately described an attack where dishonest Mallory waits for honest Alice to submit a PoDLE and then uses that to get other nodes to blacklist Alice. Neigut proposed a mitigation but an alternative more compact mitigation was proposed by JoinMarket developer Adam Gibson. Gibson’s approach requires the PoDLE commit to the node that’s expected to receive it, preventing it from being maliciously reused with other nodes. Gibson also described some of the design decisions that went into JoinMarket’s use of PoDLE and suggested how LN developers might want to use different tradeoffs for LN’s own unique constraints.

• ● Decoy nodes and lightweight rendez-vous routing: Bastien Teinturier previously posted about breaking the link between what data is included in a BOLT11 invoice and the funding transaction of the channel that will receive the payment (see Newsletter #82). After further discussion and refinement, Teinturier noted a side effect of his scheme might enable convenient rendez-vous routing—privacy-enhanced payment routing where neither the receiving node nor the spending node learns anything about each other’s network identity. For more information, see Teinturier’s documentation for the scheme, read about previous discussion of rendez-vous routing in Newsletter #22, and review discussion of the topic in Monday’s LN developer specification meeting.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

• ● BTCPay Vault using HWI for signing: BTCPay Vault is a desktop application that uses HWI to coordinate signing transactions with a variety of hardware wallets. While BTCPay Server created BTCPay Vault, the software can be repurposed for use in other applications.

• ● CKBunker using PSBTs for an HSM: CKBunker allows users to configure rule-based spending conditions for an online, Tor-enabled Coldcard hardware wallet. The Coldcard then functions like an HSM (Hardware Security Module), signing PSBTs delivered via a Tor hidden service.

Notable code and documentation changes

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

• ● Bitcoin Core #18104 ends support for building 32-bit x86 binaries for Linux as part of the Bitcoin Core release process. The corresponding 32-bit binaries for Windows were previously removed several months ago (see Newsletter #46). The 32-bit Linux binaries are still built as part of Bitcoin Core’s continuous integration tests and users may still build them manually, but the binaries are no longer being distributed by the project due to a lack of use and hands-on developer testing.

• ● C-Lightning #3488 standardizes C-Lightning’s requests for Bitcoin data making it possible to run C-Lightning on something other than Bitcoin Core as the backend. This pull request is part of a larger project to allow more freedom for how C-Lightning interacts with the Bitcoin backend as proposed in C-Lightning #3354. Keeping the backend interactions generic allows for plugins to either make standard RPC calls, combine RPCs into more abstract methods, or even create notifications. While bitcoind interaction through bitcoin-cli remains the default, this project works towards opening up possibilities for mobile integration (see C-Lightning #3484) or allowing users to share a block explorer such as an esplora instance for those that might only go online infrequently for channel management and monitoring.

• ● C-Lightning #3500 implements a simple solution to a problem that could cause channels to become stuck with neither party able to send funds to the other. The stuck funds problem occurs when a payment would cause the party who funded the channel to become responsible for paying more value than their current balance. For example, Alice funds a channel and pays Bob her full available balance. Alice now can’t spend any more money (as expected) but Bob also can’t pay Alice because that would require increasing the size of the commitment transaction and its corresponding fees—fees that the funder (Alice) is responsible for paying. This renders the channel unusable in both directions. C-Lightning’s merge simply restricts the user, when they’re the funder, from spending all of their available balance, providing an effective short term fix. An alternative solution is proposed in C-Lightning #3501, but it’s waiting on the outcome of further discussion between the maintainers of all LN implementations.

• ● C-Lightning #3489 allows multiple plugins to attach to the htlc_accepted plugin hook, with plans to allow multiple plugin attachments to other hooks in the future. For the htlc_accepted hook, this allows a plugin to either reject the HTLC, resolve the HTLC (i.e. claim any payment by returning the preimage), or pass the HTLC on to the next plugin bound to the hook.

• ● C-Lightning #3477 allows plugins to register feature flags that will be sent in the node’s BOLT1 init message, the BOLT7 node_announcement message, or the BOLT11 invoice’s feature bits field (field 9). This allows a plugin to signal to other programs that its node can handle the advertised features.

• ● Libsecp256k1 #682 removes the Java Native Interface (JNI) bindings with the reason, “[the] JNI bindings would need way more work to remain useful to Java developers but the maintainers and regular contributors of libsecp are not very familiar with Java.” The PR notes that ACINQ is known to use the bindings in their projects and maintains their own fork of the library.