Crypto Insights

Messari Released a Comprehensive Overview on Nervos Network CKB

• CKB improves Bitcoin’s programmability with its innovative innovative Cell Model and CKB-VM, expanding the UTXO framework.

• The RGB++ protocol brings an unprecedented capacity for smart contract execution and asset issuance to Bitcoin, expanding its utility and establishing itself as the execution and data availability layer for Bitcoin.

• Since the RGB++ protocol’s mainnet launch in April 2024, there has been a significant increase in Bitcoin-based asset issuance projects and a spike in CKB's on-chain activities. New address growth reached nearly 400,000 in April, marking a 181% monthly increase.

• The report also mentions the potential of projects such as UTXOStack and CKB Lightning Network to further improve Bitcoin scalability.

RGB++ CKB Bitcoin SPV Contract Passed Code Audit

As one of the core components of RGB++, the CKB Bitcoin SPV Contract has recently undergone and passed a code audit conducted by ScaleBit (@ScaleBit).

Second Look at Weak Blocks

• Introduced to complement the mempool/relay framework, weak blocks offer insight into pending transactions miners are prioritizing, potentially allowing more precise fee adjustments for timely inclusion in the blockchain.

• The idea poses challenges in managing multiple weak blocks simultaneously and deciding if these blocks should compete chain tips or be sequentially organized.

• Discussions on weak block management focus on strategies to keep multiple weak blocks at the same height.

Ongoing Discussion on Silent Payment Using PSBT

• The focus of recent discussion is on using a technique where each signer generates an ECDH (Elliptic Curve Diffie-Hellman) share and provides a compact proof that the shared secret has been correctly generated. These shared secrets and their corresponding proofs are added to the input of the PSBT (Partially Signed Bitcoin Transaction). Once the ECDH shares and proofs from all signers are received, they are combined with the recipient's silent payment scan key to generate the actual key placed in the output script (if multiple silent payments are made in the same transaction, multiple keys will be generated with multiple output scripts).

• After the transaction's output scripts are known, each signer reprocesses the PSBT to add their signature. This means that completing the PSBT involves two rounds. However, if there is only one signer for the entire transaction (for example, if the PSBT is sent to a single hardware signing device), the signing process can be done in one round.

On Introducing 64-bit Arithmetic Operations to Enhance Bitcoin Script Functionality

• The 64-bit arithmetic soft fork was proposed earlier this year to extend the computational range and flexibility for scripts, broadening the types of applications and smart contracts that can be developed on Bitcoin.

• Recently, the proposer introduced a CScriptNum extension prototype, re-enabling the multiplication and division opcodes OP_MUL and OP_DIV in the Bitcoin script; and supporting 8-byte calculation with arithmetic and comparison opcodes without introducing any new opcodes. By reusing existing opcodes based on SigVersion, the underlying implementation type in CScriptNum is changed from int64_t to __int128_t.

• However, this proposal changes the behavior of CScriptNum, introducing potential consensus risks when interacting with old nodes.

LND Onion Routing Vulnerability to DoS Attack Causing Out-of-Memory Crashes

• Lightning Network developer Matt Morehouse disclosed a vulnerability affecting versions of LND prior to 0.17.0, allowing a DoS attack where malicious onion packets can cause a node to crash due to out-of-memory (OOM).

• The core of this vulnerability is that the LND node preallocates memory buffers based on the encoded length of incoming messages, without verifying whether this length exceeds the maximum length allowed by the protocol. Attackers can exploit this by setting the length of the onion payload message up to 4GB, overwhelming the node with excessive allocations for these payloads, leading to immediate out-of-memory crashes.

Bitcoin L2 Systems: Exploring Market Demand and Interaction of Blockspace Resource Use

• Market dynamics and blockspace utilization: The use of Bitcoin blockspace is influenced by market dynamics, with economic factors determining how and when blockspace is used. Different Layer 2 systems impact each other, and the market ultimately decides the feasibility of various uses.

