diff --git a/_posts/en/newsletters/2021-03-03-newsletter.md b/_posts/en/newsletters/2021-03-03-newsletter.md new file mode 100644 index 0000000000..1af310bc24 --- /dev/null +++ b/_posts/en/newsletters/2021-03-03-newsletter.md @@ -0,0 +1,158 @@ +--- +title: 'Bitcoin Optech Newsletter #138' +permalink: /en/newsletters/2021/03/03/ +name: 2021-03-03-newsletter +slug: 2021-03-03-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter describes discussion about a desired replacement +for some of the features of the BIP70 payment protocol and summarizes +proposals for a standardized way to exchange fraud proofs for Discreet +Log Contracts (DLCs). Also included are our regular sections describing +new software releases, available release candidates, and notable changes +to popular Bitcoin infrastructure software. + +## News + +- **Discussion about a BIP70 replacement:** Thomas Voegtlin started a + [thread][voegtlin bip70 alt] on the Bitcoin-Dev mailing list about a replacement for + some of the features of the [BIP70][] payment protocol, specifically + the ability to receive a signed payment request. Voegtlin wants to be + able to prove that the address he paid was actually the address + provided to him by the receiver (e.g. an exchange). Charles Hill and + Andrew Kozlik each replied with information about protocols they're + working on. Hill's [scheme][hill scheme] is intended for use with + [LNURL][] but could be repurposed to serve Voegtlin's intended use + case. Kozlik's [scheme][kozlik scheme] is closer in spirit to BIP70 + but drops its use of [X.509 certificates][] and adds features for + exchange-based coin swaps (e.g. trading BTC for an altcoin or + vice-versa). + +- **Fraud proofs in the v0 Discreet Log Contract (DLC) specification:** + Thibaut Le Guilly started a [discussion][le guilly post] on the + DLC-dev mailing list about the [goal][dlcv0 fraud proofs] to include + fraud proofs in the version 0 DLC coordination specification. Two + types of fraud were discussed: + + - *Equivocation:* where an oracle signs for the same event more than + once, producing conflicting results. A proof of equivocation can + be automatically verified by software without third-party trust. + + - *Lying:* where an oracle signs for an outcome that users know is + wrong. This will almost always depend on evidence not available + to the user's contract software, so this type of fraud proof must + be verified manually by the user, who can compare the original + contract to the outcome signed by the oracle. + + Discussion participants seemed to all favor providing an + equivocation proof, although there was some concern that it could be + too much work for the v0 specification. As an intermediate + solution, it was suggested to focus on proofs of lying. When the + format of those proofs has been established, software can then be + updated to take two separate proofs for the same oracle and event + to create a proof of equivocation. + + One concern with proofs of lying was that users could be spammed by + fake proofs, forcing users to either waste their time verifying + false proofs or give up checking fraud proofs altogether. + Counterarguments included being able to get part of the proof from + an onchain transaction (which requires that someone paid an onchain + fee) and also that users could choose where they download fraud + proofs from, preferring to get them from a source that was known for + only propagating accurate information. + +## Notable code and documentation changes + +*Notable changes this week in [Bitcoin Core][bitcoin core repo], +[C-Lightning][c-lightning repo], [Eclair][eclair repo], [LND][lnd repo], +[Rust-Lightning][rust-lightning repo], [libsecp256k1][libsecp256k1 +repo], [Hardware Wallet Interface (HWI)][hwi repo], +[Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], +[Bitcoin Improvement Proposals (BIPs)][bips repo], and [Lightning +BOLTs][bolts repo].* + +- [Bitcoin Core #16546][] introduces a new signer interface, allowing Bitcoin + Core to interact with external hardware signing devices through the + [HWI][topic hwi] or any other application which implements the same interface. + + Bitcoin Core has been able to interface with hardware signers using HWI + [since Bitcoin Core version 0.18][hwi release]. Until this PR, however, [the + process][hwi old process] required use of the command line to transfer + data between Bitcoin Core and HWI. This PR simplifies the user experience + by enabling Bitcoin Core to directly communicate with HWI. The PR includes + [full documentation][hwi new process] on how to use the new signer interface + along with HWI. + + The new signer interface is currently only accessible through RPC methods. A + [draft PR][signer gui] adds support for the signer interface to the GUI, + allowing the use of hardware signers with Bitcoin Core without any use of + the command line. + +- [Rust-Lightning #791][] adds support for polling `BlockSource` interfaces on + startup to sync blocks and headers, with fork detection during sync. + As described in [Newsletter #135][news135 blocksource], BlockSource + allows software to obtain data from sources other than a standard Bitcoin + Core compatible node, allowing redundancy that can help prevent + [eclipse attacks][topic eclipse attacks] or other security problems. + +- [Rust-Lightning #794][] enables support for the [BOLT2][] + `option_shutdown_anysegwit` feature that permits future segwit versions when + initiating shutdown. If `option_shutdown_anysegwit` is negotiated, a channel + party sending a shutdown message to initiate closing may send a scriptpubkey + for payment, provided the script complies with the standard [BIP141][] witness + program form of a *version byte* (a 1-byte push opcode of `OP_1` through + `OP_16`) followed by a *witness program* (a byte vector push of 2 to 40 + bytes). These shutdown scripts are limited to standard forms to avoid + expensive fee-heavy scripts or transactions with oversized scripts not + propagating due to non-standardness. As it became [possible][0.19.0 + segwit] to relay payments to any segwit script in Bitcoin Core + 0.19.0.1 (released November 2019), it's now safe to [include + them][bolts #672] in LN's standard forms. + +- [HWI #413][], [#469][hwi #469], [#463][hwi #463], [#464][hwi #464], + [#471][hwi #471], [#468][hwi #468], and [#466][hwi #466] significantly + update and extend HWI's documentation. Particularly notable changes + include a link to the documentation on [ReadTheDocs.io][hwi rtd], new + and updated [examples][hwi examples], and a new [policy][hwi policy] + that describes the criteria new devices must meet for HWI to consider + supporting them. + +- [Rust Bitcoin #573][] adds a new method + `SigHashType::from_u32_standard` that ensures the provided sighash + byte is one of [standard values][sighash types] that Bitcoin Core will + relay and mine by default. Each signature's sighash byte indicates + what parts of the transaction need to be signed. Bitcoin's consensus + rules dictate that non-standard sighash values are treated as + equivalent to `SIGHASH_ALL`, but the fact that they aren't relayed or + mined by default can theoretically be used to trick software using + offchain commitments into accepting an unenforceable payment. + Developers of such software using Rust-Bitcoin may which to switch to + this new method from the `SigHashType::from_u32` method that accepts + any consensus-valid sighash byte. + +- [BIPs #1069][] updates [BIP8][] to allow for a configurable activation threshold + and to include 90% as a recommendation, down from 95% previously, based on the + most recent [taproot activation discussion][news137 taproot activation]. + +{% include references.md %} +{% include linkers/issues.md issues="16546,573,791,794,413,469,463,464,471,468,466,1069,672" %} +[voegtlin bip70 alt]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018443.html +[lnurl]: https://github.com/fiatjaf/lnurl-rfc +[hill scheme]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018446.html +[kozlik scheme]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018448.html +[le guilly post]: https://mailmanlists.org/pipermail/dlc-dev/2021-February/000020.html +[dlcv0 fraud proofs]: https://github.com/discreetlogcontracts/dlcspecs/blob/master/v0Milestone.md#simple-fraud-proofs-in-progress +[hwi old process]: https://github.com/bitcoin-core/HWI/blob/7b34fc72c5b2c5af216d8b8d5cd2d2c92b6d2457/docs/examples/bitcoin-core-usage.rst +[hwi release]: /en/newsletters/2019/05/07/#basic-hardware-signer-support-through-independent-tool +[hwi new process]: https://github.com/bitcoin/bitcoin/blob/master/doc/external-signer.md +[signer gui]: https://github.com/bitcoin-core/gui/pull/4 +[hwi rtd]: https://hwi.readthedocs.io/en/latest/?badge=latest +[hwi examples]: https://hwi.readthedocs.io/en/latest/examples/index.html +[hwi policy]: https://hwi.readthedocs.io/en/latest/devices/index.html#support-policy +[X.509 certificates]: https://en.wikipedia.org/wiki/X.509 +[sighash types]: https://btcinformation.org/en/developer-guide#signature-hash-types +[news137 taproot activation]: /en/newsletters/2021/02/24/#taproot-activation-discussion +[news135 blocksource]: /en/newsletters/2021/02/10/#rust-lightning-774 +[0.19.0 segwit]: https://bitcoincore.org/en/releases/0.19.0.1/#mempool-and-transaction-relay diff --git a/_topics/en/bip70-payment-protocol.md b/_topics/en/bip70-payment-protocol.md index 7308b47e9d..4ebcce574e 100644 --- a/_topics/en/bip70-payment-protocol.md +++ b/_topics/en/bip70-payment-protocol.md @@ -106,6 +106,9 @@ optech_mentions: - title: "2019 year-in-review: Bitcoin Core BIP70 deprecation and disablement" url: /en/newsletters/2019/12/28/#bip70 + - title: "Mailing list discussion about a BIP70 replacement" + url: /en/newsletters/2021/03/03/#discussion-about-a-bip70-replacement + ## Optional. Same format as "primary_sources" above # see_also: # - title: diff --git a/_topics/en/hwi.md b/_topics/en/hwi.md index f82accd3d2..fc373de606 100644 --- a/_topics/en/hwi.md +++ b/_topics/en/hwi.md @@ -52,6 +52,12 @@ optech_mentions: - title: "HWI #363 adds support for Bitbox02 hardware wallet" url: /en/newsletters/2020/09/09/#hwi-363 + - title: "Significantly updated and extended HWI documentation" + url: /en/newsletters/2021/03/03/#hwi-413 + + - title: "Bitcoin Core #16546 adds external signer interface compatible with HWI" + url: /en/newsletters/2021/03/03/#bitcoin-core-16546 + ## Optional. Same format as "primary_sources" above see_also: - title: Partially-Signed Bitcoin Transactions (PSBTs)