|
| 1 | +--- |
| 2 | +title: 'Bitcoin Optech Newsletter #35' |
| 3 | +permalink: /en/newsletters/2019/02/26/ |
| 4 | +name: 2019-02-26-newsletter |
| 5 | +type: newsletter |
| 6 | +layout: newsletter |
| 7 | +lang: en |
| 8 | +--- |
| 9 | +This week's newsletter describes the availability of a libsecp256k1 fork |
| 10 | +implementing BIP-Schnorr compatible signatures, lists popular questions |
| 11 | +and answers for February from the Bitcoin StackExchange, and describes |
| 12 | +notable merges in popular Bitcoin infrastructure projects. |
| 13 | + |
| 14 | +## Action items |
| 15 | + |
| 16 | +None this week. |
| 17 | + |
| 18 | +## News |
| 19 | + |
| 20 | +- **Schnorr-ready fork of libsecp256k1 available:** Blockstream |
| 21 | + cryptographer Andrew Poelstra [announced][schnorr libsecp256k1-zkp] |
| 22 | + that the [libsecp256k1-zkp][] library used in [Elements Project][] |
| 23 | + based sidechains (such as [Liquid][]) now supports [BIP-Schnorr][] |
| 24 | + compatible signatures in a variety of configurations: |
| 25 | + |
| 26 | + - Basic single pubkeys and signatures. These are almost identical |
| 27 | + in use to those with Bitcoin's current ECDSA algorithm, although |
| 28 | + signatures are serialized to use about eight fewer bytes and can |
| 29 | + be efficiently verified in batches. |
| 30 | + |
| 31 | + - [MuSig][] for multiparty signatures. Onchain, these look |
| 32 | + identical to single pubkeys and signatures but the public keys and |
| 33 | + signatures are generated by a set of tools that each bring their |
| 34 | + own private keys and cooperate in a multi-step protocol. Whereas |
| 35 | + multisig using current Bitcoin Script requires up to *n* pubkeys |
| 36 | + and signatures for k-of-n multisig security, MuSig can provide the |
| 37 | + same security using just one public key and one signature---reducing |
| 38 | + block chain space, improving verification efficiency, increasing |
| 39 | + privacy, and allowing much larger sets of signers than supported |
| 40 | + by Bitcoin Script's current byte-size and signature-operation |
| 41 | + limits. However, the multi-step protocol requires especially |
| 42 | + careful management of secret nonces; Poelstra's post details |
| 43 | + how libsecp256k1-zkp attempts to minimize the risk of |
| 44 | + nonce-related failures and teases the possibility of even better |
| 45 | + solutions in the future. |
| 46 | + |
| 47 | + - Adapter signatures for scriptless scripts. Using a multi-step |
| 48 | + protocol, Alice can prove to Bob that her final signature for |
| 49 | + spending a certain payment will reveal to him a value that will |
| 50 | + satisfy some specified condition. For example, that value could |
| 51 | + be another signature that will allow Bob himself to claim a |
| 52 | + certain other payment, such as an atomic swap or an LN payment |
| 53 | + commitment. To everyone besides Alice and Bob, the signature is |
| 54 | + just another valid signature with no special meaning. This can |
| 55 | + often improve the privacy and efficiency of the onchain parts of |
| 56 | + protocols by removing the need for including special data onchain, |
| 57 | + such as the current use of hashes and hashlocks in atomic swaps |
| 58 | + and LN payment commitments. |
| 59 | + |
| 60 | + The updated library doesn't make the features available on |
| 61 | + sidechains by itself, but it does provide the code upon which both |
| 62 | + signature generation and verification can be performed---allowing |
| 63 | + developers to build the tools necessary to put Schnorr-based systems |
| 64 | + into production. It is hoped that the code will receive additional |
| 65 | + review and be ported into the upstream [libsecp256k1][] library for |
| 66 | + eventual use in Bitcoin Core related to a soft fork proposal. To |
| 67 | + learn more, read the [blog post][schnorr libsecp256k1-zkp] or |
| 68 | + [developer documentation][schnorr docs]. |
| 69 | + |
| 70 | +## Selected Q&A from Bitcoin StackExchange |
| 71 | + |
| 72 | +{% comment %}<!-- https://bitcoin.stackexchange.com/search?tab=votes&q=created%3a1m..%20is%3aanswer -->{% endcomment %} |
| 73 | +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} |
| 74 | + |
| 75 | +- [Why does BIP44 have internal and external addresses?]({{bse}}84594) |
| 76 | + External addresses are those you give to other people so that they can |
| 77 | + pay you; internal addresses are those you include in your own |
| 78 | + transactions for receiving change. Pieter Wuille explains that |
| 79 | + [BIP32][], upon which [BIP44][] is based, encourages using separate |
| 80 | + derivation paths for these keys in case you need to prove to an |
| 81 | + auditor how much money you've received but not how much money you've |
| 82 | + spent (or have left). By giving the auditor the extended public key |
| 83 | + (xpub) for just the external addresses, he can track your received |
| 84 | + payments but still not receive any direct information about your |
| 85 | + spending or current balance via the change addresses. |
| 86 | + |
| 87 | +- [Taproot and scriptless scripts both use Schnorr, but how are they |
| 88 | + different?]({{bse}}84086) In separate answers, Gregory Maxwell and |
| 89 | + Andrew Chow each describe the differences between these two proposed |
| 90 | + uses of Schnorr-based signatures. Also includes a description of |
| 91 | + adapter signatures, which can be used to enhance the efficiency and |
| 92 | + privacy of trustless contract protocols. |
| 93 | + |
| 94 | +- [How much of block propagation time is used in verification?]({{bse}}84045) |
| 95 | + Gregory Maxwell explains that it's probably closer to 0% than 1% for |
| 96 | + the normal case, but that it can be much larger for a worst case block |
| 97 | + that was specifically constructed to take a long time to verify. |
| 98 | + |
| 99 | +## Notable code and documentation changes |
| 100 | + |
| 101 | +*Notable changes this week in [Bitcoin Core][bitcoin core repo], |
| 102 | +[LND][lnd repo], [C-Lightning][c-lightning repo], [Eclair][eclair repo], |
| 103 | +[libsecp256k1][libsecp256k1 repo], and [Bitcoin Improvement Proposals |
| 104 | +(BIPs)][bips repo].* |
| 105 | + |
| 106 | +- [Bitcoin Core #15348][] adds a [productivity hints][] document |
| 107 | + describing tools and techniques developers have found to improve their |
| 108 | + efficiency. Although some are specific to Bitcoin Core and C++ |
| 109 | + development, others more generally apply to anyone who develops with |
| 110 | + git or GitHub. |
| 111 | + |
| 112 | +- [LND #2419][] creates a time-based buffer for certain objects stored |
| 113 | + in memory that allows them to be freed after a certain period of |
| 114 | + non-use. Previously, some unused objects were being kept in memory |
| 115 | + indefinitely, leading to user-reported crashes when the program |
| 116 | + exceeded the system's free memory. |
| 117 | + |
| 118 | +- [C-Lightning #2343][] provides the project's existing documentation in |
| 119 | + a nicer format at [ReadTheDocs.io][cl rtd]. |
| 120 | + |
| 121 | +- [C-Lightning #2353][], [#2360][C-Lightning #2360], and |
| 122 | + [#2365][C-Lightning #2365] updates various RPCs to now accept values |
| 123 | + suffixed with "btc", "sat", or "msat" to indicate the denomination of |
| 124 | + the value. The "btc" value allows up to 11 decimal places and the |
| 125 | + "sat" value up to 3 decimal places but, in both cases, the last three |
| 126 | + of these places must be zeroes for onchain operations where the extra |
| 127 | + precision isn't supported by the Bitcoin protocol. Other RPCs return |
| 128 | + new fields ending in `_msat` that always contain the millisatoshi |
| 129 | + value. Several internal API changes are also made. |
| 130 | + |
| 131 | +- [C-Lightning #2380][] requires transactions have at least one |
| 132 | + confirmation before the wallet will attempt to spend their bitcoins by |
| 133 | + default. This fixes a problem where the wallet would attempt to spend |
| 134 | + its own unconfirmed change outputs but those payments would sometimes |
| 135 | + get stuck because the earlier payments weren't confirming quickly. |
| 136 | + Several RPCs related to payments receive a `minconf` parameter that |
| 137 | + defaults to `1` but can be set to `0` to continue the old behavior or |
| 138 | + set to a higher value if desired. |
| 139 | + |
| 140 | +- [Eclair #821][] adds more than a dozen heuristics used to help find |
| 141 | + the optimal route over which to send a payment. |
| 142 | + |
| 143 | +{% include references.md %} |
| 144 | +{% include linkers/issues.md issues="15348,2419,2343,2353,2360,2365,2380,821" %} |
| 145 | +[schnorr libsecp256k1-zkp]: https://blockstream.com/2019/02/18/musig-a-new-multisignature-standard/ |
| 146 | +[libsecp256k1-zkp]: https://github.com/ElementsProject/secp256k1-zkp |
| 147 | +[cl rtd]: https://lightning.readthedocs.io/ |
| 148 | +[elements project]: https://elementsproject.org/ |
| 149 | +[liquid]: https://blockstream.com/liquid/ |
| 150 | +[schnorr docs]: https://github.com/ElementsProject/secp256k1-zkp/blob/secp256k1-zkp/src/modules/musig/musig.md |
| 151 | +[productivity hints]: https://github.com/bitcoin/bitcoin/blob/master/doc/productivity.md |
| 152 | + |
0 commit comments