Hi Insiders. This is Tuma, open-source reporter from the Insider Edition.
In this week’s update we feature the new set of releases of Stratum V2, bringing security hardening, support for Bitcoin Core v32, and experimental Telegram notifications to the mining ecosystem.
We also cover several new BIPs being merged. In particular, the three BIPs for Cross-Input Signature Aggregation (CISA) — BIP458, BIP459, and BIP460 — have been merged.
Finally, we also discuss several news from the Bitcoin ecosystem. Notably, we cover a bug in LNbits that could lead to a loss of funds and the latest updates to the Great Script Restoration (GSR) proposal.
Highlights from the Bitcoin developer ecosystem
I spent 10+ hours in open-source developer calls in the Bitcoin ecosystem last week. Here is what caught my eye:
The Stratum V2 team published new releases for the core protocol, applications, and the UI.
During the weekly call, on Tuesday 03, Stratum V2 developers reported that the latest releases for the protocol were ready to be published. The releases were officially announced on Thursday 5th.
v1.13.0 of the core protocol includes security hardening on several crates, such as
buffer_sv2,codec_sv2andframing_sv2, and makes changes to better adhere to the protocol specifications. The release notes highlight that almost all the protocol crates had breaking changes and that downstream users should carefully review those changes when integrating.v0.9.0 of the applications also introduces several security fixes and adds support for Bitcoin Core v32.x. v0.8.0 of the UI was released too, adding support for an experimental feature that allows users to receive Telegram notifications about the status of their miners.
A BIPs Update
In the last days there was some movement in the BIP repository. Specifically, four new BIPs have been published and two new BIPs has been assigned a number by BIP maintainer Murchandamus.
Published BIPs
A list of recently published BIPs
BIP394: rawtr() Output Script Descriptors
Authors: jeanpablojp
Published On: Nov 6th, 2026
Layer: Applications
BIP394 defines a new output script descriptor, called rawtr() . The descriptor — that has been available in Bitcoin Core since v24.0 but was never specified in a BIP — can be used to express a P2TR output directly by its output key. The key is used as the taproot output key without applying the BIP341 tweak. This is useful, for example, when the internal structure isn’t known, or the script tree hasn’t been revealed by the owner.
BIP458: Half-Aggregation of BIP 340 Signatures
Authors: Tim Ruffing, Jonas Nick, Fabian Jahr
Published On: Nov 2nd, 2026
Layer: Applications
BIP458 describes how to perform half-aggregation of Schnorr signatures, as per BIP340. Half-aggregation is a non-interactive process for aggregating a collection of signatures into a single signature, whose size is approximately half of the combined size of the original signatures. This approach could also be leveraged for signatures in the inputs of Bitcoin transactions, a process known as cross-input signature aggregation (CISA).
BIP459: Full-Aggregation of BIP 340 Signatures
Authors: Fabian Jahr
Published On: Nov 3rd, 2026
Layer: Applications
BIP459 describes full-aggregation of Schnorr signatures, as per BIP340, a standard for Discrete Logarithm-Based Interactive Aggregate Signatures (DahLIAS) interactive aggregate signature scheme. Full-aggregation is an interactive process for aggregating a certain number of signatures into a single one, whose final size is the same as a single BIP 340 signature (64 bytes), regardless of the number of signers.
BIP460: CISA for Taproot Key Path Spends
Authors: Fabian Jahr
Published On: Nov 4th, 2026
Layer: Consensus (Soft Fork)
BIP460 proposes a soft fork to introduce transaction-wide Cross-Input Signature Aggregation. The draft defines a new witness version 2 , enabling Taproot-style key path spending where inputs can aggregate their signatures within a transaction. If used together with full-aggregation, the resulting aggregate signature would have a size of 64 bytes, independent on the number of signatures.
Numbered BIPs
BIP362: Output Public Key Exposure Classification
Authors: duncan0k
Assigned On: Nov 2nd, 2026
Layer: Applications
PR2294 introduces BIP362, which defines four exposure levels for outputs with respect to an adversary holding a cryptographically relevant quantum computer (CRQC). These labels are EXPOSED_AT_REST, which identifies long-term exposure as described in BIP360, EXPOSED_ON_SPEND, which identifies short-term exposure as described in BIP360, NOT_EXPOSED , which identifies outputs that require a valid post-quantum signature on every spending path, and UNDETERMINED , which identifies those outputs for which the script type could not be inferred.
BIP395: Unspendable Internal Keys for Wallet Policies
Authors: NTL
Assigned On: Nov 4th, 2026
Layer: Applications
PR2340 introduces BIP395, which defines _ as a placeholder for a Taproot internal key with no known signing key. This is particularly useful for those policies that require an unspendable key path. BIP395 also defines that the internal key must be derived from a synthetic BIP32 extended public key using the BIP341 Nothing Up My Sleeve (NUMS) point — a point with unknown discrete logarithm — and a chaincode — a tagged hash of the normalized policy —, which allows different implementations to independently reproduce the same address.
Other News from the Bitcoin World
LNbits Bug: The LNbits team advised all the users to immediately stop their LNbits server immediately due to a reported vulnerability that could lead to a loss of funds. No information about the bug or vulnerability has been released at the time of writing.
Update on the Great Script Restoration: Julian Moik and Rusty Russel posted an update on their work on the Great Script Restoration (GSR) — the current effort to restore Bitcoin script capabilities that were disabled by Satoshi in v0.3.1.
The updated draft is now composed of five different proposals that together form the second Taproot leaf version,
Tapleaf 0xc2.Other than restoring script capabilities, the proposal adds transaction introspection and extended primitives and limits the validation cost of each new script by introducing an explicit computational budget.
The authors published a comprehensive description of the updated proposal on the Bitcoin-dev mailing list.
More from BTC++ Insider Edition
Conferences
BTC++ Privacy Edition — Seoul: Last week, bitcoin++ held its 21st conference ever in Seoul. The main focus was on privacy, with speaker discussing coinjoins, silent payments, payjoins, ecash, and everything related. Follow bitcoin++ on X! The official livestream will be online this week!
Videos
Walter Maffione — BTC++ Insider Interviews: Walter Maffione — CEO and co-founder of KaleidoSwap — talks to the Insider about building a decentralized exchange on Bitcoin.
Joschisan — BTC++ Inisder Interviews: Fedimint developer Joschisan talks to the Insider about the work currently being done on the federated ecash protocol to improve all the modules. He also talks about the difference between Fedimint, the open-source protocol, and Fedi, the company building on top of it.