Latest Bitcoin TLDR Newsletters

Jan 20 - Jan 26, 2025

A significant vulnerability was identified in the Lightning Development Kit (LDK) versions 0.0.125 and below, making funds inaccessible through a liquidity griefing attack by exploiting a flaw in the way LDK handles conflicting HTLC claims on force-closed channels. This vulnerability allowed attackers to render funds unrecoverable by manipulating HTLC transactions, necessitating a manual construction and broadcast of a valid claim transaction for recovery. Users are advised to upgrade to LDK version 0.1, which addresses this issue by revising the logic to handle multiple conflicting aggregated transactions appropriately, ensuring the security of transactions and the recoverability of funds. The discovery of this bug, detailed in a blog post by morehouse, emphasizes the critical need for ongoing code review and the importance of simplicity and readability in software development to prevent such vulnerabilities, particularly in financial applications like those built on the LDK. [Further information can be found here](https://delvingbitcoin.org/t/disclosure-ldk-invalid-claims-liquidity-griefing/1400). The fix implemented in LDK 0.1 corrects the vulnerability by changing how confirmed transactions are processed, preventing an attacker from exploiting the bug to lock up HTLCs through conflicting aggregated transactions. This resolution highlights the significance of continuous vigilance and regular auditing in the software development process, especially for platforms facilitating critical financial operations. The incident underscores the ever-present risk of attacks in the cryptocurrency domain and reinforces the necessity for developers and users to keep software updated to mitigate potential security threats.

Jan 13 - Jan 19, 2025

Sjors Provoost introduced a discussion on the progression of BIP370, aimed at enhancing the Partially Signed Bitcoin Transactions (PSBT) standard for backward compatibility and allowing new additions to transactions. The slow adoption and review by the community have been noted, despite Bitcoin Core's integration efforts through pull request 21283 and the challenges faced by Core Lightning in maintaining compatibility. For those interested in deeper engagement with BIP370, resources and forums for discussion are available at [BIP370 Proposal](https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki), [BIP174 Standard](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki), [Bitcoin Core Pull Request 21283](https://github.com/bitcoin/bitcoin/pull/21283), and [Stack Exchange discussion](https://bitcoin.stackexchange.com). Andrew Toth discussed a draft for a Bitcoin Improvement Proposal (BIP) that introduces a method for generating provably unspendable keys using a taproot internal key, aiming at enhancing security and privacy within the Bitcoin ecosystem. The proposal encourages community engagement and offers resources for further exploration and contribution to the discussion, with notable references including [Delving Bitcoin discussion](https://delvingbitcoin.org/t/unspendable-keys-in-descriptors/304) and the [GitHub pull request](https://github.com/bitcoin/bips/pull/1746). This effort highlights the community's commitment to advancing Bitcoin's infrastructure through collaborative and open-source development.

Jan 6 - Jan 12, 2025

Ava Chow announced the release of Bitcoin Core version 28.1, featuring enhancements like new peer-to-peer (P2P) configuration options and improved compatibility across various operating systems. This version also addresses certain bug fixes, introduces performance improvements, and updates translations. Users are advised to follow specific upgrade instructions, particularly when migrating from older versions, and can download the update from [Bitcoin Core's official website](https://bitcoincore.org/bin/bitcoin-core-28.1). Significant technical advancements include modifications to address port collisions and improvements in key handling and build systems. In a separate discussion, mcelrath explored the development of covenant-based solutions for Bitcoin mining pools, focusing on secure and accurate transaction management without custody risks. By leveraging covenants, the proposal aims to ensure theft-proof payouts in alignment with a "can't-be-evil" philosophy, offering an alternative to the [FROST federation](https://github.com/pool2win/frost-federation) model. These covenants would enforce specific transaction paths, include safeguards against pool failures, and adjust for dynamic payout changes, highlighting a proactive approach to enhancing transaction security within the Bitcoin ecosystem. Finally, cdecker addressed the dynamics of channel finalization within blockchain networks, emphasizing the limited impact of attack strategies aimed at disrupting this process. The discussion highlighted mechanisms allowing victims to counter outdated updates published by attackers effectively, suggesting that collusive attacks requiring majority control are unlikely to achieve indefinite censorship. This analysis underscores the resilience of blockchain systems against such disruptions, though it acknowledges vulnerabilities in systems reliant on timelock or CSV mechanisms. For more detailed insights, visit [this discussion](https://delvingbitcoin.org/t/broken-multi-party-eltoo-with-bounded-settlement/1364/4).

Dec 30 - Jan 4, 2025

Significant enhancements were made to the Bitcoin covenants support wiki in late November 2024, informed by developer feedback which introduced a new category LNHANCE and improved the resource's accuracy with revisions such as terminology adjustments, the addition of Bitcoin Improvement Proposal (BIP) drafts, and a rationale column. Feedback from Murch and Gloria, highlighted in the bitcoin optech podcast episode 333, contributed to the development of a dedicated page listing use cases and prototype links, emphasizing the exclusion of cases enabled solely by OP_CHECKSIGFROMSTACK. Moderation efforts to ensure the integrity of information were bolstered by granting Rearden moderator permissions, amidst discussions highlighting limited interest in SIGHASH_APO among developers and unanimous support for OP_CHECKSIGFROMSTACK, indicating areas for further exploration and the need for achieving technical consensus on covenant proposals ([source](https://gnusha.org/pi/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac=@protonmail.com/T/#m89c8e1e4ee3f1ec1dc638fdc62d24444be668cb0)). A revealed bug in Bitcoin Core's block-building algorithm was identified by Ismael Sadeeq, causing underutilization of block weight and sparking a proposed Pull Request (PR) to correct the generation of block templates. Analysis covering over 107,313 blocks from December 2022 to December 2024, demonstrated most mining pools adhere to default settings, with exceptions like Ocean.xyz and F2Pool, which either exceeded the limit or optimized usage, indicating a need for correction to align actual block weights with theoretical expectations and improve mining efficiency ([source](https://delvingbitcoin.org/t/analyzing-mining-pool-behavior-to-address-bitcoin-cores-double-coinbase-reservation-issue/1351)). John Law's implementation of relative timelocks in payment channels enhances operational security by using dual "lanes" for managing timeouts and employing TXID stability, showcasing an innovative approach to transaction management within payment networks. This system's design underscores the potential of leveraging txid stability for improving the functionality and reliability of payment channels ([source](https://delvingbitcoin.org/t/contract-level-relative-timelocks/1353/2)). The Delving website's user engagement showed a significant upward trend from January 2023 to December 2024, with a notable increase post-August 2023, even after implementing an upgrade to filter out non-genuine traffic, suggesting content generation might influence visitation patterns. This growth underscores the dynamic nature of online platform engagement and the impact of content on attracting or retaining site visitors ([source](https://delvingbitcoin.org/t/end-of-2024-site-statistics/1356)).

Dec 23 - Dec 28, 2024

The Bitcoin development community, spearheaded by figures such as Jeremy Rubin, James O'Beirne, and Salvatore Ingala, is actively exploring enhancements to CheckTemplateVerify (CTV) with proposals like `OP_TEMPLATEHASH` and `OP_INPUTAMOUNTS` for more sophisticated contract structures, including vault withdrawals. These advancements aim to overcome limitations in current CTV vaults by enabling flexible transactions and better security features without the need for state-carrying covenants or intricate introspection. For an in-depth understanding, a comprehensive guide is provided at [this link](https://gist.github.com/moonsettler/d2369e043473c42ff7fa52878dd064a5). In another discussion, a proposal mandates that Bitcoin miners include at least 0.1% of transactions from the oldest in the mempool in every block mined, targeting mining centralization and transaction censorship issues. This initiative seeks to ensure democratic processing by prioritizing transaction age over fees, thereby promoting fairness and enhancing censorship resistance within the Bitcoin network. The specifics of this proposal can be explored further at [this source](https://gnusha.org/pi/bitcoindev/f1a0153b-3142-4e01-a68e-92c458762b89@dashjr.org/T/#mc0ab2bf99af67117f9cb23eca68107d7bccea3e1). Jeremy Rubin revisits the concept of soft forks with expiration terms for protocol upgrades, advocating for a balance between innovation and security in blockchain and cryptocurrency developments. This approach aims to mitigate long-term risks by allowing temporary solutions to vulnerabilities, enabling future improvements or reversals based on emerging insights or technologies. The detailed discussion on the benefits and challenges of implementing such time-bound strategies in protocol management is available at [DelvingBitcoin](https://delvingbitcoin.org/t/transitory-soft-forks-for-consensus-cleanup-forks/1333). The Armenian Crypto Project (ARMCP) emerges as a significant initiative, aiming to integrate cryptocurrencies into daily transactions and the broader financial systems by addressing regulatory and operational challenges. Through platforms like ARMCP_Cryptoblog and tools including ARMCP_Token and ARMCP_Desk, ARMCP is creating a more accessible, secure, and transparent ecosystem for cryptocurrency usage and education. This project's future directions and its efforts to simplify cryptocurrency integration into global finance are detailed at [ARMCP.net](http://ARMCP.net).

Dec 16 - Dec 22, 2024

The recent discussions within the Bitcoin development community highlight significant advancements and challenges in blockchain technology, focusing on transaction fees, software updates, hash rate growth, protocol vulnerabilities, censorship in ecash, and consensus algorithms. Stutxo et al. delve into the limitations of OP_CTV transactions in adjusting fee rates, suggesting innovative solutions like CPFP on anchor outputs to mitigate fee market sensitivity, detailed in discussions on Bitcoin's evolving transaction framework ([Bitcoin Development Mailing List](https://gnusha.org/pi/bitcoindev/5565b149-48b7-4823-9363-89cfd70ecf09n@googlegroups.com/T/#u#mc0ee57c9af3867490c1cc9fbe0b4187b6b441863)). Ava Chow announces the availability of Bitcoin Core version v28.1rc2, emphasizing the importance of community engagement and feedback in the pre-release phase to ensure software reliability and security ([Bitcoin Core’s official site](https://bitcoincore.org/bin/bitcoin-core-28.1/test.rc2/)). Anders raises an alarm over the potential double exponential growth of the Bitcoin hash rate, questioning the sustainability of the current difficulty adjustment mechanism and urging the community to explore long-term solutions ([Bitcoin Development Mailing List](https://gnusha.org/pi/bitcoindev/ab246ea3-36ae-4c87-b4d1-32b0ec4f2603n@googlegroups.com/T/#m03eb94cf0488aa80a78aeb2fd59ae5393924983c)). Meanwhile, discussions on vulnerabilities in Wasabi & GingerWallet and CoinJoin protocols reveal significant deanonymization risks, highlighting a broader dialogue on balancing privacy-enhancing technologies with security and user trust ([GitHub repository](https://github.com/)). The debate around ecash and its susceptibility to censorship through P2PK mechanisms and KYC requirements underscores tensions between regulatory compliance and preserving user autonomy, pointing to a discrepancy between ecash's promise and its implementation ([Bitcoin Development Mailing List](https://gnusha.org/pi/bitcoindev/51eb0cc8-c9e0-4a50-9928-461f5f13264en@googlegroups.com/T/#m9a77a811b028160ad982a9a9d57571ecd331911a)). Lastly, zawy introduces Braidpool's difficulty algorithm, proposing a DAG-based consensus mechanism as a more efficient alternative to existing methodologies, showcasing the ongoing innovation and the complex balance between efficiency, security, and decentralization in blockchain technology ([Fastest Possible PoW via Simple DAG](https://delvingbitcoin.org/t/fastest-possible-pow-via-simple-dag/1331)).

Dec 9 - Dec 15, 2024

Recent discussions within the Bitcoin community highlight significant advancements and proposals aimed at enhancing the network's security and user experience. Weikeng Chen emphasizes the benefits of implementing an "OP_SUCCESS" opcode in Bitcoin script, simplifying the development of fraud proofs by marking script execution as successful upon its activation, a move supported by the utility outlined in Rusty Russell's article on scriptPubkeys ([source](https://gnusha.org/pi/bitcoindev/Z1dp0Jtbrkcf7Roi@console/T/#m83eadd98e637a1ec3d2da94644256997a901892c)). In parallel, Bitcoin Error Log, under the pseudonym John Carvalho, proposes a significant shift in Bitcoin's unit representation to simplify transactions and enhance the user experience by treating the smallest indivisible unit as "one bitcoin," aiming to eliminate confusion and simplify mental arithmetic ([source](https://gnusha.org/pi/bitcoindev/CAE2fw6tjVQQT4mpvec2kQg45eLS7VemzQgUfW7Pghdk_Si3PpA@mail.gmail.com/T/#u#m0d898700e0c21764380a75952b3b901866b63713)). Matt Corallo introduces a discussion on the robustness of Bitcoin's signature scheme against quantum computing threats, advocating for the adoption of hash-based signatures like SPHINCS/SPHINCS+ to secure the network in the post-quantum era. This approach leverages taproot to build a scheme providing security without immediate action from wallet developers or users, despite the acknowledged potential threats quantum computing poses ([source](https://gnusha.org/pi/bitcoindev/52f3bfc0-9446-4400-bf7a-7e38e5777c56@dashjr.org/T/#m8c9407a48d3358be40fb94ab512c3e72b95e17cc)). Concurrently, an identified vulnerability in older versions of major Lightning Network implementations underscores the ongoing challenge of securing offchain contract protocols against potential exploits, with updates released to mitigate risks associated with transaction fee manipulation ([source](https://delvingbitcoin.org/t/disclosure-irrevocable-fees-stealing-from-ln-using-revoked-commitment-transactions/1314)). Lastly, QbitsCode's proposal for integrating Post-Quantum Cryptography (PQC) into Bitcoin Core addresses the imminent threats posed by quantum computing advancements. By incorporating core PQC algorithms like Kyber, FrodoKEM, and NTRU, this initiative aims to ensure the long-term security of Bitcoin against sophisticated quantum attacks, reflecting a proactive approach to maintaining the cryptocurrency's resilience ([source](https://delvingbitcoin.org/t/implemented-post-quantum-cryptography-pqc-feature-into-bitcoin-core/1320)).

Dec 2 - Dec 6, 2024

Antoine Riard's analysis uncovers a transaction-relay jamming attack threatening bitcoin's time-sensitive contracts, especially impacting lightning channels by exploiting Bitcoin network's transaction mechanisms. This issue, initially overshadowed by other lightning protocol concerns, resurfaced due to its implications on network security, describing two attack variants: "high overflow" and "low overflow," each affecting transaction propagation and processing capabilities differently. Proposed mitigation strategies include enhancements by lightning node operators and protocol developers, emphasizing the need for base-layer solutions for comprehensive security. The report, tracing its developmental timeline from 2020 to a public disclosure in November 2024, underscores the evolving understanding and strategic responses to such network vulnerabilities. [Read more](https://gnusha.org/pi/bitcoindev/CALZpt+EptER=p+P7VN3QAb9n=dODA9_LnR9xZwWpRsdAwedv=w@mail.gmail.com/T/#u#m4fcd81d3fbf25a2571b51eba2221cea7238279cd). Ava Chow announces the availability of Bitcoin Core version v28.1rc1 release candidate binaries, urging the community to participate in testing to ensure the software's stability before its final release. The update, significant for its enhancements and bug fixes, is a precursor to the official version v28.1, aiming to bolster the Bitcoin network's efficiency and reliability. This step reflects the ongoing efforts to refine Bitcoin Core, facilitating user engagement through accessible downloads and comprehensive release notes. [Learn more](https://bitcoincore.org/bin/bitcoin-core-28.1/test.rc1/). Securitybrahh's discussion highlights the debate over Bitcoin and Monero's roles in digital finance, particularly focusing on fungibility and privacy concerns that influence their suitability as digital cash. This conversation sheds light on the technical and philosophical differences between Bitcoin and Monero, exploring potential protocol enhancements like CTV and OP_CAT to improve Bitcoin's functionality. The discourse reflects broader community contemplation on achieving the ideal balance between transparency and privacy in cryptocurrency transactions. [Explore further](https://delvingbitcoin.org/t/op-cat-vs-op-ctv-vs-xmr/1303). Ariard's report on Bitcoin's transaction-relay vulnerabilities has prompted a request for a CVE ID, indicating the serious implications of the identified flaws on Bitcoin use-cases, including Lightning. This effort to formalize and address the vulnerability underscores the critical nature of secure transaction relay mechanisms within the Bitcoin ecosystem. [Read the full report](https://ariard.github.io/). SCrypt-ts's development of a smart contract for hashrate escrow mimics Bitcoin's Drivechain concept without requiring major protocol upgrades, showcasing innovative uses of OP_CAT for sidechain functionality. This approach, enabling new features and experimental technologies via sidechains while maintaining Bitcoin's core stability, exemplifies the potential of smart contracts to expand Bitcoin's capabilities without altering its foundational protocol. [View the code](https://github.com/sCrypt-Inc/cat-contracts/blob/master/src/contracts/driveChain.ts).

Nov 25 - Nov 29, 2024

Jeremy proposes a novel method for implementing Bitcoin covenants without altering the blockchain's native protocol, utilizing covenant emulators and signing servers. This approach relies on oracle signers depositing bonds, which are at risk if they authorize transactions violating covenant rules, ensuring compliance through financial penalties. The detailed framework and operational mechanics of this system are explored in a comprehensive paper available at [Jeremy's Paper on Bitcoin Covenants](https://rubin.io/bitcoin/2024/11/26/unfed-covenants/). A new initiative, as discussed by /dev /fd0, seeks to consolidate opinions from Bitcoin developers on covenant proposals, aiming to build consensus for future soft forks through a collaborative wiki page. This endeavor reflects the process used for SegWit support, with the wiki page inviting developers to contribute towards refining opcodes and sharing insights, particularly regarding OP_CTV, to enhance Bitcoin's functionalities such as covenants for pools and coinjoin improvements. The presentation detailing the rationale behind OP_CTV and its benefits can be found at [Rationale for OP_CTV](https://notes.dunst.be/slide//2/slide/view/Ekky-cAegV9dSOaNOjH9TStNOmAnrhDDc9hxHlmRs5M/embed/present/). Ajtowns introduces the concept of "Flexible Coin Earmarks," a method allowing the value of a single coin to be earmarked for various purposes, facilitating conditional spending within financial mechanisms like lightning networks, vaults, and payment pools. This approach promises to streamline transactions and improve security by enabling dynamic fund management and reducing the complexity of multi-party transactions. The potential for this concept to revolutionize blockchain applications is further discussed, with the full conversation available at [Flexible Coin Earmarks Discussion](https://delvingbitcoin.org/t/flexible-coin-earmarks/1275). In collaboration between sCrypt and StarkWare, a demo bridge covenant on Bitcoin illustrates the feasibility of connecting the Bitcoin blockchain to the Starknet Layer 2 network, demonstrating efficient management of deposits and withdrawals through a batched transaction system. This bridge utilizes a recursive covenant script and Merkle trees for secure transaction processing, with the detailed implementation and codebase accessible at [GitHub Repository for Bridge Covenant](https://github.com/Bitcoin-Wildlife-Sanctuary/scrypt-poc-bridge), showcasing a significant step towards enhancing Bitcoin's interoperability and smart contract capabilities.