Crypto Insights

Peter Todd on Determining Block Storage Size

• Bitcoin uses a structured approach for data storage through blk*.dat files, with sizes ranging between 128MB to 134MB. How was this range determined, and are there tests proving this to be the most effective limit?

• Peter Todd responds: The upper limit is mainly due to compatibility with old file systems, while the lower limit is influenced by technical difficulties of managing a large number of files in a single directory. Overall, this value is the result of extensive testing and consideration to optimize efficiency and performance, balancing the avoidance of the file system limits and prevention of directory overcrowding.

• Vitalik Buterin has recently published an article discussing the block size, titled Some reflections on the Bitcoin block size war.

Is BIP 21 Obsolete? Updates to Include Segwit and Taproot Addresses

• BIP 21 currently mandates only base58 addresses and does not formally support Segwit or Taproot addresses in URIs. However, a significant portion of BIP 21-compliant wallets are already advancing the use of Segwit and Taproot addresses in transactions. Additionally, with the advent of Silent Payments and BOLT 12, there's a growing need for a standard way to include extra payment instructions in URIs, which BIP 21 should document.

• Bitcoin Core developer Matt Corallo proposes a PR, detailing the updates to ensure BIP specifications align with advancements in transaction technology without hindering existing wallet functionality.

BIP 352: Partially Signed Bitcoin Transactions (PSBT) Support

• This post discusses support for spending and sending silent payment outputs in Partially Signed Bitcoin Transactions (PSBTs).

• Additionally, the proposal touches upon an innovative idea: OutputGenerator may not need direct access to private keys, but could operate using a mechanism similar to "ECDH sharing," an encryption structure allowing secure collaboration without fully revealing keys.

BIP for Testnet 4: Saying Goodbye to Testnet 3's Block Storms

• The new Bitcoin Testnet 4 aims to replace Testnet 3, with improvements to consensus that make attacks using only CPU mining impractical.

• Testnet 3, running for 13 years, started at approximately block 2.5 million, with a current block reward of ~0.014 TBTC. Its major issue is exploitation for fraudulent airdrops, leading to a significant influx of non-developers asking developers for TBTC, followed by block storms where three years' worth of blocks were mined in a few weeks, nearly rendering the network unusable.

• For more information on block storms, refer to Bitcoin Testnet Block Storms. For perspectives against valorizing testnet coins, refer to Griefing Bitcoin's Testnet.

Light Client Protocol for Silent Payments

• For sending silent payments (SP), wallet software only needs to add certain cryptographic primitives. However, to receive SP, one must also be able to access information about every on-chain transaction compatible with SP, which is trivial for Bitcoin full nodes, but requires additional functionality for lightweight clients.

• This protocol includes a service provider to build a public key per-block index for use with SP. Clients download this index with a compact block filter for the same block, compute a local tweak for each key (or set of keys), and determine if the block filter has a payment to their corresponding tweaked keys. If so, the client downloads additional block-level data to learn about the received amounts and how to use them later.

New Descriptors for Taproot Spending Conditions

• rawnode(HEXHASH) takes the hash of a Merkle tree node, be it internal or leaf, allowing wallets or other scanners to find specific output scripts without knowing the exact tapscript in use.

• rawleaf(HEXSCRIPT,[HEXLEAFVER]) functions similarly to existing raw descriptors, used for including scripts not representable by templated descriptors. Its primary distinction is the ability to specify tapleaf versions that differ from the tapscript default outlined in BIP 342.

Using BOLT12 in the Lightning Development Kit (LDK)

• BOLT12 (also known as Offers), drafted by Rusty Russell, provides enhanced privacy, reusable payment codes, refunds, and more. These functions are natively supported over the Lightning Network, facilitated by techniques like onion messages and route blinding, without requiring additional servers.

• This article elucidates the integration of BOLT12 within the Lightning Development Kit (LDK).

