|
| 1 | +--- |
| 2 | +title: "Bitcoin Optech Newsletter #19" |
| 3 | +permalink: /en/newsletters/2018/10/30/ |
| 4 | +name: 2018-10-30-newsletter |
| 5 | +type: newsletter |
| 6 | +layout: newsletter |
| 7 | +lang: en |
| 8 | +--- |
| 9 | +This week's newsletter suggests an update for C-Lightning users, |
| 10 | +describes a discussion about BIP69 deterministic input/output ordering |
| 11 | +on the mailing list, notes public overt ASICBoost support is available |
| 12 | +for miners using Antminer S9, and provides links to resources about both |
| 13 | +Square's open sourced Subzero HSM-based multisig cold storage solution |
| 14 | +and the recent Lightning Network Residency and Hackday in New York City. |
| 15 | +Also included are selected recent Q&A from Bitcoin StackExchange and |
| 16 | +descriptions of notable code changes in popular Bitcoin infrastructure |
| 17 | +projects. |
| 18 | + |
| 19 | +## Action items |
| 20 | + |
| 21 | +- **Update to [C-Lightning 0.6.2][]:** fixes a bug where the node would |
| 22 | + send an excessive number of update announcements to its peers about |
| 23 | + dead channels. |
| 24 | + |
| 25 | +## News |
| 26 | + |
| 27 | +- **[BIP69][] discussion:** this BIP from 2015 adopted by several notable |
| 28 | + wallets specifies an optional method for deterministically ordering |
| 29 | + inputs and outputs within a transaction based on the public contents |
| 30 | + of the transaction. However, other wallets have not adopted it (or |
| 31 | + even rejected it as unsuitable for adoption), leading perhaps to a |
| 32 | + "worst of both worlds" situation where wallets using BIP69 can be |
| 33 | + fairly easily identified and so wallets not using BIP69 may also be |
| 34 | + easier to identify by negation. |
| 35 | + |
| 36 | + In this [thread][bip69 thread] to the Bitcoin-Dev mailing list, Ryan |
| 37 | + Havar suggests that one reason wallet authors like BIP69 is that its |
| 38 | + deterministic ordering makes it easy and fast for their tests to |
| 39 | + ensure that they haven't leaked any information about the source of |
| 40 | + their inputs or the destination of their outputs (e.g. in some old |
| 41 | + wallets, the fist output always went to the recipient and the second |
| 42 | + output was always change---making coin tracking trivial). Havar |
| 43 | + then suggests an alternative deterministic ordering based on private |
| 44 | + information that would be available to the test suite but not |
| 45 | + exposed by production wallets, allowing developers who want to |
| 46 | + thwart block chain analysis---but also have simple and fast |
| 47 | + tests---to migrate away from BIP69. |
| 48 | + |
| 49 | +- **Overt ASICBoost support for S9 miners:** support for this |
| 50 | + efficiency-improving feature was announced by both [Bitmain][bitmain oab] |
| 51 | + and [Braiins][braiins oab] this week. ASICBoost takes advantage of the fact |
| 52 | + that the SHA256 algorithm used in Bitcoin mining first splits the 80 byte block |
| 53 | + header into 64 byte chunks. If a miner can find multiple proposed block |
| 54 | + headers where the first chunk of 64 bytes are different but start of the next |
| 55 | + chunk of 64 bytes are the same, then they can try different combinations of |
| 56 | + the first chunk and second chunk to reduce the total number of hashing |
| 57 | + operations they need to carry out to find a valid block. Early estimates |
| 58 | + indicate an improvement of 10% (or perhaps more) on existing Antminer S9 |
| 59 | + hardware. |
| 60 | + |
| 61 | + The overt form of ASICBoost alters the versionbits field in the |
| 62 | + block header, which can cause programs such as Bitcoin Core to display |
| 63 | + a warning such as "13 of last 100 blocks have unexpected version". |
| 64 | + Some ASICBoost miners have voluntarily restricted their altered |
| 65 | + versionbits range to that defined by [BIP320][], giving future |
| 66 | + programs the option to ignore those bits for upgrade signaling. |
| 67 | + |
| 68 | +- **Open sourced HSM-based multisig cold storage solution:** [Square][] has |
| 69 | + released code and documentation for the cold storage solution they've |
| 70 | + implemented to protect customer deposits, as well as a CLI tool for |
| 71 | + auditing HD wallet balances at arbitrary points in time. Optech has |
| 72 | + not evaluated their solution, but we can recommend interested parties |
| 73 | + read Square's excellent [blog post][subzero blog] and visit the |
| 74 | + repositories for the [Subzero][] cold storage solution and |
| 75 | + [Beancounter][] auditing tool. |
| 76 | + |
| 77 | +- **Lightning Residency and Hackday:** last week [Chaincode Labs][] |
| 78 | + hosted a five-day [Lightning Network Residency][] program to help |
| 79 | + onboard developers to the fledgling protocol. Following this, Fulmo |
| 80 | + organized their fourth [Lightning Network Hackday][] (actually two |
| 81 | + days) also in New York City with a few speeches, many demos, and lots |
| 82 | + of hacking. |
| 83 | + |
| 84 | + Pierre Rochard has written summaries of all the the presentations |
| 85 | + given at the residency program ([day 1][lr1], [day 2][lr2], |
| 86 | + [day 3][lr3], [day 4][lr4]) and videos of the |
| 87 | + presentations are expected to be posted soon. Videos of the |
| 88 | + hackday are available now: [day 1][hd1], [day 2][hd2]. |
| 89 | + |
| 90 | +## Selected Q&A from Bitcoin StackExchange |
| 91 | + |
| 92 | +{% comment %}<!-- https://bitcoin.stackexchange.com/search?tab=votes&q=created%3a1m..%20is%3aanswer -->{% endcomment %} |
| 93 | + |
| 94 | +*[Bitcoin StackExchange][bitcoin.se] is one of the first places Optech |
| 95 | +contributors look for answers to their questions---or when we have a |
| 96 | +few spare moments of time to help answer other people's questions. In |
| 97 | +this monthly feature, we highlight some of the top voted questions and |
| 98 | +answers made since our last update.* |
| 99 | + |
| 100 | +- [Does using pruning make initial node sync faster?][bse 79592] Pruning |
| 101 | + blocks after they've been processed can reduce disk space requirements |
| 102 | + by over 97% at present, but do they also speed up sync? Bitcoin Core |
| 103 | + developer Gregory Maxwell answers. |
| 104 | + |
| 105 | +- [Can someone steal from you by closing their Lightning Network payment |
| 106 | + channel in a certain way?][bse 80399] Several different ways to close |
| 107 | + a Lightning Network payment channel are described, and C-Lightning |
| 108 | + developer Christian Decker explains how a program following the LN |
| 109 | + protocol will protect your money in each case. |
| 110 | + |
| 111 | +- [How much energy does it take to create one block?][bse 79691] |
| 112 | + Nate Eldredge provides a simple formula and set of links to data that |
| 113 | + anyone can use to estimate the average amount of energy it would take |
| 114 | + to generate a block at the current difficulty level. For the present |
| 115 | + difficulty using only Antminer S9s without ASICBoost, an average block |
| 116 | + consumes 841,629 kilowatt hours (kWh). At a common estimate of |
| 117 | + $0.04/kWh, this is about $34,000 of electricity---well below the |
| 118 | + current block subsidy of about $80,000---but using [AJ Towns's recent |
| 119 | + estimate][towns mining estimate] of $0.16/kWh that includes costs |
| 120 | + beyond electricity and attempts to factor in risk premiums, the |
| 121 | + estimated block cost is about $135,000. |
| 122 | + |
| 123 | +## Notable merges |
| 124 | + |
| 125 | +*Notable code changes this week in [Bitcoin Core][core commits], |
| 126 | +[LND][lnd commits], [C-lightning][cl commits], and [libsecp256k1][secp |
| 127 | +commits].* |
| 128 | + |
| 129 | +{% comment %}<!-- no commits to libsecp256k1; one interesting commit |
| 130 | +#448 to C-Lightning, but I'm not confident enough of my understanding of |
| 131 | +it to write a good description, and I doubt non-LN devs care -->{% endcomment %} |
| 132 | + |
| 133 | +{% include linkers/github-log.md |
| 134 | + refname="core commits" |
| 135 | + repo="bitcoin/bitcoin" |
| 136 | + start="5c25409d6851182c5e351720cee36812c229b77a" |
| 137 | + end="f1e2f2a85962c1664e4e55471061af0eaa798d40" |
| 138 | +%} |
| 139 | +{% include linkers/github-log.md |
| 140 | + refname="lnd commits" |
| 141 | + repo="lightningnetwork/lnd" |
| 142 | + start="e5b84cfadab56037ae3957e704b3e570c9368297" |
| 143 | + end="6b19df162a161079ab794162b45e8f4c7bb8beec" |
| 144 | +%} |
| 145 | +{% include linkers/github-log.md |
| 146 | + refname="cl commits" |
| 147 | + repo="ElementsProject/lightning" |
| 148 | + start="7eec2253e962e524f8fd92b74f411f0b99706ba9" |
| 149 | + end="22b8a88b488faa94a009b2c58415ae825152f709" |
| 150 | +%} |
| 151 | +{% include linkers/github-log.md |
| 152 | + refname="secp commits" |
| 153 | + repo="bitcoin-core/secp256k1" |
| 154 | + start="1086fda4c1975d0cad8d3cad96794a64ec12dca4" |
| 155 | + end="1086fda4c1975d0cad8d3cad96794a64ec12dca4" |
| 156 | +%} |
| 157 | + |
| 158 | +- [Bitcoin Core #14451][] allows optionally building Bitcoin-Qt without |
| 159 | + support for the [BIP70][] payment protocol and adds a deprecation |
| 160 | + warning indicating the default support may be removed in a future |
| 161 | + release. The CEO of BitPay, which is the largest user of BIP70 (but |
| 162 | + which wants to use a different version of the protocol), |
| 163 | + [indicated][bitpay bip70 comment] that they supported Bitcoin Core |
| 164 | + removing BIP70. Developers seem to be in favor of removing the |
| 165 | + protocol for security reasons and because it's seeing declining use. |
| 166 | + The BIP70 dependency on OpenSSL resulted in the emergency release of |
| 167 | + [Bitcoin Core 0.9.1][] in 2014 as a result of the [heartbleed |
| 168 | + vulnerability][], and it is expected that removing it will eliminate |
| 169 | + the risk of future similar vulnerabilities. |
| 170 | + |
| 171 | +- [Bitcoin Core #14296][] removes the deprecated `addwitnessaddress` |
| 172 | + RPC. This RPC was added in version 0.13.0 to enable testing segwit |
| 173 | + on regtest and testnet before it was activated on mainnet and built |
| 174 | + into the wallet. Since version 0.16.0, Bitcoin Core's wallet has |
| 175 | + supported getting addresses directly using the regular |
| 176 | + [getnewaddress][rpc getnewaddress] mechanism. |
| 177 | + |
| 178 | +- [Bitcoin Core #14468][] deprecates the `generate` RPC. This method |
| 179 | + generates new blocks in regtest mode but it requires getting new |
| 180 | + addresses from Bitcoin Core's built-in wallet in order to pay them the |
| 181 | + mining [block reward][term block reward]. A replacement method, |
| 182 | + [generatetoaddress][rpc generatetoaddress] was introduced in version |
| 183 | + 0.13.0, which allows any regtest wallet to generate an address that |
| 184 | + will be paid the block reward. This is part of an ongoing effort to |
| 185 | + allow as many RPCs as possible to function without the wallet in order |
| 186 | + to improve test coverage of non-wallet nodes as well as to ease a |
| 187 | + future possible transition to fully separating the wallet from the |
| 188 | + node. |
| 189 | + |
| 190 | +- [Bitcoin Core #14150][] adds [key origin][] support to [output script |
| 191 | + descriptors][]. Besides allowing you to pass an additional argument |
| 192 | + to the [scantxoutset][rpc scantxoutset] RPC, this doesn't currently add any features |
| 193 | + to Bitcoin Core---but it will enable using key origin with [BIP174][] |
| 194 | + PSBTs and watch-only wallets when those parts of the software have |
| 195 | + been updated to use descriptors. See Newsletters [#5][newsletter #5], |
| 196 | + [#7][newsletter #7], [#9][newsletter #9], [#12][newsletter #12], and |
| 197 | + [#17][newsletter #17] for previous discussion of output script |
| 198 | + descriptors. Key origin support makes it possible to use extended |
| 199 | + pubkeys that have been exported from an HD wallet that uses [BIP32][] |
| 200 | + hardened derivation for protecting ancestor private keys, which |
| 201 | + helps make output script descriptors compatible with most hardware |
| 202 | + wallets. |
| 203 | + |
| 204 | +- [LND #1981][] ensures that LND doesn't leak information about any of |
| 205 | + its peers that aren't advertising themselves as public nodes. |
| 206 | + |
| 207 | +- LND [#1535][LND #1535] and [#1512][LND #1512] adds the server-side |
| 208 | + communication protocol for watchtowers along with many tests verifying |
| 209 | + its proper operation. Correct use of the LN protocol requires regular |
| 210 | + monitoring of which transactions get added to the block chain, so |
| 211 | + watchtowers are servers designed to help defend the payment channels |
| 212 | + of users who expect to be offline for an extended period of time. As |
| 213 | + such, watchtowers are considered to be a key feature for enabling |
| 214 | + wider adoption of LN by less advanced users. However, a standard |
| 215 | + specification for watchtowers has not been agreed upon by the multiple |
| 216 | + implementations of LN, so LND is only putting this feature out for |
| 217 | + initial testing and is restricting its use to testnet. |
| 218 | + |
| 219 | +{% include references.md %} |
| 220 | +{% include linkers/issues.md issues="14451,14296,14468,14150,1981,1535,1512" %} |
| 221 | + |
| 222 | +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} |
| 223 | +[bse 79592]: {{bse}}79592 |
| 224 | +[bse 80399]: {{bse}}80399 |
| 225 | +[bse 79691]: {{bse}}79691 |
| 226 | + |
| 227 | +[hd1]: https://www.youtube.com/watch?v=FGxFd944jMg |
| 228 | +[hd2]: https://www.youtube.com/watch?v=o87GVYFvwIk |
| 229 | +[lr1]: https://medium.com/@pierre_rochard/day-1-of-the-chaincode-labs-lightning-residency-ab4c29ce2077 |
| 230 | +[lr2]: https://medium.com/@pierre_rochard/day-2-of-the-chaincode-labs-lightning-residency-669aecab5f16 |
| 231 | +[lr3]: https://medium.com/@pierre_rochard/day-3-of-the-chaincode-labs-lightning-residency-5a7fad88bc62 |
| 232 | +[lr4]: https://medium.com/@pierre_rochard/day-4-of-the-chaincode-labs-lightning-residency-f28b046fc1a6 |
| 233 | +[c-lightning 0.6.2]: https://github.com/ElementsProject/lightning/releases |
| 234 | +[bip69 thread]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-October/016457.html |
| 235 | +[bitmain oab]: https://blog.bitmain.com/en/new-firmware-activate-overt-asicboost-bm1387-antminer-models/ |
| 236 | +[braiins oab]: https://twitter.com/braiins_systems/status/1055153228772503553 |
| 237 | +[subzero blog]: https://medium.com/square-corner-blog/open-sourcing-subzero-ee9e3e071827 |
| 238 | +[subzero]: https://github.com/square/subzero |
| 239 | +[beancounter]: https://github.com/square/beancounter/ |
| 240 | +[lightning network residency]: https://lightningresidency.com/ |
| 241 | +[chaincode labs]: https://chaincode.com/ |
| 242 | +[lightning network hackday]: https://lightninghackday.fulmo.org/ |
| 243 | +[bitpay bip70 comment]: https://github.com/bitcoin/bitcoin/pull/14451#issuecomment-431496319 |
| 244 | +[bitcoin core 0.9.1]: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.9.1.md |
| 245 | +[heartbleed vulnerability]: https://bitcoin.org/en/alert/2014-04-11-heartbleed |
| 246 | +[term block reward]: https://btcinformation.org/en/glossary/block-reward |
| 247 | +[key origin]: https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82#key-origin-identification |
| 248 | +[towns mining estimate]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/playing-with-fire-adjusting-bitcoin-block-subsidy/ |
| 249 | +[square]: https://cash.app/bitcoin |
0 commit comments