Bitcoin Optech: Bitcoin Technical Updates Newsletter #138

The Bitcoin Optech 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’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

News

Discussion about a BIP70 replacement: Thomas Voegtlin started a thread 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 is intended for use with LNURL but could be repurposed to serve Voegtlin’s intended use case. Kozlik’s 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 on the DLC-dev mailing list about the goal 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, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

Bitcoin Core #16546 introduces a new signer interface, allowing Bitcoin Core to interact with external hardware signing devices through the 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. Until this PR, however, the 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 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 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, BlockSource allows software to obtain data from sources other than a standard Bitcoin Core compatible node, allowing redundancy that can help prevent 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 to relay payments to any segwit script in Bitcoin Core 0.19.0.1 (released November 2019), it’s now safe to include them in LN’s standard forms.
HWI #413, #469, #463, #464, #471, #468, and #466 significantly update and extend HWI’s documentation. Particularly notable changes include a link to the documentation on ReadTheDocs.io, new and updated examples, and a new 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 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.

The original post can be found here: https://bitcoinops.org/en/newsletters/2021/03/03/

Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month: https://bitcoinops.org/en/newsletters/

Published at Thu, 04 Mar 2021 00:00:05 +0000