• System design and interaction: Systems built on Bitcoin must consider the efficient use of blockspace, transaction frequency, and time sensitivity. These significantly affect interactions between systems and their relationship with the broader blockchain network, especially in high-fee environments.

• Security, cost, and market choice: Users must balance security, cost, and centralization pressures when choosing different system architectures. The evolution of Bitcoin's fee market and the long-term sustainability of various systems depend on the market's wise decisions and how the underlying protocol adapts to these different system designs.

Rollup: Bitcoin-Native Rollup Design

• Brollups is a Bitcoin-native rollup design that operates with a native Bitcoin peg without requiring any changes to the Bitcoin protocol. The peg is enforceable on-chain and can be unilaterally redeemed at any time.

• A Brollup is operated by one or a group of operators who provide liquidity to the protocol and advance the rollup state by regularly chaining Bitcoin transactions.

Rollups Competitive Landscape. Image Source: brqgoo.medium.com

Bridging Bitcoin and Ethereum: BOB's Hybrid Layer 2 Solution

• BOB is a hybrid Layer 2 solution that combines the security of Bitcoin with the versatility of Ethereum, aiming to make building on Bitcoin easier.

• BOB's security is ensured by Bitcoin and integrated into the Bitcoin stack through lightweight clients, while simultaneously functioning as a rollup on Ethereum to facilitate use by the Ethereum community.

Bulletproofs++: A Step Towards Fully Unlinkable Transactions With Multiple Asset Types

• Blockstream's Andrew Poelstra shared research on the Bulletproofs++ scheme. It is a zero-knowledge proof that enhances inherent privacy with a smaller and more efficient design, improving upon the previous Bulletproof scheme iterations and bulletproof range.

Turning Waste into Treasure: Heat Your Room with Mining Waste Heat

• A 100-year-old house, which was heated by a hydronic boiler and radiator system. The author designed and create a new electrical system on top of the existing heating infrastructure, which is powered by the waste heat produced by mining.

• The author claims to have no experience with plumbing, soldering copper pipes, or maintaining their hydronic system before this project, only being familiar with power electrical systems and having added a few outlets and switches. The author plans to open-source the project to provide a reference for anyone interested in trying.

Image Source: stacker.news/items/480613

Top Reads on Blockchain and Beyond

Impacts of DBcache Size on Bitcoin Node Sync Speed

• DBcache refers to a write buffer (not a traditional cache), preventing users from needing to regularly write the current state of the UTXO set to disk. DBcache can be a performance improvement when synchronizing multiple blocks. The article examines the trade-offs between different DBcache sizes during a full Bitcoin node synchronization;

• Key findings:

  • Synchronization speed test: Tests with different DBcache sizes revealed that a larger DBcache (28GB) is 24% faster than the default size (450MB), taking 452 minutes and 597 minutes, respectively;

  • Risk of interruption: If a node crashes before the initial full synchronization is completed and the DBcache is set high without being fully utilized, the UTXO set is not written to disk, and restarting synchronization will require re-indexing the blockchain;

  • SSDs and operating systems use free RAM for filesystem caching, which may reduce the need to adjust DBcache. However, tests show that the performance improvement of a large DBcache becomes more significant after reaching a certain block height.

Project Got Hacked and User Funds Were Stolen

• At Bitcoin++ hackathon, the author's project drew interest, but he neglected to review the code thoroughly and audit the core flow of the application. Due to the open-source nature of the code, the project was quickly hacked.

• The author documented this experience, how it was subsequently fixed, and the lessons learned, reminding other developers of the importance of security awareness and the necessity of code review.

Research Paper: FE’d Up Covenants

• Abstract: Covenants are a way of expressing restrictions on Bitcoin. Covenants, while possible to implement as an extension to Bitcoin, do not exist natively. To enable them requires the Bitcoin community to agree upon upgrades such as CTV, CAT, CSFS, and more. This paper serves to demonstrate at a high level how covenants could be introduced to Bitcoin without a soft fork using Functional Encryption and Zero Knowledge Proofs.