● Taproot and tapscript experimentation tool: Karl-Johan Alm posted to the Bitcoin-Dev list about an experimental branch of his btcdeb tool that supports creating and executing taproot and tapscript outputs using a command line tool named tap . For more information, see his detailed tutorial .

● Safety concerns related to precomputed public keys used with schnorr signatures: libsecp256k1 PR #558 proposes adding BIP340-compatible schnorr signature creation and verification to the libsecp256k1 library used by Bitcoin Core and several other Bitcoin programs. Since BIP340 requires signatures to commit to the public key that will be used to validate the signature, the current proposed signature function uses the private key to derive the necessary public key. Gregory Maxwell noted that programs generating signatures will usually already know the appropriate public key, so the function can save CPU time by accepting the public key as a parameter.

Jonas Nick replied that the approach was reasonable, but doing it safely would require including the public key in the data used to create a deterministic nonce. Otherwise, if an attacker could obtain two signatures created by the same private key for two different public keys, and all of the other data remained the same, you would unknowingly be reusing a nonce and the attacker could derive your private key and steal your bitcoins. Discussion about addressing problem would continue in a separate issue.

Additionally, as it became clear that implementations that accept public keys without verifying them could end up producing reused nonces, Gregory Maxwell posted to a mailing list dedicated to ed25519 implementations (which also use a variation of schnorr signatures) about the risk. Ed25519 co-author Daniel Bernstein replied that “the standard defense against faults is for the signer to verify each signature.” This would detect that an invalid public key had been provided, and some wallets such as Bitcoin Core certainly do perform this check for any signatures they generate even for the currently-used ECDSA signature algorithm. However, the computational overhead of this approach may not be acceptable to many applications and there remains a risk that inexperienced developers will not know to perform this step, and so it seems preferable to use Jonas Nick’s suggestion (relayed by Maxwell) of including the public key in the data used to produce a deterministic nonce.

So far, no changes have been made to BIP340 as a direct result of this issue, but proposed changes such as including the public key in the deterministic nonce algorithm are being discussed.