This week’s newsletter describes multiple facets of a discussion about how much future soft forks should increase the expressiveness of Bitcoin’s Script and Tapscript languages and summarizes a proposal to charge for bandwidth used relaying onion messages. Also included are our regular sections with the summary of a Bitcoin Core PR Review Club meeting, announcements of new software releases and RCs, and descriptions of notable changes to popular Bitcoin infrastructure projects.

News

  • ● Limiting Script language expressiveness: on the Bitcoin-Dev mailing list, several sub-discussions were started out of the proposals to add OP_TXHASH or OP_TX opcodes to Script (see Newsletters #185 and #187). Jeremy Rubin had noted that the proposals (possibly in combination with other opcode proposals, like OP_CAT) might allow the creation of recursive covenants—conditions that would need to be fulfilled in every transaction re-spending those bitcoins or any bitcoins merged with it for perpetuity. It was asked whether anyone had concerns about allowing recursive covenants in Bitcoin, with some of the most notable concerns being summarized below:

    • ● Gradual loss of censorship resistance: contributor Shinobi posted a repeat of his concerns previously mentioned in Newsletter #157 about recursive covenants that gave a powerful third party control over subsequent spending of any coins that the entity currently controlled. For example, a government could require (by law) that its populace only accept coins that the government could later seize (as enforced by Bitcoin consensus rules).

      Replies to Shinobi’s post echoed arguments from a year ago about the same gradual loss of censorship resistance also being possible by users switching to an alternative cryptocurrency (altcoin) or sidechain-like construct with the same requirement for third-party control.

    • ● Encouraging unnecessary computation: developer James O’Beirne expressed concern that the addition of too much expressiveness to Bitcoin’s Script or Tapscript languages would encourage the creation of scripts that used more than the minimum number of operations necessary to prove someone authorized to spend a coin had chosen to spend that money. Ideally, any UTXO (coin) can be spent today using a single compact proof that the spend was authorized, such as a 64-byte schnorr signature. Bitcoin already allows more complex scripts to enable the creation of contracts, such as multisignature compacts and protocols like LN, but this capability can be abused to include operations in scripts that aren’t necessary to enforce the terms of a contract. For example, Bitcoin has in the past been at risk of denial-of-service attacks from specially-designed transactions that repeatedly performed operations requiring much CPU or memory. O’Beirne worries increased expressiveness could both create new DoS vectors as well as result in programmers creating unoptimized scripts that use more node resources than necessary.

    • ● Introduction of turing completeness: developer ZmnSCPxj criticized the addition of opcodes that allow the creation of deliberate recursive covenants as also allowing the accidental creation of recursive covenants. Money paid into recursive covenants, whether deliberately or accidentally, would never again be fully fungible with ordinary bitcoins. ZmnSCPxj phrased this concern in context of turing completeness and the halting problem.

    • ● Enablement of drivechains: extending his previous argument about turing completeness, ZmnSCPxj further argues that increased Script language expressiveness would also enable the implementation of drivechains similar in principle to that specified in BIP300, which several Bitcoin developers have argued could lead to either a loss of user funds or a reduction in censorship resistance. Users of a drivechain could lose funds if not enough of the Bitcoin economy chose to run full nodes enforcing the drivechain’s rules—but if a large part of the economy did choose to enforce a drivechain’s rules, all other users wanting to remain in consensus would need to validate all of that drivechain’s data, effectively making the drivechain part of Bitcoin without there ever being an explicit soft fork decision to modify Bitcoin’s rules.

      This particular sub-thread received extended discussion and produced a spin-off thread comparing drivechain security to LN security in the presence of a majority of mining hashrate attempting to steal bitcoins.

  • ● Paying for onion messages: Olaoluwa Osuntokun posted to the Lightning-Dev mailing list this week about adding the ability for nodes to pay for the bandwidth they use sending onion messages. The previously-proposed onion messages protocol allows one node to send a message to another node routed through an LN path without using an HTLC. The main advantage of onion messages over HTLCs for keysend-style messages is that onion messages don’t require temporarily locking up any bitcoins, making them more cost efficient and more flexible (e.g., onion messages can be sent between peers even when they don’t share a channel). However, the lack of direct financial cost in sending onion messages also makes some developers concerned that they’ll be used to relay traffic over LN for free, making it more expensive to operate an LN node and creating an incentive for large numbers of nodes to disable onion message relay. This could become especially problematic if onion messages are used for important communication between nodes, such as proposed for offers.

    Osuntokun suggested that nodes could pre-pay for the onion message bandwidth they wanted to use. For example, if Alice wants to route 10 kB of data to Zed through Bob and Carol, she will first use AMP to pay Bob and Carol for at least 10 kB of bandwidth at the message relay rates advertised by their respective nodes. When paying Bob and Carol, Alice registers a unique session ID with each of them and includes that ID in the encrypted messages she asks them to relay for her. If the amount Alice has paid is sufficient for the bandwidth her messages use, Bob and Carol participate in relaying the messages to Zed.

    Rusty Russell replied with several criticisms, most notably:

    • ● HTLCs are already currently free: the main counterargument against the concern about free onion message relay has always been that it’s already possible to use HTLCs to relay traffic over LN essentially for free.1 It’s unclear, though, whether this will remain the case permanently—many proposals to fix channel jamming attacks suggest charging for the failed HTLCs which can be used to freely route data today.

    • ● Session identifiers reduce privacy: in the previous example, the session identifiers Alice registers with Bob and Carol allow them to know which messages came from the same user. If instead there had been no session ID, they wouldn’t know whether the different messages had all come from the same user or different users all using parts of the same route. Russell noted that he’d considered blinded tokens when working on onion messages, but he was concerned that it “gets complex fast”.

    Russell instead suggested simply rate limiting the number of onion messages a node forwards (with different limits from different categories of 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.

Open p2p connections to nodes that listen on non-default ports is a PR by Vasil Dimov to remove the preferential treatment of port 8333 in the selection of outbound peers. Participants discussed Bitcoin Core’s automatic connection behavior, the benefits of a network with no default port, and rationale for avoiding certain ports.

  • What are the historical reasons for the preferential treatment of the default port 8333?

    This behavior has always existed, but Satoshi’s motivation is not certain. Common folklore suggests that it prevents leverage of the Bitcoin network to DoS a service by gossipping its address, but this is not the actual historical reason. Another rumored explanation is that a default port may help prevent an attacker from dominating a node’s IP address table and, thus, P2P connections using a single IP address and many ports (what we would now call an eclipse attack). ➚

  • What are the benefits of removing the preferential treatment of port 8333 with this PR?

    The initial method for filtering and storing IP addresses of potential peers was not as sophisticated as it is today; we now limit the number of IP addresses we store by the addresses’ netgroups, AS, source peers, and more. We also rate-limit the amount of addresses we process and relay in general. Given these changes to the address manager (‘addrman’) and address relay, the preferential treatment has little impact on the prevention of eclipse and DoS attacks. Additionally, preference for the default port means very few connections are made to nodes listening on non-default ports. It’s also a privacy leak that lets local network administrators detect Bitcoin network traffic trivially - just look for port 8333. In the event that a government wishes to ban Bitcoin, instructing ISPs to log and/or block traffic to a single port is much easier than trying to identify Bitcoin traffic by monitoring data sent and received on all connections. ➚

  • Before this change, automatic connections to peers listening on non-default ports were discouraged, but not impossible. Under what circumstances would a node still connect to such a peer?

    In the automatic connection logic, the node attempts to connect to addresses randomly selected from its address manager. If no connection has been successful after 50 attempts, it will start considering non-default addresses. One participant noted that nodes in the functional tests don’t use default ports either, but it was pointed out that these nodes are connected using manual connections, not automatic outbound connections. ➚

  • After this PR, the default port still plays a role in Bitcoin Core. Where is it still used?

    When a port is not provided, the default is used. This is particularly relevant for DNS seeds, which new nodes use to bootstrap their address manager. Removing the concept of a default port entirely would require finding an alternative, since DNS is designed to resolve domain names to IP addresses, not to provide the addresses and ports of services. ➚

  • What is the reason for allowing callers to pass salts to CServiceHash and then initializing it with CServiceHash(0, 0) in commit d0abce9?

    Nodes announce their own address approximately every 24 hours, and each node gossips rumored addresses to help nodes around the network discover new peers. This code uses the hash of the IP address and current time to randomly pick one or two peers to forward a recently-received address to. However, we don’t want to make it possible to boost the propagation of an address simply by sending it multiple times. Thus, we use the same salt (0, 0) and timestamp granularity of a day. ➚

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

  • ● Bitcoin Core #23542 removes Bitcoin Core’s preference to only connect to peers on the default Bitcoin port (8333 for mainnet). Instead, Bitcoin Core will open connections to peers on any port except for a few dozen ports known to be used by other services. Port 8333 is still the default port Bitcoin Core binds to locally, so only nodes which override the default will advertise that they accept connections on other ports. Some additional information about this change may be found in the Bitcoin Core PR Review Club summary earlier in this newsletter.

  • ● BDK #537 refactors wallet address caching into a public method. Previously, the only way to ensure that a wallet’s internal database had addresses loaded and cached was through an internal function—meaning that an offline wallet had no mechanism to ensure that the database had addresses loaded. This patch enables use cases like offline wallets being used as a multisig signer and validating change addresses. Relatedly, BDK #522 adds an API for internal addresses, which is useful for applications to create a transaction that splits an output into several smaller ones.

Footnotes

  1. When user Alice relays an HTLC-based keysend message to user Zed through routing nodes Bob and Carol, Alice can construct the HTLC with a hash with no known preimage, guaranteeing it will fail and so neither Bob nor Carol will receive any money. The only costs Alice bears for sending such a message are the costs of creating the channel (if she created it) and for later closing it (if she’s responsible for paying those costs)—plus the risk that an attacker will either steal the private key for her LN hot wallet or any of the other data that could compromise her LN channels. For a secure and bug-free node with long-lived channels, these costs should be essentially zero, and so HTLC-based keysend messages can be currently considered to be free. ↩