{"id":17584,"date":"2021-03-04T00:00:05","date_gmt":"2021-03-04T00:00:05","guid":{"rendered":"http:\/\/ci027d2866600026c3"},"modified":"2025-10-02T15:07:17","modified_gmt":"2025-10-02T20:07:17","slug":"bitcoin-optech-bitcoin-technical-updates-newsletter-138","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-optech-bitcoin-technical-updates-newsletter-138","title":{"rendered":"Bitcoin Optech: Bitcoin Technical Updates Newsletter #138"},"content":{"rendered":"<div id=\"bsf_rt_marker\"><\/div><p><em>The <a href=\"https:\/\/bitcoinops.org\/\" target=\"_blank\" rel=\"noopener\">Bitcoin Optech <\/a>newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we&#8217;re republishing the latest issue of this newsletter below. Remember <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/\" target=\"_blank\" rel=\"noopener\">to subscribe<\/a> to receive this content straight to your inbox.<\/em><\/p>\n<h2>News<\/h2>\n<ul>\n<li><strong>Discussion about a BIP70 replacement:<\/strong> Thomas Voegtlin started a <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-February\/018443.html\" target=\"_blank\" rel=\"noopener\">thread<\/a> on the Bitcoin-Dev mailing list about a replacement for some of the features of the <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0070.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP70<\/a> 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\u2019re working on. Hill\u2019s <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-February\/018446.html\" target=\"_blank\" rel=\"noopener\">scheme<\/a> is intended for use with <a href=\"https:\/\/github.com\/fiatjaf\/lnurl-rfc\" target=\"_blank\" rel=\"noopener\">LNURL<\/a> but could be repurposed to serve Voegtlin\u2019s intended use case. Kozlik\u2019s <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-February\/018448.html\" target=\"_blank\" rel=\"noopener\">scheme<\/a> is closer in spirit to BIP70 but drops its use of <a href=\"https:\/\/en.wikipedia.org\/wiki\/X.509\" target=\"_blank\" rel=\"noopener\">X.509 certificates<\/a> and adds features for exchange-based coin swaps (e.g. trading BTC for an altcoin or vice-versa).<\/li>\n<li><strong>Fraud proofs in the v0 Discreet Log Contract (DLC) specification:<\/strong> Thibaut Le Guilly started a <a href=\"https:\/\/mailmanlists.org\/pipermail\/dlc-dev\/2021-February\/000020.html\" target=\"_blank\" rel=\"noopener\">discussion<\/a> on the DLC-dev mailing list about the <a href=\"https:\/\/github.com\/discreetlogcontracts\/dlcspecs\/blob\/master\/v0Milestone.md#simple-fraud-proofs-in-progress\" target=\"_blank\" rel=\"noopener\">goal<\/a> to include fraud proofs in the version 0 DLC coordination specification. Two types of fraud were discussed:\n<ul>\n<li><em>Equivocation:<\/em> 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.<\/li>\n<li><em>Lying:<\/em> where an oracle signs for an outcome that users know is wrong. This will almost always depend on evidence not available to the user\u2019s 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.<\/li>\n<\/ul>\n<p>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.<\/li>\n<\/ul>\n<h2>Notable code and documentation changes<\/h2>\n<p><em>Notable changes this week in <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\" target=\"_blank\" rel=\"noopener\">Bitcoin Core<\/a>, <a href=\"https:\/\/github.com\/ElementsProject\/lightning\" target=\"_blank\" rel=\"noopener\">C-Lightning<\/a>, <a href=\"https:\/\/github.com\/ACINQ\/eclair\" target=\"_blank\" rel=\"noopener\">Eclair<\/a>, <a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/\" target=\"_blank\" rel=\"noopener\">LND<\/a>, <a href=\"https:\/\/github.com\/rust-bitcoin\/rust-lightning\" target=\"_blank\" rel=\"noopener\">Rust-Lightning<\/a>, <a href=\"https:\/\/github.com\/bitcoin-core\/secp256k1\" target=\"_blank\" rel=\"noopener\">libsecp256k1<\/a>, <a href=\"https:\/\/github.com\/bitcoin-core\/HWI\" target=\"_blank\" rel=\"noopener\">Hardware Wallet Interface (HWI)<\/a>, <a href=\"https:\/\/github.com\/rust-bitcoin\/rust-bitcoin\" target=\"_blank\" rel=\"noopener\">Rust Bitcoin<\/a>, <a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/\" target=\"_blank\" rel=\"noopener\">BTCPay Server<\/a>, <a href=\"https:\/\/github.com\/bitcoin\/bips\/\" target=\"_blank\" rel=\"noopener\">Bitcoin Improvement Proposals (BIPs)<\/a>, and <a href=\"https:\/\/github.com\/lightningnetwork\/lightning-rfc\/\" target=\"_blank\" rel=\"noopener\">Lightning BOLTs<\/a>.<\/em><\/p>\n<ul>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/16546\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #16546<\/a> introduces a new signer interface, allowing Bitcoin Core to interact with external hardware signing devices through the <a href=\"https:\/\/bitcoinops.org\/en\/topics\/hwi\/\" target=\"_blank\" rel=\"noopener\">HWI<\/a> or any other application which implements the same interface.Bitcoin Core has been able to interface with hardware signers using HWI <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/05\/07\/#basic-hardware-signer-support-through-independent-tool\" target=\"_blank\" rel=\"noopener\">since Bitcoin Core version 0.18<\/a>. Until this PR, however, <a href=\"https:\/\/github.com\/bitcoin-core\/HWI\/blob\/7b34fc72c5b2c5af216d8b8d5cd2d2c92b6d2457\/docs\/examples\/bitcoin-core-usage.rst\" target=\"_blank\" rel=\"noopener\">the process<\/a> 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 <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/blob\/master\/doc\/external-signer.md\" target=\"_blank\" rel=\"noopener\">full documentation<\/a> on how to use the new signer interface along with HWI.The new signer interface is currently only accessible through RPC methods. A <a href=\"https:\/\/github.com\/bitcoin-core\/gui\/pull\/4\" target=\"_blank\" rel=\"noopener\">draft PR<\/a> 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.<\/li>\n<li>Rust-Lightning #791 adds support for polling <code>BlockSource<\/code> interfaces on startup to sync blocks and headers, with fork detection during sync. As described in <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/02\/10\/#rust-lightning-774\" target=\"_blank\" rel=\"noopener\">Newsletter #135<\/a>, BlockSource allows software to obtain data from sources other than a standard Bitcoin Core compatible node, allowing redundancy that can help prevent <a href=\"https:\/\/bitcoinops.org\/en\/topics\/eclipse-attacks\/\" target=\"_blank\" rel=\"noopener\">eclipse attacks<\/a> or other security problems.<\/li>\n<li>Rust-Lightning #794 enables support for the <a href=\"https:\/\/github.com\/lightningnetwork\/lightning-rfc\/blob\/master\/02-peer-protocol.md\" target=\"_blank\" rel=\"noopener\">BOLT2<\/a> <code>option_shutdown_anysegwit<\/code> feature that permits future segwit versions when initiating shutdown. If <code>option_shutdown_anysegwit<\/code> 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 <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0141.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP141<\/a> witness program form of a <em>version byte<\/em> (a 1-byte push opcode of <code>OP_1<\/code> through <code>OP_16<\/code>) followed by a <em>witness program<\/em> (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 <a href=\"https:\/\/bitcoincore.org\/en\/releases\/0.19.0.1\/#mempool-and-transaction-relay\" target=\"_blank\" rel=\"noopener\">possible<\/a> to relay payments to any segwit script in Bitcoin Core 0.19.0.1 (released November 2019), it\u2019s now safe to include them in LN\u2019s standard forms.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin-core\/HWI\/issues\/413\" target=\"_blank\" rel=\"noopener\">HWI #413<\/a>, <a href=\"https:\/\/github.com\/bitcoin-core\/HWI\/issues\/469\" target=\"_blank\" rel=\"noopener\">#469<\/a>, <a href=\"https:\/\/github.com\/bitcoin-core\/HWI\/issues\/463\" target=\"_blank\" rel=\"noopener\">#463<\/a>, <a href=\"https:\/\/github.com\/bitcoin-core\/HWI\/issues\/464\" target=\"_blank\" rel=\"noopener\">#464<\/a>, <a href=\"https:\/\/github.com\/bitcoin-core\/HWI\/issues\/471\" target=\"_blank\" rel=\"noopener\">#471<\/a>, <a href=\"https:\/\/github.com\/bitcoin-core\/HWI\/issues\/468\" target=\"_blank\" rel=\"noopener\">#468<\/a>, and <a href=\"https:\/\/github.com\/bitcoin-core\/HWI\/issues\/466\" target=\"_blank\" rel=\"noopener\">#466<\/a> significantly update and extend HWI\u2019s documentation. Particularly notable changes include a link to the documentation on <a href=\"https:\/\/hwi.readthedocs.io\/en\/latest\/?badge=latest\" target=\"_blank\" rel=\"noopener\">ReadTheDocs.io<\/a>, new and updated <a href=\"https:\/\/hwi.readthedocs.io\/en\/latest\/examples\/index.html\" target=\"_blank\" rel=\"noopener\">examples<\/a>, and a new <a href=\"https:\/\/hwi.readthedocs.io\/en\/latest\/devices\/index.html#support-policy\" target=\"_blank\" rel=\"noopener\">policy<\/a> that describes the criteria new devices must meet for HWI to consider supporting them.<\/li>\n<li><a href=\"https:\/\/github.com\/rust-bitcoin\/rust-bitcoin\/issues\/573\" target=\"_blank\" rel=\"noopener\">Rust Bitcoin #573<\/a> adds a new method <code>SigHashType::from_u32_standard<\/code> that ensures the provided sighash byte is one of <a href=\"https:\/\/btcinformation.org\/en\/developer-guide#signature-hash-types\" target=\"_blank\" rel=\"noopener\">standard values<\/a> that Bitcoin Core will relay and mine by default. Each signature\u2019s sighash byte indicates what parts of the transaction need to be signed. Bitcoin\u2019s consensus rules dictate that non-standard sighash values are treated as equivalent to <code>SIGHASH_ALL<\/code>, but the fact that they aren\u2019t 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 <code>SigHashType::from_u32<\/code> method that accepts any consensus-valid sighash byte.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bips\/issues\/1069\" target=\"_blank\" rel=\"noopener\">BIPs #1069<\/a> updates <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0008.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP8<\/a> to allow for a configurable activation threshold and to include 90% as a recommendation, down from 95% previously, based on the most recent <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/02\/24\/#taproot-activation-discussion\" target=\"_blank\" rel=\"noopener\">taproot activation discussion<\/a>.<\/li>\n<\/ul>\n<p>Find the <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/03\/03\/\" target=\"_blank\" rel=\"noopener\">original post here.<\/a>&nbsp;<\/p>\n<p>Please <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/\" target=\"_blank\" rel=\"noopener\">subscribe to the Bitcoin Optech newsletter<\/a> directly to receive this content straight to your inbox every month.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This week\u2019s newsletter covers the BIP70 payment protocol, proposals for a standardized way to exchange fraud proofs for Discreet Log Contracts (DLCs) and more.<\/p>\n","protected":false},"author":3246,"featured_media":16038,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[2887],"class_list":{"0":"post-17584","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-bitcoin-optech"},"author_data":{"id":3246,"name":"Bitcoin Optech","nicename":"bitcoin-optech","avatar_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/12\/optech-notext-96x96.png"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/op-ed-bitcoin-in-africa.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/17584","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/users\/3246"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=17584"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/17584\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/16038"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=17584"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=17584"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=17584"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}