Enhancing Bitcoin Baselayer Privacy with Dandelion++

• Dandelion, a propagation protocol (BIP 0156), aims to enhance transaction routing privacy by obfuscating the origin. Proposed in 2018, it has evolved through Dandelion++, Dandelion Lite, and Clover, and has been implemented in privacy-focused currencies like Monero and protocols such as Mimblewimble. Due to concerns over potential DoS attacks, Dandelion has never been implemented on Bitcoin.

• This article examines the benefits and trade-offs of Dandelion++ and suggests that revisiting the protocol could be pivotal in maintaining Bitcoin's censorship resistance.

Image Source: therage.co

Understanding AVM, Atomicals Protocol's Virtual Machine

• AVM leverages Bitcoin’s limited storage space and OP Codes framework by introducing a special encoding and decoding method within a sandbox environment for each Bitcoin mainnet transaction.

• This sandbox comes with an indexer, sandbox parser (instruction set), global database, etc., which can independently complete a whole set of functions such as asset storage and transaction status recording. It is equivalent to embedding a dynamic 'state machine' in the Bitcoin mainnet, facilitating complex smart contract processing and state synchronization and verification.

• However, AVM’s reliance on Bitcoin Script for encoding storage and OP Codes for transaction execution means it is subject to the performance limitations of the Bitcoin mainnet.

Top Reads on Blockchain and Beyond

Griefing Bitcoin's Testnet

• The author explicitly opposes using Bitcoin Testnet3 for anything of real value.

• He recalls his experience of mining TBTC on Testnet 3, which eventually led to a block storm. Once the storm mode was activated, it could easily surpass 20,000 blocks per day. Normally, the testnet produces about 150 blocks per day. As shown in the image below:

Image Source: blog.lopp.net

Bitcoin Testnet Block Storms

• The background of block starms is mining difficulty retargeting, which is based on the difficulty of the previous block. “On testnet when the block before the retarget (block #2015, #4031, etc) is a difficulty 1 block due to the special minimum difficulty rule, the retarget logic for the next block will run based upon the assumption that the difficulty for the entire previous 2015 blocks has been 1! … once the difficulty gets reset to 1, even a cheap ASIC like an S5 can mine multiple blocks per second.”

Some Reflections on the Bitcoin Block Size War

• Vitalik shares his thoughts after reading two books on the Bitcoin block size war. They represent two opposing viewpoints: Jonathan Bier's The Blocksize War, advocating for small blocks, and Roger Ver and Steve Patterson's Hijacking Bitcoin, which favors large blocks.

• “I found myself agreeing with Ver more often on big-picture questions, but with Bier more often on individual details. In my view, big blockers were right on the central question that blocks needed to be bigger, and that it was best to accomplish this with a clean simple hard fork like Satoshi described, but small blockers committed far fewer embarrassing technical faux pas, and had fewer positions that led to absurd outcomes if you tried to take them to their logical conclusion.”

• “The combined picture that I get from reading these two books is a political tragedy that I feel like I have seen over and over again in all kinds of contexts, including cryptocurrencies, corporations and national politics: One side monopolizes all the competent people, but uses its power to push a narrow and biased perspective; the other side correctly recognizes that something is wrong, but engulfs itself in a focus on opposition, failing to develop the technical ability to execute on its own.”

Digital Objects, Economies, and the Challenge of Meaning: a Beginning

• The Value Spectrum:

  • Goods: Items for immediate needs that do not accrue value

  • Assets: Held for future benefits with potential for value increase

  • Collectibles: Sit between goods and assets, gaining value over time and through meaning

• The Role of Meaning: Transforms goods into collectibles or assets, providing stability against volatility

• Digital Object Challenges:

  • Familiarity and Usage: Require more widespread recognition and consistent use

  • Tangibility: Face the challenge of being non-physical, affecting sensory engagement

  • Fundamentals: Need to meet human needs or have a clear, widely accepted value to be considered assets