Stay up to Date on the Latest in Bitcoin Tech

  1. Weekly summaries of bitcoin-dev, lightning-dev, and Delving Bitcoin mailing lists
  2. Keep your finger on the pulse of bitcoin tech development and conversations
  3. Perfect for bitcoin builders, educators, and contributors to stay on top of a growing field

Bitcoin TLDR

#134

Oct 6 - Oct 11, 2026

curly arrow

Catch up on This Week's Activity

The recent discussions from various mailing lists reveal significant advancements and considerations in blockchain technology and cryptocurrency frameworks. A novel Layer 2 (L2) transaction system proposed by Adam Gibson and detailed in the Lichen Draft Paper allows for secure, co-owned contract transactions on the Bitcoin blockchain without requiring trust in a central hub's honesty. This system leverages multi-signature setups and cryptographic proofs to ensure user control over funds even if the hub goes offline, potentially expanding to support complex smart contracts and high-privacy transactions.

Luke Carriere has introduced a draft to standardize enforcement policies for blockchain co-signers, aiming to enhance interoperability across different security products like Liquidium and Lendasat. This draft, outlined in Draft BIP, suggests a unified format for various verification methods and conditions, fostering greater compatibility and security in co-signed transactions across diverse blockchain applications.

Furthermore, an emerging protocol named Cassis, as discussed at Cassis, proposes a streamlined method for conducting payments across multiple blockchain layers using Hash Time Locked Contracts (HTLCs). This approach not only simplifies transaction routing via various solvers but also enhances user flexibility in managing privacy and security settings without sacrificing functionality. The ongoing development and challenges of this protocol are actively documented and accessible on GitHub, inviting contributions to refine and optimize this innovative payment mechanism.

Read This Week's Newsletter
/icons/grey-bitcoin-icon.svg
FOCUSED ON BITCOIN

100% concentrated on bitcoin and related technologies.

/icons/grey-github-icon.svg
OPEN SOURCE

Everything we do is open source. We want your reviews and contributions.

/icons/grey-code-icon.svg
BITCOIN TECH

We focus on enabling devs to learn, practice, and build with bitcoin.

Explore Bitcoin Tech Conversations
dancing astronaut

Active Discussions

Check out posts actively getting replies and inspiring conversations.

View All

Historic Conversations

Explore posts in this historic deep dive. Surfacing posts where the last reply is in the current month.

View All

All Activity

Read the most recent individual posts in chronological order.

View All
curvy lines
Latest Bitcoin TLDR Newsletters

Bitcoin TLDR

#134

newsletter icon

Oct 6 - Oct 11, 2026

