The Bitcoin Optech newsletter provides readers with a high-level summary of the most important technical news happening in Bitcoin, along with resources to help them learn more. To help our readers stay up to date with Bitcoin, we’re republishing the latest edition of this newsletter below. Remember to subscribe to receive this content straight to your inbox.
This week’s newsletter announces a change in the networks of several IRC channels and celebrates the 150th Optech newsletter. Also included are our usual sections with frequently asked questions and answers from Bitcoin Stack Exchange, new software releases, release candidates, and notable changes to popular Bitcoin infrastructure projects.
- IRC Channels Move to Libera.Chat: At the Bitcoin Core Developers Weekly Meeting, it was so Established That Thursday, May 27th meeting will be the last to be held on the Freenode network. Bots, registration, other infrastructure, future meetings and general discussion will be moved to #bitcoin-core-dev at Libra network. Actions taken by Freenode officials shortly before this newsletter was published seem to have forced the move to happen early Wednesday morning (UTC). Several other Bitcoin and LN related channels are also moving in. For help in finding the current network of the various channels, see Bitcoin Wiki’s List of IRC channels. If you run a moving channel and don’t have a Wiki account to update this list yourself, please let the editors know at the #bitcoin-wiki on Libera.
Celebrating Optech’s 150th Newsletter
by John NewberyFounder of Optech
This is the 150th weekly Optech newsletter we wrote for the Bitcoin tech community. We’re only pausing for short breaks around the Christmas holidays, and we’ve posted summaries of the most important events in Bitcoin and Lightning’s development every week since June 2018.
Optech started with some very simple goals: to help Bitcoin companies adopt technologies that allow Bitcoin to scale, and to highlight the amazing technical work that is happening in the Bitcoin open source community. Although we couldn’t predict exactly what shape it would take three years in advance, it’s a mission we still believe in, and it guides all the work we do. Since June 2018, we have:
- Posted 150 Newsletters, several Blog Posts and field reports, a A special series on the bash 32, And the Interactive Radical Workshop. In total, we published about 250,000 words – enough to fill about 700 printed pages.
- The email has over 4,100 subscribers and nearly 11,000 Twitter followers.
- I started seeing some of our newsletters translated into Japanese And the Spanish by community members.
- Produced and maintained a Topic Index A single site where readers can track the evolution of Bitcoin and Lightning proposals and improvements.
Newsletters are the work of many contributors. Among them in the first place Dave Harding, who writes the majority of our content. To say Dave is prolific is an understatement – week after week, he produces brief, clear summaries of the highly diverse research and development that is happening across the Bitcoin ecosystem. We are fortunate to have someone with the breadth of knowledge, dedication, and humility to document Bitcoin. The wide range of work he has produced for Optech and other projects is a huge asset for all current and future Bitcoins.
Supporting roles are filled by other Optechers. Mike Schmidt He writes our regular sections about Stack Exchange Q&As and noticeable changes to the Bitcoin software and infrastructure, and makes sure the newsletter reaches everyone’s inbox on time. John Attack Contributes to our regular summary of the Bitcoin Core PR Review Club. as well as mike and john, Carl DongAnd the Adam JonasAnd the Mark Erhardt I occasionally contribute PR summaries and review our newsletter each week to try to ensure that the content we produce is accurate and clear.
Thanks to all the members of the Bitcoin community – too many individual names – who checked out our newsletters, helped us understand concepts, and opened up issues and PR when we made mistakes.
Finally, thank you, our readers. We love being part of this community and contributing to this ecosystem. Knowing how valuable this resource is to so many people, and hearing feedback from our readers is very rewarding for us. If you would like to contribute, or have suggestions on how we can improve, please feel free to contact us at email@example.com.
Bitcoin Stack Exchange specific question and answer
Bitcoin Stack Exchange It’s one of the first places Optech contributors look for answers to their questions – or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since the last update.
- Why is there more than one transaction output in a coinbase transaction? Andrew Chow explains some common outputs in a coinbase transaction:
- Pay one miner block reward
- Multiple payments, as with a mining pool that pays miners
- BIP141OP_RETURN Obligation of the witness
- Additional OP_RETURN commits, as in Mining merge and other protocols
- Money Transfer – What is it? Pieter Wuille demonstrates what RPC does for a money transaction by providing 4 examples of how to send coins using RPC.
- What are the preexisting technologies that made Bitcoin possible? Murch provides a summary, based on a file Bitcoin Academic Pedigree Paper, of the existing technological components that have been combined to create Bitcoin. These technologies are associated with temporal/verifiable records, Byzantine fault tolerance, Proof of Work, digital cash, and public keys as identities.
- How can I follow the progress of the signal miner to activate Taproot? In addition to Hampus Sjöberg’s https://taroot.watch Website, Bitcoin Core users can use getblockchaininfo to get a number of signal blocks and getblock’s versionhex field, where the signal version bits are located, to monitor the signals.
Releases and releases candidates
New Releases and Candidate Releases for Popular Bitcoin Infrastructure Projects. Please consider upgrading to new releases or help test release candidates.
- Eclair 0.6.0 It is a new version that contains many improvements that enhance user security and privacy. It also provides compatibility with future software that may be used root addresses.
- LND 0.13.0 Beta It is a release filter that adds support for using a full-trimmed Bitcoin node, and allows receiving and sending payments using Atomic MultiPath (AMP), and more than PSBT capabilities, among other improvements and bug fixes.
Notable changes to code and documentation
Notable changes this week in Bitcoin CoreAnd the C- lightningAnd the EclairAnd the LNDAnd the rust and lightningAnd the libsecp256k1And the Hardware Wallet Interface (HWI)And the rust bitcoinAnd the BTCPay serverAnd the Bitcoin Improvement Proposals (BIPs), And the lightning bolt.
- Bitcoin Core #21843 Adds a network argument to getnodeaddresses RPC. When getnodeaddresses is called with this argument set to a supported network type (ipv4, ipv6, onion or i2p), it will return only known addresses on the given network. When connecting without a network argument, getnodeaddresses will return known addresses from all networks.
- Eclair # 1810 Peers are required to point to and comply with the payment_secret bit. Payment secrets feature frustrates Recipient anonymization attack It provides additional protection against Inappropriate image inspired. The feature is supported across all major implementations and is mandatory for payments to LND And the rust and lightning.
- Eclair # 1774 Expands() Java’s built-in SecureRandom CSPRNG Powered by a secondary source for weaker randomness. Weaker randomization is hashed and hash digests are hashed with initial randomness so that, even if SecureRandom() produces predictable results due to some bug detected in the future, there is a chance that Eclair will still have enough entropy that its ciphers remain untappable .
- BIPs # 1089 appointed BIP87 for a previous suggestion Discussed in the mailing list To create a unified set of BIP32 Paths to multisig wallets regardless of their multisig parameters, address type you’re using, or other script-level details. Instead, users of the proposed standard store those details in a file script descriptor. This eliminates the need for wallets to implement multiple different criteria for subtle differences in multisig (eg BIP45 and the m/48′ standard) or create new standards for things that can be handled by descriptors. Although using a descriptor instead of a unified script means that more data needs to be backed up, the actual difference is small – most of the data in a typical multisig descriptor will be the extended public keys (xpubs) that need to be backed up by each party in the multisig on any given case, so the additional information about the script template and the descriptor checksum assembler only adds a small amount of overhead by comparison.
- BIPs # 1025 appointed BIP 88 to the standard format shown in Newsletter #105 To describe the BIP32 key derivation paths that the wallet should support. Path templates provide a compact way for the user to select the paths they want to use. The compression of the path templates makes it easy to back up the template with the base, which helps prevent users from losing money. An additional advantage of the proposed path templates is the ability to describe the limits of derivation (for example, a wallet should not derive more than 50,000 keys in a given path), which makes it practical to perform recovery to erase the received bitcoins for everyone. Wallet Keys, removing concerns about gap limits in HD wallets.
- BIPs # 1097 appointed BIP129 To the Bitcoin Secure Multisig (BSMS) setup described in Newsletter #136, which explains how wallets, especially hardware signature devices, can securely exchange the information necessary to become signer of a multi-signature wallet. The information to be exchanged includes the sample script to be used (eg P2WSH with 2 of 3 keys required for signing) and each signer BIP32 The extended public key (xpub) in the master path it plans to use for signing. The protocol uses a formatter to gather the required information and generate an output script descriptor, which then checks individual signers to ensure that their key contains correctly.
Excuse me Subscribe to the Bitcoin Optech Newsletter Direct to receive this content straight to your inbox every month.