This week’s newsletter describes a proposed update to BIP340 schnorr keys and signatures, seeks feedback on a proposal to improve startup feature negotiation between full nodes, examines a suggestion for a standardized way to prevent hardware wallets from using corrupt nonces to leak private keys, and links to an analysis of the properties necessary in a hash function for taproot to be secure. Also included are our regular sections for release announcements and notable changes to popular Bitcoin infrastructure projects.

None this week.

● Taproot in the generic group model: Lloyd Fournier published his poster for the Financial Cryptography conference two weeks ago describing what properties must be present in the hash function used with taproot in order for taproot to be secure. This extends a previous proof by Andrew Poelstra which made the broader assumption that the hash function acted as a random oracle . Those evaluating the cryptographic security of taproot are encouraged to review Poelstra’s proof and Fournier’s poster.

● Proposal to standardize an exfiltration resistant nonce protocol: Stepan Snigirev started a discussion on the Bitcoin-Dev mailing list about standardizing a protocol that prevents hardware wallets from using biased nonces to leak users’ private keys. One previously proposed mechanism for defending against this attack would be to use the sign to contract protocol to verify that the signature commits to randomness selected by the hardware wallet’s host computer or mobile device. Developers of libsecp256k1 have already been working on an API to both enable generic sign to contract and build an exfiltration resistant nonce capability on top of it. Snigirev’s email describes the currently preferred protocol and how it can be extended to multiple computers and Partially Signed Bitcoin Transactions ( PSBTs ).

● Improving feature negotiation between full nodes at startup: Suhas Daftuar requested feedback on a proposal to insert a message into the sequence used by nodes to open a connection with a new peer. The new message would make it easier for a node to negotiate what features it wants to receive from its peer. A challenge here is that previous versions of Bitcoin Core would terminate a new connection if certain messages didn’t appear in a particular order—and it’s into this strict sequence that Daftuar wants to insert a new message. The proposal does increment the P2P protocol version to provide backwards compatibility, but Daftuar is seeking feedback from maintainers of full nodes about whether the insertion of negotiation messages would cause any problems. If you’re aware of any problems, please reply to the thread.

New releases and release candidates for popular Bitcoin infrastructure. Please consider upgrading to new releases or helping to test release candidates.

● LND 0.9.1 is a new minor version release that doesn’t contain any new features but which fixes several bugs, including a bug that can result in “erroneous force closes between nodes”.

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

● Bitcoin Core #17985 removes dead code that should’ve relayed transactions from a whitelisted peer even if the transactions would’ve been rejected from the mempool. The feature stopped working in Bitcoin Core 0.13.0, with it being unclear whether that was intentional or by accident.

● Bitcoin Core #17264 changes the default in RPCs that create or process Partially Signed Bitcoin Transactions (PSBTs) to include any known BIP32 HD wallet derivation path. This allows any other wallets that later process the PSBT to use that information to select the appropriate signing key or verify that a change output pays the correct address. Those wanting to keep their derivation paths private may disable sharing using the bip32_derivs parameter.

● C-Lightning #3490 adds a getsharedsecret RPC that will derive a shared secret from the combination of the local node’s private key and a user-specified public key. This shared secret is derived the same way other shared secrets are derived in the LN protocol (SHA256 digest of the ECDH result), which may not be the same way other programs derive shared secrets using elliptic curve cryptography (e.g. for ECIES). This RPC can be useful for plugins that want to encrypt their communication with other LN nodes.

● Eclair #1307 updates the packaging scripts used by Eclair, producing a zip file with everything needed to use the software. This new method allows Eclair GUI to be built deterministically in addition to the core library (which we reported in Newsletter #83). Reproducible builds help users ensure that the software they run is based on the source code that’s been publicly reviewed.

● Libsecp256k1 #710 makes minor changes to the library to help with testing. In one of the changes, a function that could previously return a range of values (contrary to its documented behavior) will now only return either 0 or 1 . At least one other library used the old behavior and a concern was mentioned in the #secp256k1 IRC chatroom that other programs or libraries might also be using the old unadvised behavior. If any of your programs use the secp256k1_ecdh function, consider reviewing the discussion on this PR and in the related rust-secp256k1 issue.