|
| 1 | +--- |
| 2 | +title: 'Bitcoin Optech Newsletter #67' |
| 3 | +permalink: /en/newsletters/2019/10/09/ |
| 4 | +name: 2019-10-09-newsletter |
| 5 | +slug: 2019-10-09-newsletter |
| 6 | +type: newsletter |
| 7 | +layout: newsletter |
| 8 | +lang: en |
| 9 | +--- |
| 10 | +This week's newsletter requests help testing release candidates for |
| 11 | +Bitcoin Core and LND, tracks continued discussion about the proposed |
| 12 | +noinput and anyprevout sighash flags, and describes several notable |
| 13 | +changes to popular Bitcoin infrastructure projects. |
| 14 | + |
| 15 | +{% comment %}<!-- include references.md below the fold but above any Jekyll/Liquid variables-->{% endcomment %} |
| 16 | +{% include references.md %} |
| 17 | + |
| 18 | +## Action items |
| 19 | + |
| 20 | +- **Help test Bitcoin Core 0.19.0rc1:** production users of Bitcoin Core |
| 21 | + are especially encouraged to test this [latest release candidate][core |
| 22 | + 0.19.0] to ensure that it fulfills all of your organization's needs. |
| 23 | + Experienced users who plan to test are also asked to take a few |
| 24 | + moments to test the GUI and look for problems that might |
| 25 | + disproportionately affect less-experienced users who don't normally |
| 26 | + participate in RC testing. |
| 27 | + |
| 28 | +- **Help test LND 0.8.0-beta-rc2:** experienced users of LND are |
| 29 | + encouraged to [help test][lnd 0.8.0-beta] the next release. For the |
| 30 | + first time ever, this testing can include creating a [reproducible |
| 31 | + build][lnd repo build] of LND and verifying that it has the same hash |
| 32 | + as the binaries distributed by the LND developers. |
| 33 | + |
| 34 | + |
| 35 | +## News |
| 36 | + |
| 37 | +- **Continued discussion about noinput/anyprevout:** this proposed |
| 38 | + sighash flag that would allow LN implementations to use [eltoo][] was |
| 39 | + [discussed][noinput thread] again on the Bitcoin-dev and Lightning-dev mailing lists. |
| 40 | + After summarizing previous discussions, Christian Decker asked several |
| 41 | + questions: is the idea behind the proposal useful? (Respondents seemed |
| 42 | + to agree that it was.) Do people want mandatory chaperon signatures? |
| 43 | + (Respondents seemed moderately opposed.) Do people want mandatory output |
| 44 | + tagging? (Respondents seemed opposed, some strongly.) |
| 45 | + |
| 46 | + In response to the question about output tagging, C-Lightning |
| 47 | + contributor ZmnSCPxj [proposed][zmn internal tagging] an alternative |
| 48 | + tagging mechanism that would put the tag inside the taproot |
| 49 | + commitment, making it invisible unless a script-path spend was used. |
| 50 | + This could allow a spender who was worried about noinput to ensure |
| 51 | + they didn't pay noinput-compatible scripts---the [original goal][orig |
| 52 | + output tagging] behind output tagging---but without the decrease in |
| 53 | + privacy and fungibility created by output tagging. Several people |
| 54 | + seemed to express interest in this idea, although it wasn't clear |
| 55 | + whether they wanted to see it as part of a proposal or they just |
| 56 | + preferred it to external output tagging (which, as noted above, was |
| 57 | + generally opposed by respondents). |
| 58 | + |
| 59 | + The entire thread is more than 20 messages at present and started a |
| 60 | + [spin-off discussion about `OP_CAT`][cat spinoff]. Hopefully the |
| 61 | + discussion will be able to settle the major unresolved issues |
| 62 | + related to noinput and help get this proposal on track for |
| 63 | + inclusion in a subsequent soft fork. |
| 64 | + |
| 65 | +## Notable code and documentation changes |
| 66 | + |
| 67 | +*Notable changes this week in [Bitcoin Core][bitcoin core repo], |
| 68 | +[LND][lnd repo], [C-Lightning][c-lightning repo], [Eclair][eclair repo], |
| 69 | +[libsecp256k1][libsecp256k1 repo], [Bitcoin Improvement Proposals |
| 70 | +(BIPs)][bips repo], and [Lightning BOLTs][bolts repo].* |
| 71 | + |
| 72 | +- [Bitcoin Core #13716][] adds `-stdinrpcpass` and |
| 73 | + `-stdinwalletpassphrase` parameters to |
| 74 | + `bitcoin-cli` that allow it to read either an RPC or wallet |
| 75 | + passphrase from the standard input buffer rather than as a CLI |
| 76 | + parameter that would be stored in shell history. Echoing is also |
| 77 | + disabled on stdin during reading so that the passphrase isn't visible |
| 78 | + to anyone watching your screen. |
| 79 | + |
| 80 | +- [Bitcoin Core #16884][] switches the default address type |
| 81 | + for users of the RPC interface (including via `bitcoin-cli`) from |
| 82 | + P2SH-wrapped P2WPKH to native segwit (bech32) P2WPKH. This change is on the |
| 83 | + master development code branch and is not expected to be released |
| 84 | + until Bitcoin Core 0.20.0 sometime in mid-2020. However, a [previous |
| 85 | + change][gui bech32] expected to be released as part of 0.19.0 in the |
| 86 | + next month or so will switch the default address type for GUI users to |
| 87 | + also use bech32 P2WPKH. |
| 88 | + |
| 89 | +- [Bitcoin Core #16507][] fixes a [rounding issue][bitcoin core #16499] where a |
| 90 | + node would accept transactions into its mempool if they had a |
| 91 | + feerate greater than the node's dynamic minimum feerate but wouldn't |
| 92 | + relay those transactions to peers if the transactions' feerates were |
| 93 | + less than minimum rounded up to next 0.00001000 BTC. |
| 94 | + |
| 95 | +- [LND #3545][] adds code and [documentation][lnd repo doc] that allows |
| 96 | + users to create reproducible builds of LND. This should allow anyone with |
| 97 | + moderate technical skills to build identical binaries to those |
| 98 | + released by Lightning Labs, ensuring that users are running the |
| 99 | + peer-reviewed code from the LND repository and its dependencies. |
| 100 | + |
| 101 | +- [LND #3365][] adds support for using `option_static_remotekey` |
| 102 | + commitment outputs as described [later in this section][opt static |
| 103 | + remotekey]. |
| 104 | + This new commitment protocol is particularly useful when something has |
| 105 | + gone wrong and you've lost data. If that happens, you need only wait |
| 106 | + for your channel counterparty to close the channel by paying a key |
| 107 | + directly derived from your HD wallet. Because the key was generated |
| 108 | + without any additional data ("tweaking"), your wallet doesn't need any |
| 109 | + extra data in order to find and spend your funds. This is a simplified |
| 110 | + alternative to the [data loss protection][] protocol that LND |
| 111 | + previously used and continues to understand. |
| 112 | + |
| 113 | +- [C-Lightning #3078][] adds support for creating and using channels |
| 114 | + that spend Liquid-BTC on the Liquid sidechain. |
| 115 | + |
| 116 | +- [C-Lightning #2803][] adds a new python package named `pyln` that |
| 117 | + includes a partial implementation of the LN specification. As |
| 118 | + described in its [documentation][pyln-proto readme], "This package |
| 119 | + implements some of the Lightning Network protocol in pure python. It |
| 120 | + is intended for protocol testing and some minor tooling only. It is |
| 121 | + not deemed secure enough to handle any amount of real funds (you have |
| 122 | + been warned!)." |
| 123 | + |
| 124 | +- [C-Lightning #3062][] causes the `plugin` command to return an error if a |
| 125 | + requested plugin hasn't reported successful startup within 20 seconds. |
| 126 | + |
| 127 | +- [BOLTs #676][] amends [BOLT2][] to specify that a node should not send |
| 128 | + the `funding_locked` message until it has validated the funding |
| 129 | + transaction. This warns future implementers about the problem that |
| 130 | + lead to the vulnerabilities [described in last week's newsletter][ln |
| 131 | + vuln disclosure]. |
| 132 | + |
| 133 | +- [BOLTs #642][] allows two peers opening a channel to negotiate an |
| 134 | + `option_static_remotekey` flag. If both peers set this flag, any |
| 135 | + commitment transactions they create which they're able to spend |
| 136 | + unilaterally (e.g. to force close the channel) must pay their peer's |
| 137 | + funds to a static address negotiated during the initial channel open. |
| 138 | + For example, if Alice has the address `bc1ally`, Bob has the address |
| 139 | + `bc1bob`, and they both request `option_static_remotekey`, |
| 140 | + any commitment transactions that Alice can publish onchain must pay |
| 141 | + `bc1bob` and any commitment transactions that Bob can publish |
| 142 | + onchain must pay `bc1ally`. If at least one of them doesn't set |
| 143 | + this flag, they'll fall back to the older protocol of using a different |
| 144 | + payout address for each commitment transaction, with the addresses |
| 145 | + created by combining the remote peer's pubkey with a commitment |
| 146 | + identifier. |
| 147 | + |
| 148 | + Always paying the same address allows that address to be a normal |
| 149 | + derivable address in the client's HD wallet, making it possible for |
| 150 | + the user to recover their funds even if they've lost all of their |
| 151 | + state besides their HD seed. This is believed to be superior to the |
| 152 | + [data loss protection][] protocol which depends on storing enough |
| 153 | + state to be able to at least contact the remote peer and identify |
| 154 | + the channel. With `option_static_remotekey`, it can be assumed that |
| 155 | + the remote peer will eventually get tired of waiting for a missing |
| 156 | + peer to show up and will unilaterally close the channel, putting the |
| 157 | + funds onchain in an address where your HD wallet will find them. |
| 158 | + |
| 159 | +{% include linkers/issues.md issues="13716,16884,16507,16499,3545,3365,3078,2803,3062,676,642" %} |
| 160 | +[lnd repo doc]: https://github.com/lightningnetwork/lnd/blob/master/build/release/README.md |
| 161 | +[core 0.19.0]: https://bitcoincore.org/bin/bitcoin-core-0.19.0/ |
| 162 | +[lnd 0.8.0-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.8.0-beta-rc2 |
| 163 | +[lnd repo build]: #lnd-3545 |
| 164 | +[noinput thread]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002176.html |
| 165 | +[cat spinoff]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002201.html |
| 166 | +[ln vuln disclosure]: /en/newsletters/2019/10/02/#full-disclosure-of-fixed-vulnerabilities-affecting-multiple-ln-implementations |
| 167 | +[data loss protection]: /en/newsletters/2019/01/29/#fn:fn-data-loss-protect |
| 168 | +[pyln-proto readme]: https://github.com/ElementsProject/lightning/blob/master/contrib/pyln-proto/README.md |
| 169 | +[opt static remotekey]: #bolts-642 |
| 170 | +[zmn internal tagging]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002180.html |
| 171 | +[gui bech32]: /en/newsletters/2019/04/16/#bitcoin-core-15711 |
| 172 | +[orig output tagging]: /en/newsletters/2019/02/19/#discussion-about-tagging-outputs-to-enable-restricted-features-on-spending |
0 commit comments