The Bitcoin Optech newsletter provides readers with a summary of the most important technical news in Bitcoin, as well as resources to help them learn more. To help our readers stay up to date on Bitcoin, we are posting the latest edition of this newsletter below. Remember to sign up to have this content delivered straight to your inbox.
- Discussion about a BIP70 replacement: Thomas Voegtlin started a thread on the Bitcoin Dev mailing list about a replacement for some features of the BIP70 payment protocol, in particular the ability to receive a signed payment request. Voegtlin would like to be able to prove that the address it paid was actually the address given by the recipient (e.g. an exchange). Charles Hill and Andrew Kozlik each responded with information about protocols they are working on. The Hill scheme is intended to be used with LNURL, but could be used by Voegtlin for the intended use case. Kozlik’s scheme is more similar to the BIP70, but dispenses with the use of X.509 certificates and adds functions for exchange-based coin exchanges (e.g. trading BTC for an altcoin or vice versa).
- Evidence of fraud in the DLC specification (Discreet Log Contract) v0: Thibaut Le Guilly started a discussion on the DLC developer mailing list about the goal of including evidence of fraud in the version 0 DLC coordination specification. Two types of fraud were discussed:
- Ambiguity: When an oracle signs more than once for the same event, which leads to conflicting results. Evidence of ambiguity can be automatically checked by the software without trusting third parties.
- Lies: Where an oracle represents an outcome that users know is wrong. This almost always depends on evidence that is not available to the user’s contract software. Therefore, this type of evidence of fraud must be manually verified by the user who can compare the original contract with the result signed by the oracle.
Panellists all seemed to prefer to provide proof of ambiguity, although there were concerns that it might be too much work for the v0 specification. As a workaround, it was suggested to focus on lying evidence. Once the format of these evidences has been determined, the software can be updated to create two separate evidences for the same oracle and event to create a proof of ambiguity. One problem with lying evidence was that bogus evidence could mark users as spam. Users must either waste their time reviewing false evidence or stop reviewing fraud evidence altogether. Counter arguments included the ability to get some of the evidence from an onchain transaction (for which someone has to pay an onchain fee) and that users can choose where to download evidence of fraud from and prefer to get it from one source, which is known only for disseminating accurate information.
Notable code and documentation changes
Notable changes this week to Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Suggestions (BIPs), and Lightning BOLTs.
- Bitcoin Core # 16546 introduces a new signing interface that allows Bitcoin Core to interact with external hardware signature devices through the HWI or any other application that implements the same interface. Bitcoin Core has been able to communicate with hardware signers via HWI since Bitcoin Core version 0.18. However, up until this PR, the process required using the command line to transfer data between Bitcoin Core and HWI. This PR simplifies the user experience by allowing Bitcoin Core to communicate directly with HWI. The PR contains complete documentation on the use of the new signing interface together with HWI. The new signing interface can currently only be accessed via RPC methods. A PR draft supports the signer’s interface UI and allows hardware signers to be used with Bitcoin Core without using the command line.
- Rust-Lightning # 791 has support for getting BlockSource interfaces at startup to sync blocks and headers, with the fork being detected during the sync. As described in Newsletter # 135, BlockSource allows the software to pull data from sources other than a standard Bitcoin Core compatible node. This enables redundancy which can help prevent Eclipse attacks or other security issues.
- Rust-Lightning # 794 enables support for the BOLT2 function option_shutdown_anysegwit, which enables future Segwit versions when starting shutdown. When option_shutdown_anysegwit is negotiated, a channel party sending a shutdown message to initiate the closing can send a scriptpubkey to pay, provided the script conforms to the standard form of the BIP141 witness program of a version byte (a 1-byte push Opcode from OP_1 to OP_16) by a witness program (a byte-vector push of 2 to 40 bytes). These shutdown scripts are limited to standard forms in order to avoid expensive scripts that are liable to costs or transactions with oversized scripts that are not distributed due to nonstandardity. Since it became possible to route payments to any Segwit script in Bitcoin Core 0.19.0.1 (released November 2019), it is now safe to include them on LN’s standard forms.
- HWI No. 413, No. 469, No. 463, No. 464, No. 471, No. 468 and No. 466 update and expand the documentation of HWI considerably. Notable changes include a link to documentation on ReadTheDocs.io, new and updated examples, and a new policy that describes the criteria new devices must meet in order for HWI to support them.
- Rust Bitcoin # 573 adds a new method SigHashType :: from_u32_standard, which ensures that the provided Sighash byte is one of the default values that Bitcoin Core forwards and mines by default. The sighash byte of each signature indicates which parts of the transaction need to be signed. Bitcoin’s consensus rules dictate that non-standard sigh values are treated as equivalent to SIGHASH_ALL. However, the fact that they are not routed or mined by default can theoretically be used to trick software with offchain obligations into accepting an unenforceable payment. Developers of such software using Rust Bitcoin can switch from the SigHashType :: from_u32 method, which accepts any consensus-valid sigh, to this new method.
- BIPs # 1069 updates BIP8 to allow for a configurable activation threshold and include 90% as a recommendation, compared to 95% previously based on the recent discussion on taproot activation.
You can find the original article here: https://bitcoinops.org/en/newsletters/2021/03/03/
Subscribe directly to the Bitcoin Optech newsletter to receive this content directly in your inbox every month: https://bitcoinops.org/en/newsletters/