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.

Action items

None this week.

News

• ● Updates to BIP340 schnorr keys and signatures: as previously mentioned in two separate items in Newsletter #84 (1, 2), several updates to BIP340 schnorr signatures have been proposed (which also affect BIP341 taproot). Pieter Wuille suggests changing which variant of a public key should be used with BIP340, with the new selection being based on the evenness of the key. Also, the recommended procedure for generating a nonce has been changed to include the public key in nonce generation, to include independently-generated randomness when available, and to include a step in the nonce generation algorithm that uses the randomness to obfuscate the private key in order to protect the key against differential power analysis.

  Because of the significance of some of these changes, the tag for the tagged hashes in BIP340 is changed, ensuring that any code written for the earlier drafts will generate signatures that fail validation under the proposed revisions. Wuille requests community feedback on the changes.

• ● 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. 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.

  Correction (2020-12-16): the paragraph above was edited to remove an erroneous claim that inserting a message during version negotiation had backwards compatibility issues. The original text is preserved in place as an HTML comment.

• ● 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).

• ● 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.

Releases and release candidates

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”.

• ● Bitcoin Core 0.19.1 (release candidate)

Notable code and documentation changes

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.

• ● BIPs #886 updates BIP340 schnorr signatures with two recommendations: (1) to include entropy in the nonce calculation whenever a random number generator is available, and (2) to verify any signatures produced by the software are valid before distributing them to outside programs, at least whenever the extra computation and delay isn’t burdensome. These two steps help ensure an attacker can’t recover a user’s private key by obtaining invalid signatures with reused nonces; see Newsletter #83 for attack details. For other proposed changes to BIP340, see the news item above in this week’s newsletter.