This week’s newsletter describes a revised proposal for a generic message signing protocol. Also included are our regular sections describing releases, release candidates, and notable changes to popular Bitcoin infrastructure software.

Action items

None this week.

News

• ● Alternative to BIP322 generic signmessage: the existing BIP322 proposes a generic message signing protocol for Bitcoin that would allow signing messages for any Bitcoin address (script) even if it used multisig or advanced features. This includes the ability to sign for all types of bech32 addresses, a feature that has not yet been standardized even several years after the introduction of that type of address and its subsequent widespread adoption (see Newsletter #54).

  This week, BIP322 author Karl-Johan Alm posted to the Bitcoin-Dev mailing list an alternative proposal for message signing that would use a technique called virtual transactions. The first virtual transaction would be deliberately invalid by attempting to spend from a non-existent previous transaction (one whose txid is all zeroes). This first transaction pays the address (script) the user wants to sign for and contains a hash commitment to the desired message. A second transaction spends the output of the first transaction—if the signatures and other data for that spend could be a valid transaction, then the message is considered signed (although the second virtual transaction still can’t be included onchain because it spends from an invalid previous transaction).

  The advantage of using virtual transactions, which were also adopted in the BIP325 specification for signet (see Newsletter #109), is that they may work with existing software that’s configured to sign arbitrary transactions, including those in PSBT format. The revised specification also allows one of the virtual transactions to contain inputs that reference specific UTXOs, allowing users to (arguably) prove control over those funds, similar to BIP127 proof of reserves.

  Alm is seeking feedback on the alternative proposal, including whether or not it should replace BIP322 or be opened as a separate BIP.

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.

• ● LND 0.11.1-beta is the release for a new minor version. Its release notes summarize the changes as “a number of reliability improvements, some macaroon [authentication token] upgrades, and a change to make our version of anchor commitments spec compliant.”

• ● HWI 1.2.0-rc.1 is a release candidate that adds support for a new hardware device and contains multiple bug fixes.

Notable code and documentation changes

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

• ● Bitcoin Core #19898 changes the “unexpected version” warnings in the debug log to be printed only when the validation log category is set, rather than unconditionally. Originally designed to alarm users that miners and users might be coordinating a soft fork activation using BIP9 versionbits, these frequent warnings had become spurious and were both unactionable and a source of unnecessary confusion for users. See Newsletter #36 for more information.

• ● Bitcoin Core #15367 adds a -startupnotify configuration parameter that accepts a shell command to be executed after Bitcoin Core has finished its initialization and is ready to handle enabled interfaces (ZMQ, REST, JSON-RPC, etc). This can be used to directly start programs/daemons dependent on Bitcoin Core’s interfaces, or to notify init systems (e.g. systemd) that dependent programs/daemons can be safely started.

• ● Bitcoin Core #19723 changes the way unknown P2P protocol messages are handled. Previously the node penalized peers who sent unknown messages between their version and verack message; now the node ignores unknown messages during the brief window between when the remote peer establishes a new connection by sending a version message and when the remote node acknowledges receipt of the local peer’s version with a verack message. Unknown messages received from a node after their verack are ignored, like before.

  By ignoring messages before verack, the local node makes it safe for a peer to send special messages identifying any features it supports. If the node recognizes any special messages, it can enable its support for the corresponding features; otherwise, it can just ignore the message. See Newsletter #111 for previous discussion about this proposed method for protocol feature negotiation.

  Correction: this item originally incorrectly stated that Bitcoin Core penalized peers who sent unknown messages after their verack messages. We’ve corrected it to indicate that unknown messages were never specifically penalized, although messages received out of the expected order were penalized. Before this change, that included receiving any message besides version or wtxidrelay before verack. We thank Marco Falke for reporting the error in our description.

• ● Bitcoin Core #19725 updates the getpeerinfo RPC. Its results now return a new connection_type field that indicates the reason the node either opened that connection to an outbound peer or accepted an inbound connection from the peer. The existing addnode field in the RPC output is deprecated (not returned by default); connections manually requested by the user now show up as connection_type: manual.

• ● Bitcoin Core #18309 allows each ZeroMQ configuration parameter to be specified multiple times. If the same parameter is specified more than once, each listed IP address and port will receive notifications. Previously, only the first provided address/port would receive a notification.

• ● Bitcoin Core #19501 updates the sendtoaddress and sendmany RPCs with a new optional verbose parameter that returns what mechanism was used to select the transaction’s feerate—such as whether the user manually selected the feerate, an appropriate feerate was automatically selected, or the configured fallback feerate was used.

• ● Bitcoin Core #20003 results in the program immediately exiting if the -proxy configuration parameter is specified without arguments. Previously, the program would start without a proxy, which could lead to the user thinking they were using a proxy (e.g. for privacy) when they really weren’t.

• ● Bitcoin Core #19991 makes it possible to track incoming connections to a local Tor onion service separately from other connections made by services or proxies run on the same computer. This is done by having Bitcoin Core listen on an additional port (8334), only on localhost, and associate any connections to that port with Tor. The Tor listening port may be changed using the existing -bind configuration parameter and its new =tor flag. This PR doesn’t do anything special with the ability to identify which connections came from Tor (or those that are now more likely to have come from a local service), leaving that to future PRs. Tor onion service operators who upgrade to this new code may want to update their settings as described in the updated documentation.

• ● Eclair #1528 allows plugins (see Newsletter #43) to register new features and message types. The features will be advertised to peers and potential peers, and any messages using registered message types will be routed to the appropriate plugin. Plugins may now also send messages with arbitrary message types.

• ● Eclair #1539 implements a simple measure to try to prevent channel jamming attacks. When a node has two or more open channels to the same peer and it receives a payment to that peer, it now routes the payment by whichever channel has the least amount of remaining bitcoin value. This means attackers will end up jamming low-value channels before high-value channels. This doesn’t eliminate the attack, but it does mean an attacker will need more open channels in order to jam some high-value channels. This PR shared discussion with LND #4646, which implements the same feature in LND.

• ● Eclair #1540 adds a configuration parameter for setting the name of the Bitcoin Core wallet to use. If not set, Eclair will use Bitcoin Core’s default wallet. The configuration documentation warns that the wallet must not be changed while there are open channels.

• ● LND #4389 adds a new psbt wallet subcommand that allows users to create and sign PSBTs. This extends LND’s previous PSBT support that was focused on allowing other wallets to fund a channel open (see Newsletter #92). For details about the new psbt subcommand and examples of it in use, see LND’s updated documentation.