Libauth

An ultra-lightweight, zero-dependency JavaScript library for Bitcoin Cash, Bitcoin, and @bitauth applications. #BCH #Bitcoin

[Libauth @libauth]

Libauth v2.0.0 is now available! 🚀

Libauth is an ultra-lightweight, zero-dependency JavaScript library for Bitcoin Cash, Bitcoin, and @bitauth applications.

Links in bio, read on for release notes:

Libauth is now a pure ESM package, simplifying the developer experience by allowing WASM crypto to be instantiated internally/automatically by default 🎉. This refactor also simplifies the usage of and types surrounding Libauth virtual machines and compilers, and several other APIs have been improved.

New, dedicated Telegram channels are also available for Libauth release announcements and Libauth developer discussions.

Simplified Virtual Machine Types

Previously, Libauth VMs were very strictly-typed such that error messages and opcodes used chain-specific enums (e.g. AuthenticationErrorBCH and OpcodesBCH). While this configuration did ensure that VMs and VM results were strictly-typed with chain information, the configuration ultimately made library components much harder to remix without deep knowledge of TypeScript's type system. In both cases, such type information rarely catches downstream implementation bugs:

- Differing opcode enums effectively only narrow the real-time type from number to 0 | 1 | 2 | ... | 254 | 255.
- Differing error enums only offer a slight benefit in making error matching slightly simpler, and they present a significant disadvantage in that they preclude the contextualization of errors – each error string must be fully defined at compile time.

In both cases, the differing types offer only very marginal benefit at the cost of exceptional added complexity (widespread proliferation of generic types throughout the codebase). This refactor migrates the opcode type to number and the error type to string | undefined, leaving the opcode and error enums primarily as a form of documentation.

Simplified VM Usage

Transaction validation infrastructure is now a part of each VM instance, so transaction validation is as simple as vm.verify({ transaction, sourceOutputs }) (returning either true or an error string). This behavior offers individual VMs full control of transaction parsing and validation, allowing Libauth VMs to implement proposals for significant modifications like new transaction formats or high-level transaction validation changes.

Simplified VM Operations and Instruction Sets

Beginning with this version, Libauth will no longer maintain support for defunct VM versions. For example, BCH_2019_05 was an upgrade which enabled Schnorr signature support in CHECKSIG and CHECKDATASIG and a clean-stack exception for SegWit recovery. The BCH_2019_05 VM was replaced without a network split by the BCH_2019_11 upgrade, meaning BCH_2019_05 is no longer in use by any public network. As such, relevant code paths, flags, and other VM-specific functionality for BCH_2019_05 has been removed to simplify currently supported Libauth VMs. (Of course, historical implementations will always remain available in previously-released versions of Libauth.)

Additional Changes

- Default crypto interface instances – because Libauth is now pure ESM, all of Libauth's WebAssembly cryptography implementations can now be automatically instantiated internally by the library. All Libauth methods that require crypto now use these automatically-instantiated implementations by default (as a default parameter), but consumers can opt-out of the behavior by providing a replacement implementation (and build tools that support dead code elimination/tree shaking of default parameters can automatically drop the unused crypto implementations.) To support this functionality, the parameter ordering of many functions have been modified to shift crypto implementations to the end (as optional parameters).
- Secp256k1 never throws - the Secp256k1 interface previously threw errors, breaking from Libauth's convention of well-typed errors. All Secp256k1 methods now return error messages as strings where applicable.
- CashAssembly – is the new name for Bitauth Templating Language (BTL), the simple language used within Libauth templates.
- Expanded state available to VMs and compilers – VM and compiler operations can now access all raw contents of transactions and source outputs.
- Expanded capabilities of template scenarios – scenarios can now represent any transaction shape and generate full, serializable transactions.
- New VM bytecode test vector generation – Libauth includes a new vmb_tests test vector generation system to produce sets of cross-implementation test vectors as serialized transactions; this allows for sets of test vectors that fully test all transaction validation infrastructure without making assumptions about implementation internals.
- Improved CashAddress utilities – cash address utilities no longer require enums, hash lengths are measured in bytes rather than bits, and type is distinguished from typeBit.
- More consistent encoding/decoding utilities – Several decoding methods have been renamed and refactored to use the new ReadPosition API.
- More consistent error handling – all possible errors are surfaced in type signatures as strings.
- Consistent capitalization, naming corrections – some exports have been renamed to consistently use camelCase (for functions) or PascalCase (for types/interfaces), respectively. Several exports have been renamed for discoverability and consistency with other exports.

