This week’s newsletter describes a proposal to allow retrieval of LN offers using specific DNS addresses similar to lightning addresses. Also included are our regular sections summarizing changes to services and client software, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

  • ● Offers-compatible LN addresses: Bastien Teinturier posted to the Lightning-Dev mailing list about creating email-style addresses for LN users in a way that takes advantage of the features of the offers protocol. For context, a popular lightning address standard exists based on LNURL, which requires operating an always-available HTTP server to associate email-style addresses with LN invoices. Teinturier notes that this creates several problems:

    • Lack of privacy: the server operator likely learns the IP address of the spender and the receiver.

    • Risk of theft: the server operator can man-in-the-middle invoices to steal funds.

    • Infrastructure and dependencies: the server operator must setup DNS and HTTPS hosting, and the spender software must be able to use DNS and HTTPS.

    Teinturier offers three proposed designs based on offers:

    • Linking domains to nodes: a DNS record maps a domain (e.g. example.com) to an LN node identifier. The spender sends an onion message to that node requesting an offer for the ultimate receiver (e.g. alice@example.com). The domain node replies with an offer signed by its node key, allowing the spender to later prove fraud if it provided an offer that wasn’t from Alice. The spender can now use the offer protocol to request an invoice from Alice. The spender can also associate alice@example.com with the offer, so it doesn’t need to contact the domain node for future payments to Alice. Teinturier notes that this design is extremely simple.

    • Certificates in node announcements: the existing mechanism an LN node uses to advertise itself to the network is modified to allow an advertisement to contain an SSL certificate chain proving that (according to a certificate authority) the owner of example.com claimed this particular node is controlled by alice@example.com. Teinturier notes that this would require LN implementations to implement SSL-compatible cryptography.

    • Store offers directly in DNS: a domain may have multiple DNS records that directly store offers for particular addresses. For example, a DNS TXT record, alice._lnaddress.domain.com, includes an offer for Alice. Another record, bob._lnaddress.domain.com includes an offer for Bob. Teinturier notes that this requires the domain owner create one DNS record per user (and update that record if the user needs to change their default offer).

    The email spurred an active discussion. One notable suggestion was possibly allowing both the first and third suggestions to be used (the suggestions for linking domains to nodes and storing offers directly in DNS).

Changes to services and client software

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

  • ● BitMask Wallet 0.6.3 released: BitMask is a web and browser extension-based wallet for Bitcoin, Lightning, RGB, and payjoin.

  • ● Opcode documentation website announced: The https://opcodeexplained.com/ website was recently announced and provides explanations of many of Bitcoin’s opcodes. The effort is ongoing and contributions are welcome.

  • ● Athena Bitcoin adds Lightning support: The Bitcoin ATM operator recently announced support for receiving Lightning payments for cash withdrawals.

  • ● Blixt v0.6.9 released: The v0.6.9 release includes support for simple taproot channels, defaults to bech32m receive addresses, and adds additional zero conf channel support.

  • ● Durabit whitepaper announced: The Durabit whitepaper outlines a protocol using timelocked Bitcoin transactions in conjunction with a chaumian-style mint to incentivize the seeding of large files.

  • ● BitStream whitepaper announced: The BitStream whitepaper and early prototype layout a protocol for the hosting and atomic exchange of digital content for coins using timelocks and merkle trees with verification and fraud proofs. For previous discussion of paid data transfer protocols, see Newsletter #53.

  • ● BitVM proof of concepts: Two proof of concepts building on BitVM were posted including one implementing the BLAKE3 hash function and another that implements SHA256.

  • ● Bitkit adds taproot send support: Bitkit, a mobile Bitcoin and Lightning wallet, added taproot sending support in the v1.0.0-beta.86 release.

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

  • ● Core Lightning #6857 updates the names of several configuration options used for the REST interface to prevent them from conflicting with the c-lightning-rest plugin.

  • ● Eclair #2752 allows data in an offer to reference a node using either its public key or the identity of one of its channels. A public key is the typical way to identify a node, but it uses 33 bytes. A channel can be identified using a BOLT7 short channel identifier (SCID), which only uses 8 bytes. Because channels are shared by two nodes, an additional bit is prepended to the SCID to specifically identify one of the two nodes. Because offers may often be used in size-constrained media, the space savings are significant.