This week’s newsletter describes a proposal for providing DNS-based human-readable Bitcoin payment instructions, summarizes a post with thoughts about mempool incentive compatibility, links to a thread discussing the design of Cashu and other ecash systems, briefly looks at continuing discussion about 64-bit arithmetic in Bitcoin scripts (including a specification for a previously proposed opcode), and gives an overview of an improved reproducible ASMap creation process. Also included are our regular sections describing updates to clients and services, new releases and release candidates, and notable changes to popular Bitcoin infrastructure software.

News

  • ● DNS-based human-readable Bitcoin payment instructions: following previous discussions (see Newsletter #278), Matt Corallo posted to Delving Bitcoin a draft BIP that will allow a string like example@example.com to resolve to DNS address such as example.user._bitcoin-payment.example.com, which will return a DNSSEC-signed TXT record containing a BIP21 URI such as bitcoin:bc1qexampleaddress0123456. BIP21 URIs can be extended to support multiple protocols (see the BIP70 payment protocol); for example, the following TXT record could indicate a bech32m address to use as a fallback by simple onchain wallets, a silent payment address to use by onchain wallets that support that protocol, and an LN offer to use by LN-enabled wallets:

    bitcoin:bc1qexampleaddress0123456?sp=sp1qexampleaddressforsilentpayments0123456&b12=lno1qexampleblindedpathforanoffer...

    The specifics of the different supported payment protocols are not defined in the draft BIP. Corallo has two other drafts, one a BOLT and one a BLIP for describing details relevant for LN nodes. The BOLT allows a domain owner to set a wildcard record such as *.user._bitcoin-payment.example.com that will resolve to a BIP21 URI containing the parameter of omlookup (onion message lookup) and a blinded path to a particular LN node. A spender wanting to make an offer to example@example.com will then pass the receiver part (example) to that LN node to allow a multiuser node to correctly handle the payment. The BLIP describes an option for allowing any LN node to securely resolve payment instructions for any other node over the LN communication protocol.

    At the time of writing, most discussion about the proposal could be found on the PR to the BIPs repository. One suggestion was to use an HTTPS solution which might be more accessible to many web developers but would require additional dependencies; Corallo said he will not change this part of the specification, but he did write a small library with a demo website that does all the work for web developers. Another suggestion was to use the existing OpenAlias DNS-based payment address resolution system that is already supported by some Bitcoin software, such as Electrum. A third significantly discussed topic was how addresses should be displayed, e.g. example@example.com, @example@example.com, example$example.com, etc.

  • ● Thinking about mempool incentive compatibility: Suhas Daftuar posted to Delving Bitcoin several insights into the criteria full nodes can use to select which transactions to accept into their mempools, relay to other nodes, and mine for maximal revenue. The post starts from first principles and proceeds to the cutting edge of current research with approachable descriptions that should be accessible to anyone interested in the design of Bitcoin Core’s transaction relay policy. Some of the insights we found most interesting included:

    • ● Pure replace by feerate doesn’t guarantee incentive compatibility: it seems like replacing a transaction paying a lower feerate with a transaction paying a higher feerate ought to be a strict win for miners. Daftuar provides a simple illustrated example of why that’s not always the case. For previous discussion of pure replace by feerate, see Newsletter #288.

    • ● Miners with different hashrates have different priorities: a miner with 1% of total network hashrate who forgoes including a particular transaction in their block templates and manages to find the next block will only have a 1% chance of mining an immediate successor block that could include that transaction. This strongly encourages the small miner to collect as much fee as it can now, even if that means it significantly reduces the amount of fee available to miners of future blocks (including itself, potentially).

      By comparison, a miner with 25% of total network hashrate who forgoes including a transaction in the next block will have a 25% chance of mining an immediate successor block that could include that transaction. This large miner is incentivized to avoid collecting some fees now if doing so is likely to significantly increase the available fees in the future.

      Daftuar gives an example of two conflicting transactions. The smaller transaction pays a higher feerate; the larger transaction pays more absolute fees. If there aren’t many transactions in the mempool near the feerate of the larger transaction, a block containing it would pay its miner more fees than a block containing the smaller (higher feerate) transaction. However, if there are many transactions in the mempool with similar feerates to the large transaction, a miner with a small share of total network hashrate might be motivated to mine the smaller (higher feerate) version to get as much fee now—but a miner with a larger share of total hashrate might be motivated to wait until it’s profitable to mine the larger (lower feerate) version (or until the spender becomes even more tired of waiting and creates an even higher feerate version). The differing incentives of different miners may imply there’s no universal policy for incentive compatibility.

    • ● Finding incentive-compatible behaviors that can’t resist DoS attacks would be useful: Daftuar describes how the Bitcoin Core project tries to implement policy rules that are both incentive compatible and resistant to denial-of-service (DoS) attacks. However, he notes “an interesting and valuable area of research would be to determine if there are incentive-compatible behaviors that would not be DoS-resistant to deploy on the entire network (and characterize them, if they exist). If so, such behaviors could introduce an incentive for users to connect directly to miners, which might be mutually beneficial to those parties but harmful to the decentralization of mining on the network overall. […] Understanding those scenarios may also be helpful to us as we try to design incentive-compatible protocols that are DoS-resistant, so that we know where the boundaries are of what is possible.”

  • ● Cashu and other ecash system design discussion: several weeks ago, developer Thunderbiscuit posted to Delving Bitcoin a description of the blind signature scheme behind the Chaumian ecash system used in Cashu, which denominates balances in satoshis and allows sending and receiving money using Bitcoin and LN. Developers Moonsettler and Zmnscpxj replied this week to talk about some of the constraints of the simple version of blind signing and how alternative protocols might be able to provide additional benefits. The discussion was entirely theoretical but we think it could be interesting to anyone curious about ecash-style systems.

  • ● Continued discussion about 64-bit arithmetic and OP_INOUT_AMOUNT opcode: several developers have continued discussing a potential future soft fork that could add 64-bit arithmetic operations to Bitcoin (see Newsletter #285). Most discussion since our earlier mention has continued to focus on how to encode 64-bit values in scripts, with the main difference being whether to use a format that minimizes onchain data or a format that’s simplest to operate on programmatically. Also discussed was whether to use signed integers or only allow unsigned integers (for those who don’t know, which seems to include a self-proclaimed advanced Bitcoin innovator, signed integers indicate what sign they use (positive sign or negative sign); unsigned integers only allow expressing zero and positive numbers). Additionally considered was whether to allow operating on larger numbers, potentially up to 4,160 bits (which matches the current Bitcoin stack element size limit of 520 bytes).

    This week, Chris Stewart created a new discussion thread for a draft BIP for an opcode originally proposed as part of OP_TAPLEAF_UPDATE_VERIFY (see Newsletter #166). The opcode, OP_INOUT_AMOUNT pushes to the stack the value of the current input (which is the value of the output it is spending) and the value of output in the transaction that has the same index as this input. For example, if the transaction’s first input is worth 4 million sats, the second input is 3 million sats, the first output pays 2 million sats, and the second output pays 1 million sats, then an OP_INOUT_AMOUNT executed as part of evaluating the second input would put on the stack 3_000_000 1_000_000 (encoded, if we understand the draft BIP correctly, as a 64-bit little-endian unsigned integer, e.g. 0xc0c62d0000000000 0x40420f0000000000). If the opcode were added to Bitcoin in a soft fork, it would make it much easier for contracts to verify that the input and output amounts were within the range expected by the contract, e.g. that a user only withdrew from a joinpool the amount to which they were entitled.

  • ● Improved reproducible ASMap creation process: Fabian Jahr posted to Delving Bitcoin about advancements in creating a map of autonomous systems (ASMap) that each control the routing for large parts of the internet. Bitcoin Core currently tries to maintain connections to peers from a diverse collection of subnets of the global namespace so that an attacker will need to obtain IP addresses on each subnet to perform the simplest type of eclipse attack against a node. However, some ISPs and hosting services control IP addresses on multiple subnets, weakening this protection. The ASMap project aims to provide approximate information about which ISPs control which IP addresses directly to Bitcoin Core (see Newsletters #52 and #83). A major challenge faced by this project is allowing multiple contributors to create a map in a reproducible manner, allowing independent verification that its contents were accurate at the time it was created.

    In this week’s post, Jahr describes the tooling and techniques that he says has “found that there is a good chance that within a group of 5 or more the majority of participants will have the same result. […] This process can be initiated by anyone, very similar to a Core PR. Participants that have a matching result could be interpreted as ACKs. If anyone sees something weird in the result or they simply didn’t get a match, they can ask for the raw data to be shared to investigate further.”

    If the process is eventually found acceptable (perhaps with additional refinements), it’s possible future versions of Bitcoin Core could be shipped with ASMaps and the feature enabled by default, improving resistance to eclipse attacks.

Changes to services and client software

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

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, Bitcoin Inquisition, and BINANAs.

  • ● Bitcoin Core #27877 updates Bitcoin Core’s wallet with a new coin selection strategy, CoinGrinder (see Newsletter #283). This strategy is intended to be used when estimated feerates are high compared to their long-term baseline, allowing the wallet to create small transactions now (with the consequence that it may need to create larger transactions at a later time, hopefully when feerates are lower).

  • ● BOLTs #851 adds support for dual funding to the LN specification along with support for the interactive transaction construction protocol. Interactive construction allows two nodes to exchange preferences and UTXO details that allow them to construct a funding transaction together. Dual funding allows a transaction to include inputs from either or both parties. For example, Alice may want to open a channel with Bob. Before this specification change, Alice had to provide all of the funding for the channel. Now, when using an implementation that supports dual funding, Alice can open a channel with Bob where he provides all of the funding or where they each contribute funds to the initial channel state. This can be combined with the experimental liquidity advertisements protocol, which has not yet been added to the specification.