Finally, we're excited to share that Libauth has reached >1M annual downloads with consistent growth in daily downloads (see graph).

Thanks for reading – we can't wait to see what you build. 🚀

[Jason Dreyzehner @bitjson]

The May 2026 upgrade is now active on Chipnet at block 279,792! 🎉

This upgrade completes the restoration of Bitcoin Script on Bitcoin Cash (CashVM), making CashVM a simple, ultra-efficient, high-level programming environment for sound money.

Left: 2016 opcodes, right: 2026 opcodes 🔥 (source: https://t.co/DtwRUeTsCV)

Over the last decade, Bitcoin Cash has delivered:

• 2018: Opcode restoration (OP_CAT, OP_XOR, OP_DIV, OP_MOD, etc.),
• 2019: Schnorr signatures with multisig batch verification,
• 2020: Density-based signature limits,
• 2022: OP_MUL and introspection,
• 2023: Cross-covenant commitments (CashTokens),
• 2025: Density-based general limits and BigInts,
• 2026: Loops, functions, bitwise, and Pay-2-Script.

Each upgrade carefully preserved Bitcoin Cash's transaction-level parallelization, enabling global-scale, layer-1 throughput – without compromising Bitcoin Cash's scalability, decentralization, and censorship-resistance.

Fully-validating, archival BCH nodes run on consumer hardware and still outperform clusters of high-powered, centralized sequencers required by account-based networks.

With this upgrade, CashVM becomes even more powerful, allowing contract developers to efficiently implement post-quantum cryptography, homomorphic encryption, zero-knowledge proof systems, and more – without waiting for network upgrades.

Case Study: Quantumroot
Quantumroot is a quantum-secure vault contract design offering full 256-bit classical, 128-bit quantum security strength. Possible since May 2025, but made 10-100× more efficient by the 2026 upgrade: Quantumroot sweep transactions are 15% smaller per-UTXO than P2PKH wallets.

Upgrade Details

The 2026 upgrade includes four Bitcoin Cash Improvement Proposals (CHIPs):

Loops CHIP
Introduces the well-established, OP_BEGIN/OP_UNTIL loop construction to CashVM, bounded by the density-based limits activated in the 2025 upgrade. Loops eliminate duplication in repeated procedures, significantly reducing transaction sizes and enabling previously impractical constructions.

Functions CHIP
Enables factoring of contract bytecode into reusable functions with OP_DEFINE/OP_INVOKE, eliminating duplicated logic and reducing transaction sizes. Functions improve the efficiency of complex financial and cryptographic computations, including zero-knowledge proof verification, homomorphic encryption, post-quantum cryptography, and more.

Bitwise CHIP
Re-enables bitwise operations, including OP_INVERT for bit inversion, arithmetic shifts (OP_LSHIFTNUM and OP_RSHIFTNUM) for numeric values, and binary/logical shifts (OP_LSHIFTBIN and OP_RSHIFTBIN) for binary data. These operations allow CashVM contracts to more efficiently implement a variety of financial and cryptographic algorithms.

Pay-2-Script CHIP
Makes Pay-2-Script (P2S) outputs standard, enables longer token commitments (up to 128 bytes), and unifies the standard unlocking bytecode length limit with the consensus limit (10,000 bytes). These changes improve wallet ecosystem safety, simplify contract design, and reduce transaction sizes for many vault, multi-party covenant, and decentralized financial applications.Technical Specs

For more details, see the CHIPs:
- Loops: https://t.co/j3srDCzs1U
- Functions: https://t.co/iBblU1iZMC
- Bitwise: https://t.co/pb9VfV6veA
- Pay-2-Script: https://t.co/A87oonYh8J

[Jason Dreyzehner @bitjson]

In anticipation of future Zero-Knowledge Proof (ZKP) Bitcoin Cash covenants, I've been reviewing how to make implementation in wallets as practical and private as possible.

I expect now that many ZKP covenant systems can be fully supported by generalized "wallet engine" infrastructure, such that software which supports wallet templates will be able to simply import and use ZKP covenant wallet templates (create a wallet, scan for matching UTXOs, and deposit, transfer within, and withdraw from public ZKP covenants) with minimal integration work.

However, the Bitcoin Cash P2P protocol has two areas requiring improvements for better privacy in real-world usage:

- Transaction origin exposure – network-level adversaries can trivially identify the node which first broadcasts most transactions. Many end-user wallets are partially protected from network-level monitoring by broadcasting via a backend controlled by their wallet vendor or community-run Fulcrum servers (Electrum protocol), but this comes at the cost of leaking far more actionable data to those providers (who in many cases are also servicing "balance checks" and other queries that reliably de-anonymize all of the end-user's activity).

- Cleartext network communications – the Bitcoin Cash P2P protocol does not support any form of encryption, so network-level adversaries can very easily identify and track all activity, simplifying and lowering the cost of both censorship and attacks on privacy.

Some ideas I've reviewed:

A new "`ONION_TX`" P2P protocol extension:

We could add a Tor-like transaction broadcast protocol where the transaction is encrypted to a path of known "onion-capable" nodes. However, powerful network-level attackers could likely still correlate traffic in and out of circuits with timing analysis – at the very least, much of the rest of the network would need to upgrade to encrypted connections as well.

Additionally, it's very hard to protect against denial-of-service attacks: even if nodes temporarily remembered onion TXs they forwarded, and we added a backwards-propagating `ONION_ABUSE` message to allow nodes in the circuit to blame a misbehaving node, the originating node may always plausibly claim to be a victim of an earlier non-existent node. Compare that with our existing protocol, which is very byte-efficient at banning misbehaving peers for wasting bandwidth on invalid transactions. (And of course transaction fees impose a cost on valid transaction bandwidth.)

Note also that BCH nodes can already connect via Tor, which probably offers both better privacy and greater resistance to denial-of-service attacks (due to the size of the existing Tor network).

TLDR: An "onion" extension would be complex, easily abused, and ultimately less private than network-layer encryption + a deniable broadcast solution (Dandelion++ or Clover).

BIP324 opportunistic encryption:

Bitcoin Cash nodes could implement BIP324, an upgrade to add encryption to the existing P2P protocol.

If our only goal were to better protect traffic against powerful network-level adversaries, this solution seems hard to beat: maximally simple, pseudorandom bytestream, shapable for better censorship resistance, etc.

However, implementation is not trivial: it's a new, special-purpose protocol with relatively little ecosystem support (some scattered patches for various BTC software, early support in a few BTC-only libraries).

It's quite hard to justify this additional work and maintenance when compared to adopting a more widely-used stack like Noise or libp2p, for which better-reviewed libraries already exist in a variety of language/programming environments.

Further, even if encryption support were successfully deployed to 100% of BCH nodes, we'd still need solutions for transaction origin exposure – well-connected adversaries could still trivially identify originating nodes on the main network, and the status quo of wallets leaking private info to backend servers would remain unchanged.

In fact, even coupled with a deniable broadcast solution like Dandelion++ or Clover, practical privacy for most end-users would still remain highly vulnerable to trusted backends. To create plausible deniability in light client transaction broadcast, you need the light clients to also be plausibly participating in the deniable broadcast protocol, i.e. light clients with peer connections to other nodes and light clients.

Implementing BIP324 would bring encryption to the existing P2P network, but it wouldn't improve the privacy of most light wallets – for that we need to make it easier for light wallets to broadcast transactions directly over the P2P network (even if they still leak other info to backend servers rather than internally running pruned or SPV nodes).

TLDR: a partial solution to cleartext P2P communications, but at significant implementation cost, with little new practical privacy for most light wallets users.

---

Proposals for Bitcoin Cash:

With that background, I'd like to outline some solutions I'm exploring.

These might eventually become CHIPs to make them easier to talk about, but note that they're much "lower-stakes" than VM changes: there's no consensus or widely-coordinated upgrade needed here, nodes and wallets can choose to start or stop speaking protocols whenever they like, and it's likely we'll iterate a bit.

Implement `PTX` messages ("Clover")

In my opinion, Clover is a clear improvement over Dandelion++ – it's simpler, faster, more byte efficient, has fewer pitfalls, and offers overall better privacy to all network participants.

In short: nodes add a new `PTX` ("proxy TX") message type equivalent to the `TX` type, but quietly relayed based on some simple rules such that the network first "hears" it via the standard `INV` diffusion after a few hops.

When performed across encrypted connections, this offers similar privacy to an "onion" extension, but without the denial-of-service issues. Note that even the first peer to receive the `PTX` can't know if the originator was simply forwarding it, so they learn only slightly more than if they were passing along an onion-encrypted payload. However, with the payload visible, they 1) are not wasting bandwidth (they won't need to `GETDATA` the TX again later) and 2) can easily see if it's invalid and ban misbehaving peers.

