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