From dcdbe475bb870a77f9245cd09cc1296b574ff434 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Sun, 28 Feb 2021 17:55:05 -1000 Subject: [PATCH 1/5] Newsletters: add 138 (2021-03-03) --- .../en/newsletters/2021-03-03-newsletter.md | 117 ++++++++++++++++++ _topics/en/bip70-payment-protocol.md | 3 + _topics/en/hwi.md | 3 + 3 files changed, 123 insertions(+) create mode 100644 _posts/en/newsletters/2021-03-03-newsletter.md 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..c0309a5fe2 --- /dev/null +++ b/_posts/en/newsletters/2021-03-03-newsletter.md @@ -0,0 +1,117 @@ +--- +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][] External signer support - Wallet Box edition FIXME:jnewbery + +- [Rust-Lightning #791][] SPV client utility for syncing a lightning node FIXME:dongcarl + +- [Rust-Lightning #794][] Add support for `opt_shutdown_anysegwit` feature #780 FIXME:jonatack + +- [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][] BIP 8: Reduce threshold recommendation to 90% FIXME:bitschmidty or harding + +{% include references.md %} +{% include linkers/issues.md issues="16546,573,791,794,413,469,463,464,471,468,466,1069" %} +[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 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 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..add29d2ddd 100644 --- a/_topics/en/hwi.md +++ b/_topics/en/hwi.md @@ -52,6 +52,9 @@ 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 + ## Optional. Same format as "primary_sources" above see_also: - title: Partially-Signed Bitcoin Transactions (PSBTs) From 87bc079b3828e9e5b0dc2784148d911e3788ed02 Mon Sep 17 00:00:00 2001 From: John Newbery Date: Mon, 1 Mar 2021 12:04:47 +0000 Subject: [PATCH 2/5] news138: Add Bitcoin Core n16546 --- .../en/newsletters/2021-03-03-newsletter.md | 21 ++++++++++++++++++- _topics/en/hwi.md | 3 +++ 2 files changed, 23 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2021-03-03-newsletter.md b/_posts/en/newsletters/2021-03-03-newsletter.md index c0309a5fe2..d4beb26d32 100644 --- a/_posts/en/newsletters/2021-03-03-newsletter.md +++ b/_posts/en/newsletters/2021-03-03-newsletter.md @@ -73,7 +73,22 @@ repo], [Hardware Wallet Interface (HWI)][hwi repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], and [Lightning BOLTs][bolts repo].* -- [Bitcoin Core #16546][] External signer support - Wallet Box edition FIXME:jnewbery +- [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][] SPV client utility for syncing a lightning node FIXME:dongcarl @@ -110,6 +125,10 @@ BOLTs][bolts repo].* [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 diff --git a/_topics/en/hwi.md b/_topics/en/hwi.md index add29d2ddd..fc373de606 100644 --- a/_topics/en/hwi.md +++ b/_topics/en/hwi.md @@ -55,6 +55,9 @@ optech_mentions: - 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) From 9c75371ac83b7a6ddca07dc2e4b4345a3adc2d8e Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 1 Mar 2021 12:54:25 -0600 Subject: [PATCH 3/5] News138: add BIPs 1069 --- _posts/en/newsletters/2021-03-03-newsletter.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2021-03-03-newsletter.md b/_posts/en/newsletters/2021-03-03-newsletter.md index d4beb26d32..2639c5206a 100644 --- a/_posts/en/newsletters/2021-03-03-newsletter.md +++ b/_posts/en/newsletters/2021-03-03-newsletter.md @@ -115,7 +115,9 @@ BOLTs][bolts repo].* this new method from the `SigHashType::from_u32` method that accepts any consensus-valid sighash byte. -- [BIPs #1069][] BIP 8: Reduce threshold recommendation to 90% FIXME:bitschmidty or harding +- [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" %} @@ -134,3 +136,4 @@ BOLTs][bolts repo].* [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 From 235379e08068969b2ccb7948e72a57ee234561b1 Mon Sep 17 00:00:00 2001 From: Carl Dong Date: Mon, 1 Mar 2021 16:11:37 -0500 Subject: [PATCH 4/5] News138: Add Rust-Lightning #791 description --- _posts/en/newsletters/2021-03-03-newsletter.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2021-03-03-newsletter.md b/_posts/en/newsletters/2021-03-03-newsletter.md index 2639c5206a..cd2438e4a3 100644 --- a/_posts/en/newsletters/2021-03-03-newsletter.md +++ b/_posts/en/newsletters/2021-03-03-newsletter.md @@ -90,7 +90,12 @@ BOLTs][bolts repo].* allowing the use of hardware signers with Bitcoin Core without any use of the command line. -- [Rust-Lightning #791][] SPV client utility for syncing a lightning node FIXME:dongcarl +- [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][] Add support for `opt_shutdown_anysegwit` feature #780 FIXME:jonatack @@ -137,3 +142,4 @@ BOLTs][bolts repo].* [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 From 9175eff0a5cc625a396c05e0fc7cb6f27c8d3dea Mon Sep 17 00:00:00 2001 From: Jon Atack Date: Tue, 2 Mar 2021 19:18:29 +0100 Subject: [PATCH 5/5] News138: Add Rust-Lightning #794 --- _posts/en/newsletters/2021-03-03-newsletter.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/_posts/en/newsletters/2021-03-03-newsletter.md b/_posts/en/newsletters/2021-03-03-newsletter.md index cd2438e4a3..1af310bc24 100644 --- a/_posts/en/newsletters/2021-03-03-newsletter.md +++ b/_posts/en/newsletters/2021-03-03-newsletter.md @@ -97,7 +97,19 @@ BOLTs][bolts repo].* Core compatible node, allowing redundancy that can help prevent [eclipse attacks][topic eclipse attacks] or other security problems. -- [Rust-Lightning #794][] Add support for `opt_shutdown_anysegwit` feature #780 FIXME:jonatack +- [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 @@ -125,7 +137,7 @@ BOLTs][bolts repo].* 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" %} +{% 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 @@ -143,3 +155,4 @@ BOLTs][bolts repo].* [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