Without encryption, the originator of each `PTX` message is still easily tracked by powerful network-level adversaries, but when combined with some P2P layer encryption solution (and perhaps if messages are padded to a fixed length), we get Tor-like privacy without the DoS exposure.

One BCH-specific detail: nodes must advertise in service bits whether or not they support `PTX`, and only forward `PTX` to other supporting nodes. With BCH's annual upgrades, we're likely to have great support relatively quickly, but it's important that `PTX` "support" remains optional (e.g. @ChaingraphCash probably won't implement the `PTX` forwarding behavior, so if nodes blindly selected a Chaingraph agent to send a `PTX`, propagation would be delayed until a previous node's timeout was triggered.) Some node implementations will never bother to implement, and that's fine.

Implement optional `libp2p` transport protocols:

The libp2p project seems to have come a long way in standardizing various transport protocols, implementing native libraries in a variety of languages, and resolving earlier resource exhaustion issues. A number of cryptocurrency projects now use libp2p, including Ethereum since 2023.

I'd love to see BCH node implementations experiment with using libp2p libraries to support the TCP + Noise + Yamux, WebTransport, and WebRTC libp2p transport protocols. This would unlock P2P network compatibility with the web platform, enabling:

- Web-based peers that can easily contribute bandwidth from any connection (like Tor's Snowflake project),
- Stronger censorship resistance: more protocol options to route around censorship/damage, and BCH traffic can blend in with video calls (WebRTC) and HTTP/3 (WebTransport),
- Strongly-private, PWA-based nodes and severless wallets,
- Simpler, JS-only P2P connection code in web-stack based software (e.g. wallets built with Electron, Tauri, Expo, React Native, Capacitor, etc.)

Rough sketch of the necessary parts:

- Reuse most of existing P2P message formats after libp2p handshakes – can simply remove the checksum field (as the transport layers handle message integrity). The `addr` message format would continue to enable "v1" P2P discovery.
- Extend the existing `version` handshake to enable immediately upgrading to libp2p WebTransport for the performance and encryption, or libp2p TCP for the encryption.
- Seeder support for JSON responses – we need some seeder (like BCHN's) to support listening on a port and returning the list via HTTP in JSON format. (Seeder operators should also set up HTTPS with Caddy or something.) The JSON response should only include nodes with libp2p interfaces enabled (and returned records should allow for opening WebTransport and/or WebRTC connections).

Long term, I hope to add support in @Libauth for locally running a fast-syncing pruned node in the browser, Node.js, Deno, Bun, etc. such that Libauth-based wallets can both participate in `PTX` ("Clover") broadcasting and scan for their own UTXOs without leaking info to backends (at the cost of local storage and bandwidth usage).

Clients running in Node.js, Deno, or Bun would bridge between v1 P2P nodes and libp2p-connected nodes to help bootstrap the libp2p-based network (stretch goal: a PWA and/or browser extension-based full node with support for ~1MB sub-block progressive knockout filters).

---

Does anyone see areas for improvement over PTX messages + encrypted libp2p transports?

I also posted this on Bitcoin Cash Research, ideas and feedback welcome.

[Mathieu Geukens @GeukensMathieu]

Chat GPT explains what you'd need to build a proper compiler for Bitcoin Script

@CashScriptBCH as only tool in the entire industry, has all of these, thanks to the integrated debugging with @libauth and step-by-step execution in the @BitauthIDE

Of all 7 items listed by GPT, only a 'visualiser tool' is suggestion we don't have yet.

[Jason Dreyzehner @bitjson]

The `next` branches of @libauth and @BitauthIDE now have draft support for OP_BEGIN/OP_UNTIL, OP_EVAL, and P2S. You'll see a some new UI for stepping through loops in the IDE too: (recording from locally-installed app, offline mode ✈️)

[Bitauth IDE @BitauthIDE]

@bitjson Debug in Bitauth IDE 🚀 https://t.co/Hy1kXQ2FWE

[Jason Dreyzehner @bitjson]

A chipnet transaction with 8×8 byte OP_MUL:
0xffffffffffffffff(-9223372036854775807)
0xffffffffffffffff(-9223372036854775807)
OP_MUL
0x0100000000000000ffffffffffffff3f(85070591730234615847396907784232501249)
OP_EQUAL
=> 0x01(1)

https://t.co/aWPb1Vt1f4

[Jason Dreyzehner @bitjson]

The May 2025 upgrade to Bitcoin Cash is now active on chipnet at block 227,228! 🎉 (0000000000b8dc4625844fa367b12317645fac7c9afbc5fb8def4025a6822c86)

This upgrade includes two Bitcoin Cash Improvement Proposals (CHIPs):

Targeted Virtual Machine Limits CHIP

The VM Limits CHIP retargets Bitcoin Cash's Denial-of-Service limits to extend compute for real contracts by more than 100x while reducing worst-case node compute usage by 50%. By reducing overhead, the retargeted limits simplify contracts, reduce transaction sizes, streamline contract audits, and improve overall security.

By improving contract efficiency, this upgrade also makes important use cases more practical, including post-quantum cryptography, stronger escrow and settlement strategies, zero-knowledge proofs, homomorphic encryption, and other crucial innovations for the future security and competitiveness of Bitcoin Cash.

Finally, this upgrade raises the bar by contributing new tooling and a cross-implementation benchmarking methodology to continuously verify node performance. Beyond empirically verifying the safety and correctness of the upgrade, these tools will simplify development of new production-ready implementations, prevent regressions in existing implementations, and reduce the cost of verifying implementation-specific software updates.

BigInt CHIP: High-Precision Arithmetic for Bitcoin Cash

The BigInt CHIP enables high-precision math for Bitcoin Cash, offering over 10x reductions in contract lengths and making previously-theoretical use cases immediately practical: more advanced automated market making and exchange protocols, decentralized stablecoins, collateralized loan protocols, cross-chain and sidechain bridges, zero-knowledge proofs, post-quantum cryptography, homomorphic encryption, and more.

This upgrade takes full advantage of Bitcoin Cash's fundamentally more scalable architecture to offer math capabilities which exceed those of Ethereum: "bare metal" performance, more byte-efficient transactions, far lower transaction fees, and protocol-level simplicity that eliminates whole classes of Ethereum contract vulnerabilities. These capabilities are available to Bitcoin Cash contracts on "layer one" – ensuring security, censorship resistance, and cross-contract compatibility – without increasing compute requirements: fully-archiving Bitcoin Cash nodes can continue to run on inexpensive, consumer hardware.

Learn More

To learn more about the upgrade or the CHIP upgrade process, please see this earlier post:

https://t.co/zT1TT8GnMX

[Bitauth IDE @BitauthIDE]

Bitcoin Cash's 2025 upgrade is now live in Bitauth IDE: no opcode limit, larger contracts, 10KB stack items, and high-precision math! 🚀 Details:

https://t.co/QjQC0MTQCk

Pro tip: click the icon in your browser's URL bar to install the app. Full screen, easy offline access ✈️

[Jason Dreyzehner @bitjson]

Bitcoin Cash's November 15th chipnet lock-in is almost here, and the VM Limits & BigInt CHIP upgrades are expected to activate in 2025! 🚀 If you run a node on chipnet, please upgrade today!

Over the past 6 weeks, we’ve been requesting final approval from all stakeholders: over 400 companies, organizations, and projects from across the Bitcoin Cash (BCH) ecosystem.

We recognize that taking a public position on a network upgrade requires time, resources, and commitment to advancing Bitcoin Cash. Thank you to all of the organizations and individuals who have participated during this lock-in process.

Thank you to all contributors to these proposals. Technical feedback has been incorporated over dozens of revisions, and the upgrade is now meticulously optimized and widely reviewed – over 6 months before mainnet activation.

My summary, endorsement, and links to the VM Limits CHIP:

https://t.co/Kf59m7rEri

My summary, endorsement, and links to the BigInt CHIP:

https://t.co/57TEI8p37o

Again, if you run a chipnet node, be sure to upgrade before chipnet activation: ~30 hours from the time of this post! Verified builds and a docker image are available:

https://t.co/7ZvdQIWsr8

[Jason Dreyzehner @bitjson]

On behalf of @BitauthIDE, @ChaingraphCash, and @libauth, I'm endorsing two Bitcoin Cash Improvement Proposals (CHIPs) for the 2025 upgrade cycle:

- CHIP-2021-05 VM Limits: Targeted Virtual Machine Limits
- CHIP-2024-07 BigInt: High-Precision Arithmetic for Bitcoin Cash

[Libauth @libauth]

Please star us on GitHub! https://t.co/pwjAHdKAMR

[Libauth @libauth]

Libauth v3.0.0 is out! 🚀 More consistency across utilities, detailed usage guides, and a new API overview in the readme:

[Jason Dreyzehner @bitjson]

Ever wondered how Bitcoin Script becomes a bitcoin address?

Here's the Bitcoin Script For Beginners talk I gave at @tabconf 2019. It covers:

• How transactions use Bitcoin Script
• How funds are "locked" to addresses
• How opcodes work
• How to define new kinds of wallets, and
• How to write your own scripts with @BitauthIDE, the interactive debugger shown in the demo.

[Bitauth IDE @BitauthIDE]

Bitauth IDE v1.0.0 is now available 🎉

• Works offline ✈️
• Uses @libauth v2.0.0
• >70% screenshot-testing coverage
• Performance improvements and bug fixes

Please help us grow by starring the project on GitHub: https://t.co/kfEpzRZX0F

[Jason Dreyzehner @bitjson]

The May 2024 upgrade to Bitcoin Cash (BCH), CHIP-2023-04 Adaptive Blocksize Limit Algorithm, is now active on chipnet at block #174519 (0000000068675ff881ff763de0c4b47b8da8f64c7800c016a9dac60f7f8e0007)! 🎉

This upgrade resolves an economic vulnerability that was introduced in 2010 and led to the BCH/BTC network split in 2017.

The algorithm automatically adjusts Bitcoin Cash's block size limit to reduce infrastructure costs during periods of lower usage while enabling up to a doubling of the maximum block size per year at peak growth.

Why Limit Block Size?

The block size limit caps the technical requirements of network infrastructure, enables reliable infrastructure cost projection, and prevents attacks that increase the cost of participating in the network.

Excessively large blocks could require users and businesses to waste resources on unnecessary infrastructure, switch to cheaper and less secure validation strategies, or even to abandon running their own infrastructure and instead rely on third-party service providers – reducing the overall privacy, independence, and financial freedom of all users.

Vulnerability of Static Block Size Limits

To limit block size, most bitcoin-like networks (BCH, BTC, BSV, XEC, etc.) employ a static block size limit. For Bitcoin Cash mainnet, this limit is currently 32MB.

If a payment network is growing, usage will eventually approach any previously-established static limit. If this limit is reached before a successfully coordinated upgrade, network service degrades: transaction fees and confirmation times become less predictable as size-limited blocks become more common.

Uncorrected, market actors begin to adapt to this artificial scarcity by using alternatives to on-chain transactions: custodians, intermediaries, and competing networks. This in turn compromises the long-term economics of mining – cumulative transaction fee revenue is suppressed, and long-term network security grows to rely on continuous inflation via block subsidies.

Because static block size limits can only be changed as part of a widely coordinated network upgrade, they present a focal point for network interruption or capture by motivated attackers: rent seeking institutions, competing networks, opponents of peer-to-peer cash, etc. To make matters worse, the attackers have a significant coordination advantage – while honest network participants must achieve near-unanimous consensus to activate an upgrade, attackers must only create sufficient uncertainty among the honest participants to delay limit increases, as inaction results in degradation of the network’s functionality and long-term security.

Adaptive Block Size Limits

Adaptive block size limits resolve the economic vulnerability of static limits by automatically adjusting the maximum block size over time.

While an adaptive block size limit could still diverge from a hypothetical "ideal" size due to significant changes in the rate of technological advancement or the availability of capital, such divergences would likely remain much smaller than with static limits, and attackers are no longer afforded an advantage.

Bitcoin Cash's Adaptive Algorithm

The new algorithm is conservative and based on observed usage. In cooling-off periods of falling network usage, the limit slowly decreases to preserve the resources of infrastructure operators. On the other hand, during periods of rapid growth, the limit can increase at a rate of up to 2x per year.

---

This post is adapted from my earlier blog post about the May 2024 upgrade. You can find more information about this upgrade and Bitcoin Cash's upgrade process in that post (link in bio). Thanks for reading!

[emergent_reasons#100🌵 @EmergentReasons]

@jimfriendo steps toward excellent UX AND self-sovereignty:

LibCash/similar: Development wrappers on BCH primitives in @libauth and full nodes.

Documentation e.g. https://t.co/h55vIXkKp7

CashRPC building on @bitjson - empowering users without depending on a domain.

[Jason Dreyzehner @bitjson]

I've submitted the following stakeholder statement for CHIP-2023-04 Adaptive Blocksize Limit Algorithm:

This proposal resolves the economic vulnerability inherent to static block size limits and could reasonably get us to universal Bitcoin Cash adoption without further intervention. Fourteen years of network usage data, across multiple ecosystems, provide the insight required to have confidence in deploying an adaptive block size algorithm.

On the specifics of the algorithm: I'm most focused on development of applications and services (primarily Chaingraph, Libauth, and Bitauth IDE) where raising the block size limit imposes serious costs in development time, operating expense, and product capability. Even if hardware and software improvements technically enable higher limits, raising limits too far in advance of real usage forces entrepreneurs to wastefully redirect investment away from core products and user-facing development. By measuring observed usage, CHIP-2023-04 Adaptive Blocksize Limit Algorithm minimizes such waste while still ensuring adequate capacity for both bursts of activity and consistent future growth; I support this CHIP's activation in the May 2024 upgrade.

For an overview of the proposal, please see the full post: https://t.co/tusgAYxh9V

[Dagur Valberg 🧪✨ @dagur]

@bchautist Thanks for helping me debug it with @libauth IDE 🙏

[Libauth @libauth]

New commit - Merge pull request #89 from mr-zwets/patch-1

Documentation fix for generatePrivateKey https://t.co/Bmf8CxxL0G