The recent discussions from various mailing lists reveal significant advancements and considerations in blockchain technology and cryptocurrency frameworks. A novel Layer 2 (L2) transaction system proposed by Adam Gibson and detailed in the [Lichen Draft Paper](https://github.com/AdamISZ/lichen/blob/master/papers/lichen-draft.pdf) allows for secure, co-owned contract transactions on the Bitcoin blockchain without requiring trust in a central hub's honesty. This system leverages multi-signature setups and cryptographic proofs to ensure user control over funds even if the hub goes offline, potentially expanding to support complex smart contracts and high-privacy transactions. Luke Carriere has introduced a draft to standardize enforcement policies for blockchain co-signers, aiming to enhance interoperability across different security products like Liquidium and Lendasat. This draft, outlined in [Draft BIP](https://github.com/lukecarriere/bip-cosigner-spending-policies/blob/main/bip-cosigner-spending-policies.md), suggests a unified format for various verification methods and conditions, fostering greater compatibility and security in co-signed transactions across diverse blockchain applications. Furthermore, an emerging protocol named Cassis, as discussed at [Cassis](https://cassis.cash/), proposes a streamlined method for conducting payments across multiple blockchain layers using Hash Time Locked Contracts (HTLCs). This approach not only simplifies transaction routing via various solvers but also enhances user flexibility in managing privacy and security settings without sacrificing functionality. The ongoing development and challenges of this protocol are actively documented and accessible on [GitHub](https://github.com/cassiscash/cassi), inviting contributions to refine and optimize this innovative payment mechanism.

Bitcoin TLDR

#133

newsletter icon

Sep 29 - Oct 4, 2026

Recent discussions in the Bitcoin development community have centered on the proposed Bitcoin Improvement Proposal (BIP) 54, spearheaded by Poinsot, aimed at addressing significant security vulnerabilities within the Bitcoin protocol. The proposal, which includes tackling issues such as the timewarp attack and 64-byte transaction malleability, has stirred extensive debate, particularly regarding the rule to eliminate 64-byte transactions. The implementation of BIP 54 in Bitcoin Core and btcd is under review, with further testing being encouraged to ensure robustness before potential activation around the second semester of 2027. For more detailed insights, see [Bitcoin Dev Mailing List](https://gnusha.org/pi/bitcoindev/CALZpt+GwkE1gH2-yrJXt=oqkrYR_ubdrMur0PG6aZvziJCHMLg@mail.gmail.com/T/#u#m682e9faf2a19de1093268d41240823ed54a0a6cc). The Flame project presents a novel Bitcoin side chain that employs a proof-of-burn consensus mechanism, aiming for a fully decentralized model without according special privileges to any network participants. This side chain enhances transaction confidentiality and network efficiency through technologies like Bulletproofs and Ristretto, and Utreexo for compact state management. The Flame project, which links closely with Bitcoin's security model, is set to launch its mainnet in January 2027, with documentation and ongoing development details available on [GitHub](https://github.com/runflame/flame-lib) and an overview on [Flame Project PDF](https://runflame.org/flame.pdf). Additionally, advancements in blockchain technology have facilitated new methods for dispute resolution within smart contracts, particularly through the introduction of "venues" in Bitcoin's Lightning Network. This method, detailed in a recent paper and GitHub repository, allows for trustless dispute resolution in games like chess and blackjack by efficiently managing long-chain games off-chain. Despite potential vulnerabilities such as collusion risks, this system maintains minimal blockchain space usage and introduces broader implications for decentralized services. Further details can be accessed in the [GitHub Repository](https://github.com/AdamISZ/ln-gap). Lastly, the recent update to Eclair v0.14.1 addresses critical vulnerabilities that could impact node functionality and security, demonstrating the continuous need for updates and vigilance in the cryptocurrency software environment. Notable fixes in this update address denial-of-service exploits and misuse of `temporary_channel_id`, with further details provided in the [Lnfuzz Advisory](https://lnfuzz.org/advisories/eclair-open-channel-race-dos/) and [Erick Cestari's Blog](https://erickcestari.dev/blog/eclair-oom-pending-channels/).

Bitcoin TLDR

#132

newsletter icon

Aug 24 - Aug 29, 2026

The SHRINCS Working Group has proposed a draft for a new cryptographic Bitcoin Improvement Proposal (BIP), introducing SHRINCS, a semi-stateful hash-based signature scheme aimed at enhancing security against quantum threats. The draft highlights the speed and compactness of SHRINCS but notes the complexity of its stateful nature and the high computational demands of its key generation and signing processes. Significant contributions by Jonas Nick and Mikhail Kudinov have improved interoperability and flexibility for high-frequency signing applications like the Lightning Network. Community feedback is sought to address the lack of essential components such as security proofs and optimized implementations ([SHRINCS Working Group Draft](https://github.com/SHRINCS/shrincs-bip/blob/main/SHRINCS.md), [Video Interview](https://youtu.be/n-jGPICZMR0?si=NpfyTRB88-sUxtlh)). The Time-Shifted Proof of Work (TSPOW) protocol introduces a two-stage process for Bitcoin transaction verification and coin minting, aiming to stabilize block times and address economic incentives for withholding mining efforts. Despite its potential benefits in reducing time variance and economic manipulation, TSPOW does not mitigate fundamental security issues like majority attacks and requires a hard fork due to significant changes in the block structure. Detailed analyses and simulations are available for community review and feedback in the TSPOW GitHub repository ([TSPOW GitHub Repository](https://github.com/corepool/timeshiftpow)). Silent Payments in coinbase transactions (SPc) offer a more privacy-focused method for paying cryptocurrency miners, utilizing static public addresses to prevent exposure of transaction histories. This approach requires significant adjustments in mining pool operations and coinbase transaction structures, with ongoing community collaboration essential for refining and potentially formalizing SPc into a BIP. Security measures and operational logistics are crucial in preserving miner privacy while maintaining mining integrity ([Silent Payments Discussion](https://delvingbitcoin.org/t/silent-payments-coinbase/2833)).

Read Summaries by Source

Bitcoin Dev

View All

Delving Bitcoin

View All

Lightning Dev (archive)

View All
reading astronaut
curvy lines
What People Have to Say
Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiDecoding BitcoinWarnet
Built with 🧑 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project.

Give Feedback