|
| 1 | +--- |
| 2 | +title: 'Bitcoin Optech Newsletter #6' |
| 3 | +permalink: /en/newsletters/2018/07/31/ |
| 4 | +name: 2018-07-31-newsletter |
| 5 | +type: newsletter |
| 6 | +layout: newsletter |
| 7 | +lang: en |
| 8 | +--- |
| 9 | +This week's newsletter includes the usual dashboard and action items, a |
| 10 | +feature article by developer Anthony Towns about the consolidation of |
| 11 | +four million UTXOs at Xapo, news about possible upgrades to Bitcoin's |
| 12 | +script system, links to a few highly-voted questions and answers on |
| 13 | +the Bitcoin StackExchange, and some notable commits in the development |
| 14 | +branches of the Bitcoin Core, Lightning Network Daemon (LND), and |
| 15 | +C-lightning projects. |
| 16 | + |
| 17 | +## Action items |
| 18 | + |
| 19 | +- **Bitcoin Core 0.16.2 released:** a minor release that brings bug |
| 20 | + fixes and minor improvements. If you use the [abandontransaction][rpc |
| 21 | + abandontransaction] or [verifytxoutproof][rpc verifytxoutproof] RPCs, |
| 22 | + you should particularly consider upgrading. Otherwise, we recommend |
| 23 | + you review the [release notes][bitcoin core 0.16.2] for other changes |
| 24 | + that may affect your operation and upgrade when convenient. |
| 25 | + |
| 26 | +## Dashboard items |
| 27 | + |
| 28 | +- **Fees still low:** hash rate increased difficulty by more than 14% |
| 29 | + in the 2,016-block retarget period ending Sunday, giving an average |
| 30 | + time between blocks of 8 minutes and 41 seconds. This helped to absorb the |
| 31 | + increased transaction load from the past week's price |
| 32 | + speculation. Immediately following a difficulty retarget, the average |
| 33 | + time between blocks is restored to 10 minutes. |
| 34 | + |
| 35 | + As we transition away from the normal weekend transaction lull into the |
| 36 | + new week, there's the possibility for a rapid increase in estimated |
| 37 | + transaction fees. We recommend being careful sending large low-fee |
| 38 | + transactions such as consolidations until closer to the weekend when |
| 39 | + transaction volume begins to taper off again. |
| 40 | + |
| 41 | +## Field Report: Consolidation of 4 Million UTXOs at Xapo |
| 42 | + |
| 43 | +*by [Anthony Towns](https://twitter.com/ajtowns), Developer on Bitcoin Core at [Xapo][]* |
| 44 | + |
| 45 | +{% include articles/towns-xapo-consolidation.md hlevel='###' %} |
| 46 | + |
| 47 | +## News |
| 48 | + |
| 49 | +- **"Improvements in the Bitcoin Scripting Language" by Pieter |
| 50 | + Wuille:** a talk last week giving a high-level overview of several |
| 51 | + possible near-term improvements to Bitcoin. We highly recommend |
| 52 | + watching the [video][sfdev video], viewing the [slides][sipa slides], |
| 53 | + or reading the [transcript][kanzure transcript] (with references) by |
| 54 | + Bryan Bishop---but if you're too busy, here's Wuille's conclusion: "my |
| 55 | + initial focus here is Schnorr signatures and taproot. The reason for |
| 56 | + this focus is that the ability to make any input and output in the |
| 57 | + cooperative case look identical is an enormous win for how script |
| 58 | + execution works. |
| 59 | + |
| 60 | + "Schnorr is necessary for this because without it we cannot encode |
| 61 | + multiple parties into a single key. Having multiple branches in |
| 62 | + there is a relatively simple change. |
| 63 | + |
| 64 | + "If you look at the consensus changes necessary for these things, |
| 65 | + it's really remarkably small, dozens of lines of code. It looks like |
| 66 | + a lot of the complexity is in explaining why these things are useful |
| 67 | + and how to use them and not so much in the impact on the consensus |
| 68 | + rules. |
| 69 | + |
| 70 | + "Things like aggregation, I think, are something that can be |
| 71 | + done after we have explored various options for structural |
| 72 | + improvements to the scripting language, once it's clear around what |
| 73 | + the structuring should be, because we will probably learn from the |
| 74 | + deployments how these things get used in practice. That's what I'm |
| 75 | + working on with a number of collaborators and we'll hopefully be |
| 76 | + proposing something soon, and that's the end of my talk." |
| 77 | + |
| 78 | +[sfdev video]: https://www.youtube.com/watch?v=YSUVRj8iznU |
| 79 | +[sipa slides]: https://prezi.com/view/YkJwE7LYJzAzJw9g1bWV/ |
| 80 | +[kanzure transcript]: http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2018-07-09-taproot-schnorr-signatures-and-sighash-noinput-oh-my/ |
| 81 | + |
| 82 | +## Selected Q&A from Bitcoin StackExchange |
| 83 | + |
| 84 | +{% comment %}<!-- |
| 85 | +https://bitcoin.stackexchange.com/search?tab=votes&q=created%3a1m..%20is%3aanswer |
| 86 | +-->{% endcomment %} |
| 87 | + |
| 88 | +*[Bitcoin StackExachange][bitcoin.se] is one of the first places Optech |
| 89 | +contributors look for answers to their questions---or when we have a |
| 90 | +few spare moments of time to help answer other people's questions. In |
| 91 | +this new monthly feature, we highlight some of the top voted questions |
| 92 | +and answers made there in the past month.* |
| 93 | + |
| 94 | +- [Schnorr versus ECDSA][bse 77235]: in this answer, Bitcoin protocol |
| 95 | + developer Pieter Wuille explains some of the chief advantages of the |
| 96 | + Schnorr signature scheme over Bitcoin's current ECDSA signature |
| 97 | + scheme. |
| 98 | + |
| 99 | +- [Why does HD key derivation stop working after a certain index in |
| 100 | + BIP44 wallets?][bse 76998]: a developer testing his wallet finds that |
| 101 | + a payment sent to low-numbered key indexes works as expected, but |
| 102 | + payments sent to high-numbered indexes never appear in his wallets. |
| 103 | + An answer from Viktor T. reveals why. |
| 104 | + |
| 105 | +- [The maximum size of a Bitcoin DER-encoded signature is...][bse |
| 106 | + 77191]: in this answer, Pieter Wuille provides the math for calculating |
| 107 | + the size of a Bitcoin signature. As mentioned in [Newsletter #3][], |
| 108 | + the maximum size using a regular wallet is 72 bytes---but Wuille |
| 109 | + explains how you can create a non-standard transaction with a 73 byte |
| 110 | + signature and why you might think you saw a signature that was 74 or |
| 111 | + even 75 bytes. |
| 112 | + |
| 113 | +- [If you can use almost any opcode in P2SH, why can't you use them in |
| 114 | + scriptPubKeys?][bse 76541]: in this answer, Bitcoin technical writer |
| 115 | + David A. Harding explains why early versions of Bitcoin restricted the |
| 116 | + types of transactions that could be sent to "standard transactions" |
| 117 | + and why most of those restrictions are still in place even though |
| 118 | + almost all opcodes are available for standard use now via P2SH and |
| 119 | + segwit P2WSH. |
| 120 | + |
| 121 | +## Notable commits |
| 122 | + |
| 123 | +*A quick look at recent merges and commits made in various open source |
| 124 | +Bitcoin projects.* |
| 125 | + |
| 126 | +{% comment %} |
| 127 | +bitcoin: git log --merges 07ce278455757fb46dab95fb9b97a3f6b1b84faf..ef4fac0ea5b4891f4529e4b59dfd1f7aeb3009b5 |
| 128 | +lnd: git log --topo-order -p 271db7d06da3edf696e22109ce0277eaff11cc5e..92b0b10dc75de87be3a9f895c8dfc5a84a2aec7a |
| 129 | +c-lightning: git log --topo-order -p d84d358562a3bcdf48856fdea24511907ff53fd9..0b597f671aa31c1c56d32a554fcdf089646fc7c1 |
| 130 | +{% endcomment %} |
| 131 | + |
| 132 | +- [Bitcoin Core #12257][#12257]: if you start Bitcoin Core with the |
| 133 | + optional flag `-avoidpartialspends`, the wallet will by default spend |
| 134 | + all outputs received to the same address whenever any one of them |
| 135 | + would be spent. This prevents two outputs to the same address from being spent |
| 136 | + in separate transactions, which is a common way address reuse reduces |
| 137 | + privacy. The downside is that it may make transactions larger than |
| 138 | + the smallest they need to be. Bitcoin businesses using Bitcoin Core's |
| 139 | + built-in wallet who don't need the extra privacy may still want to |
| 140 | + toggle this flag on when fees are low for automatic consolidation of |
| 141 | + related inputs. |
| 142 | + |
| 143 | +- [LND #1617][]: updates estimates for the size of on-chain |
| 144 | + transactions to prevent transactions from accidentally paying too low |
| 145 | + of a fee and getting stuck. [This commit][lnd |
| 146 | + ee2f2573c1b1b33288d05ba59a1e8ef9e8fb621c] may be interesting for |
| 147 | + anyone wondering about the size of the transactions (and parts of |
| 148 | + transactions) produced in the current protocol. |
| 149 | + |
| 150 | +- [LND #1531][]: the daemon no longer looks for spends in the memory |
| 151 | + pool---it waits for them to be a confirmed part of a block first. |
| 152 | + This allows the same code to work on full nodes like Bitcoin Core and |
| 153 | + btcd as well as on [BIP157][]-based lightweight clients that don't have |
| 154 | + access to unconfirmed transactions. This is part of the ongoing effort |
| 155 | + to help people without full nodes use LN. |
| 156 | + |
| 157 | +- In several commits, [C-lightning][] developers have mostly completed |
| 158 | + the transition from handling peer-related functions in `gossipd` to |
| 159 | + handling them in `channeld` or `connectd` as appropriate. |
| 160 | + |
| 161 | +- C-lightning has improved its secret handling so that secrets and |
| 162 | + signatures are always generated and stored by a separate daemon than the |
| 163 | + parts of the system directly connected to the network. |
| 164 | + |
| 165 | +{% include references.md %} |
| 166 | +{% include link-to-issues.md issues="12257" %} |
| 167 | + |
| 168 | +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} |
| 169 | +[bse 77235]: {{bse}}77235 |
| 170 | +[bse 76998]: {{bse}}76998 |
| 171 | +[bse 77191]: {{bse}}77191 |
| 172 | +[bse 76541]: {{bse}}76541 |
| 173 | + |
| 174 | +{% assign lnd = "https://github.com/lightningnetwork/lnd/pull/" %} |
| 175 | +[lnd #1617]: {{lnd}}1617 |
| 176 | +[lnd #1531]: {{lnd}}1531 |
| 177 | +[lnd ee2f2573c1b1b33288d05ba59a1e8ef9e8fb621c]: https://github.com/lightningnetwork/lnd/commit/ee2f2573c1b1b33288d05ba59a1e8ef9e8fb621c |
0 commit comments