The Bitcoin Optech e-newsletter gives readers with a top-level abstract of a very powerful technical information taking place in Bitcoin, together with sources that assist them be taught extra. To assist our readers keep up-to-date with Bitcoin, we’re republishing the newest concern of this article under. Keep in mind to subscribe to obtain this content material straight to your inbox.
Information
- Dialogue a few BIP70 alternative: Thomas Voegtlin began a thread on the Bitcoin-Dev mailing listing a few alternative for a number of the options of the BIP70 cost protocol, particularly the flexibility to obtain a signed cost request. Voegtlin desires to have the ability to show that the handle he paid was truly the handle offered to him by the receiver (e.g. an trade). Charles Hill and Andrew Kozlik every replied with details about protocols they’re engaged on. Hill’s scheme is meant to be used with LNURL however may very well be repurposed to serve Voegtlin’s meant use case. Kozlik’s scheme is nearer in spirit to BIP70 however drops its use of X.509 certificates and provides options for exchange-based coin swaps (e.g. buying and selling BTC for an altcoin or vice-versa).
- Fraud proofs within the v0 Discreet Log Contract (DLC) specification: Thibaut Le Guilly began a discussion on the DLC-dev mailing listing in regards to the goal to incorporate fraud proofs within the model 0 DLC coordination specification. Two forms of fraud have been mentioned:
- Equivocation: the place an oracle indicators for a similar occasion greater than as soon as, producing conflicting outcomes. A proof of equivocation will be mechanically verified by software program with out third-party belief.
- Mendacity: the place an oracle indicators for an end result that customers know is mistaken. It will virtually all the time rely on proof not accessible to the consumer’s contract software program, so any such fraud proof should be verified manually by the consumer, who can examine the unique contract to the result signed by the oracle.
Dialogue contributors appeared to all favor offering an equivocation proof, though there was some concern that it may very well be an excessive amount of work for the v0 specification. As an intermediate resolution, it was steered to concentrate on proofs of mendacity. When the format of these proofs has been established, software program can then be up to date to take two separate proofs for a similar oracle and occasion to create a proof of equivocation.One concern with proofs of mendacity was that customers may very well be spammed by pretend proofs, forcing customers to both waste their time verifying false proofs or surrender checking fraud proofs altogether. Counterarguments included with the ability to get a part of the proof from an onchain transaction (which requires that somebody paid an onchain payment) and in addition that customers might select the place they obtain fraud proofs from, preferring to get them from a supply that was identified for less than propagating correct info.
Notable code and documentation adjustments
Notable adjustments 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 brand new signer interface, permitting Bitcoin Core to work together with exterior {hardware} signing units by means of the HWI or every other software which implements the identical interface.Bitcoin Core has been in a position to interface with {hardware} signers utilizing HWI since Bitcoin Core version 0.18. Till this PR, nonetheless, the process required use of the command line to switch knowledge between Bitcoin Core and HWI. This PR simplifies the consumer expertise by enabling Bitcoin Core to immediately talk with HWI. The PR contains full documentation on how you can use the brand new signer interface together with HWI.The brand new signer interface is presently solely accessible by means of RPC strategies. A draft PR provides help for the signer interface to the GUI, permitting using {hardware} signers with Bitcoin Core with none use of the command line.
- Rust-Lightning #791 provides help for polling
BlockSourceinterfaces on startup to sync blocks and headers, with fork detection throughout sync. As described in Newsletter #135, BlockSource permits software program to acquire knowledge from sources aside from a regular Bitcoin Core suitable node, permitting redundancy that may assist forestall eclipse attacks or different safety issues. - Rust-Lightning #794 allows help for the BOLT2
option_shutdown_anysegwitfunction that allows future segwit variations when initiating shutdown. Ifoption_shutdown_anysegwitis negotiated, a channel social gathering sending a shutdown message to provoke closing could ship a scriptpubkey for cost, offered the script complies with the usual BIP141 witness program type of a model byte (a 1-byte push opcode ofOP_1by means ofOP_16) adopted by a witness program (a byte vector push of two to 40 bytes). These shutdown scripts are restricted to straightforward types to keep away from costly fee-heavy scripts or transactions with outsized scripts not propagating attributable to non-standardness. Because it grew to become possible to relay funds to any segwit script in Bitcoin Core 0.19.0.1 (launched November 2019), it’s now secure to include them in LN’s normal types. - HWI #413, #469, #463, #464, #471, #468, and #466 considerably replace and lengthen HWI’s documentation. Significantly notable adjustments embody a hyperlink to the documentation on ReadTheDocs.io, new and up to date examples, and a brand new policy that describes the standards new units should meet for HWI to contemplate supporting them.
- Rust Bitcoin #573 provides a brand new methodology
SigHashType::from_u32_standardthat ensures the offered sighash byte is one in every of standard values that Bitcoin Core will relay and mine by default. Every signature’s sighash byte signifies what elements of the transaction have to be signed. Bitcoin’s consensus guidelines dictate that non-standard sighash values are handled as equal toSIGHASH_ALL, however the truth that they aren’t relayed or mined by default can theoretically be used to trick software program utilizing offchain commitments into accepting an unenforceable cost. Builders of such software program utilizing Rust-Bitcoin could which to change to this new methodology from theSigHashType::from_u32methodology that accepts any consensus-valid sighash byte. - BIPs #1069 updates BIP8 to permit for a configurable activation threshold and to incorporate 90% as a suggestion, down from 95% beforehand, primarily based on the latest taproot activation discussion.
The unique submit will be discovered right here: https://bitcoinops.org/en/newsletters/2021/03/03/
Please subscribe to the Bitcoin Optech e-newsletter on to obtain this content material straight to your inbox each month: https://bitcoinops.org/en/newsletters/
![What Is Bitcoin? The Definitive Beginner’s Guide [2020]](https://www.mypipro.com/wp-content/uploads/2020/11/what-is-bitcoin-social-compressor-120x86.jpg?189db0&189db0)
