This week’s newsletter describes the availability of a libsecp256k1 fork implementing BIP-Schnorr compatible signatures, lists popular questions and answers for February from the Bitcoin StackExchange, and describes notable merges in popular Bitcoin infrastructure projects.

Action items

None this week.

News

• Schnorr-ready fork of libsecp256k1 available: Blockstream cryptographer Andrew Poelstra announced that the libsecp256k1-zkp library used in Elements Project based sidechains (such as Liquid) now supports BIP-Schnorr compatible signatures in a variety of configurations:

  • Basic single pubkeys and signatures. These are almost identical in use to those with Bitcoin’s current ECDSA algorithm, although signatures are serialized to use about eight fewer bytes and can be efficiently verified in batches.

  • MuSig for multiparty signatures. Onchain, these look identical to single pubkeys and signatures but the public keys and signatures are generated by a set of private keys using a multi-step protocol. Whereas multisig using current Bitcoin Script requires n pubkeys and k signatures for k-of-n multisig security, MuSig can provide the same security using just one public key and one signature—reducing block chain space, improving verification efficiency, increasing privacy, and allowing much larger sets of signers than supported by Bitcoin Script’s current byte-size and signature-operation limits. But it does have two downsides: the increase in privacy also destroys provable accountability—there’s no way to know which particular authorized signers were part of the subset that created a signature—and the multi-step protocol requires especially careful management of secret nonces to avoid accidentally revealing private keys. Addressing the second issue, Poelstra’s post details how libsecp256k1-zkp attempts to minimize the risk of nonce-related failures and teases the possibility of even better solutions in the future.

  • Adapter signatures for scriptless scripts. Using a multi-step protocol, Alice can prove to Bob that her final signature for spending a certain payment will reveal to him a value that will satisfy some specified condition. For example, that value could be another signature that will allow Bob himself to claim a certain other payment, such as an atomic swap or an LN payment commitment. To everyone besides Alice and Bob, the signature is just another valid signature with no special meaning. This can often improve the privacy and efficiency of the onchain parts of protocols by removing the need for including special data onchain, such as the current use of hashes and hashlocks in atomic swaps and LN payment commitments.

  The updated library doesn’t make the features available on sidechains by itself, but it does provide the code upon which both signature generation and verification can be performed—allowing developers to build the tools necessary to put Schnorr-based systems into production. It is hoped that the code will receive additional review and be ported into the upstream libsecp256k1 library for eventual use in Bitcoin Core related to a soft fork proposal. To learn more, read the blog post or developer documentation.

Selected Q&A from Bitcoin StackExchange

Bitcoin StackExchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments of time to help curious or confused users. In this monthly feature, we highlight some of the top voted questions and answers made since our last update.

• Why does BIP44 have internal and external addresses? External addresses are those you give to other people so that they can pay you; internal addresses are those you include in your own transactions for receiving change. Pieter Wuille explains that BIP32, upon which BIP44 is based, encourages using separate derivation paths for these keys in case you need to prove to an auditor how much money you’ve received but not how much money you’ve spent (or have left). By giving the auditor the extended public key (xpub) for just the external addresses, he can track your received payments but still not receive any direct information about your spending or current balance via the change addresses.

• Taproot and scriptless scripts both use Schnorr, but how are they different? In separate answers, Gregory Maxwell and Andrew Chow each describe the differences between these two proposed uses of Schnorr-based signatures. Also includes a description of adapter signatures, which can be used to enhance the efficiency and privacy of trustless contract protocols.

• How much of block propagation time is used in verification? Gregory Maxwell explains that it’s probably closer to 0% than 1% for the normal case, but that it can be much larger for a worst case block that was specifically constructed to take a long time to verify.

Notable code and documentation changes

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

• Bitcoin Core #15348 adds a productivity hints document describing tools and techniques developers have found to improve their efficiency. Although some are specific to Bitcoin Core and C++ development, others more generally apply to anyone who develops with git or GitHub.

• C-Lightning #2343 provides the project’s existing documentation in a nicer format at ReadTheDocs.io.

• C-Lightning #2353, #2360, and #2365 updates various RPCs to now accept values suffixed with “btc”, “sat”, or “msat” to indicate the denomination of the value. The “btc” value allows up to 11 decimal places and the “sat” value up to 3 decimal places but, in both cases, the last three of these places must be zeroes for onchain operations where the extra precision isn’t supported by the Bitcoin protocol. Other RPCs return new fields ending in _msat that always contain the millisatoshi value. Several internal API changes are also made.

• C-Lightning #2380 requires transactions have at least one confirmation before the wallet will attempt to spend their bitcoins by default. This fixes a problem where the wallet would attempt to spend its own unconfirmed change outputs but those payments would sometimes get stuck because the earlier payments weren’t confirming quickly. Several RPCs related to payments receive a minconf parameter that defaults to 1 but can be set to 0 to continue the old behavior or set to a higher value if desired.

• Eclair #821 improves the heuristics used to help find a good route over which to send a payment.