This week’s newsletter describes how BLS signatures could be used to improve DLCs without consensus changes to Bitcoin and includes our regular sections with announcements of new software releases and release candidates, plus summaries of notable changes to popular Bitcoin infrastructure software.

News

  • ● Using Bitcoin-compatible BLS signatures for DLCs: Discreet Log Contracts (DLCs) allow a trusted third party known as an oracle to attest to a piece of data. Individuals who trust that oracle can use that attestation in contracts without revealing to the oracle that a contract exists or what its terms are, among other benefits of DLCs. DLCs were originally proposed to use a feature of schnorr signatures but were later developed to use more generalized signature adaptors.

    This week, Lloyd Fournier posted to the DLC-Dev mailing list about the benefits of having an oracle make their attestation using Boneh–Lynn–Shacham (BLS) signatures. Bitcoin does not support BLS signatures and a soft fork would be required to add them, but Fournier links to a paper he co-authored that describes how information can be securely extracted from a BLS signature and used with Bitcoin-compatible signature adaptors without any changes to Bitcoin.

    Fournier then goes on to describe several benefits of BLS-based attestations. The most significant of these is that it would allow “stateless” oracles where the parties to a contract (but not the oracle) could privately agree on what information they wanted the oracle to attest to, e.g. by specifying a program written in any programming language they knew the oracle would run. They could then allocate their deposit funds according to the contract without even telling the oracle that they were planning to use it. When it came time to settle the contract, each of the parties could run the program themselves and, if they all agreed on the outcome, settle the contract cooperatively without involving the oracle at all. If they didn’t agree, any one of them could send the program to the oracle (perhaps with a small payment for its service) and receive back a BLS attestation to the program source code and the value returned by running it. The attestation could be transformed into signatures that would allow settling the DLC onchain. As with current DLC contracts, the oracle would not know which onchain transactions were based on its BLS signatures. Multiple oracles could be used, including in a threshold configuration (e.g. 5-of-10).

    The post makes a compelling case for the advantages of stateless oracles over existing DLC oracles which need to be aware of the contract at the time the contract is being created. As of this writing, the post had not received replies by other DLC contributors.

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, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • ● Bitcoin Core #23480 updates the output script descriptor language with a rawtr() descriptor for referring to the exposed key in a taproot output in cases where either the key is used without a tweak (not recommended, see BIP341) or when the internal key and scripts aren’t known (which can be unsafe; see the PR comments or the documentation added by this PR for details). Although it’s already possible to refer to the key in those cases using the existing raw() descriptor, which is primarily meant to be used with tools like Bitcoin Core’s scantxoutset RPC for scanning its database of UTXOs, the new rawtr() descriptor makes it easier to use other existing descriptor fields to associate additional information with the taproot output such as key origin information. The key origin information may indicate that an alternative key generation scheme is being used, such as incremental tweaking to create vanity addresses or cooperative tweaking for privacy.

  • ● Bitcoin Core #22751 adds a simulaterawtransaction RPC which accepts an array of unconfirmed transactions and returns how much BTC those transactions will add or subtract from the wallet’s balance.

  • ● Eclair #2273 implements the proposed interactive funding protocol where two LN nodes coordinate more closely to open a new payment channel. Implementing interactive funding moves Eclair closer to support for dual funding which allows funds to be contributed to a new channel by either of the nodes participating in that channel. Additional preparation for dual funding was also merged this week in Eclair #2247.

  • ● Eclair #2361 begins requiring channel updates to include the htlc_maximum_msat field as proposed by BOLTs #996 (see Newsletter #211).

  • ● LND #6810 begins using receiving payments to taproot outputs in almost all of the wallet’s automatically-generated output scripts. In addition, LND #6633 implements support for option_any_segwit (see Newsletter #151), which allows receiving the funds from a mutual close of a channel to a taproot output.

  • ● LND #6816 adds documentation about how to use zero-conf channels.

  • ● BDK #640 updates the get_balance function to return the current balance separated into four categories: an available balance for confirmed outputs, a trusted-pending balance for unconfirmed outputs from the wallet to itself (e.g. change outputs), an untrusted-pending balance for unconfirmed outputs from external wallets, and an immature balance for outputs from coinbase (mining) outputs that haven’t reached the minimum 100 confirmations necessary to become spendable according to Bitcoin’s consensus rules.