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.
- 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.