General Protocols Sponsorship for Q2 2026
https://youtu.be/3Wxgcyd25j8
In Q2 2026, General Protocols is supporting several ongoing projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q2 2026:
Electron Cash: *A Bitcoin Cash SPV wallet* https://electroncash.org/
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.* https://bitcoincashnode.org/en/
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.* https://cashscript.org/
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.* https://github.com/cculianu/Fulcrum
The Bitcoin Cash Podcast: *A podcast dedicated to Bitcoin Cash, aimed at accelerating BCH adoption, by providing news, updates and entertaining media all related to Bitcoin Cash.*
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://bitcoincashpodcast.com/ https://blog.generalprotocols.com/
General Protocols Sponsorship for Q1 2026
https://www.youtube.com/watch?v=Okz5xP7FlCY
In Q1 2026, General Protocols is supporting several ongoing projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q1 2026:
Electron Cash: *A Bitcoin Cash SPV wallet* https://electroncash.org/
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.* https://bitcoincashnode.org/en/
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.* https://cashscript.org/
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.* https://github.com/cculianu/Fulcrum
The Bitcoin Cash Podcast: *A podcast dedicated to Bitcoin Cash, aimed at accelerating BCH adoption, by providing news, updates and entertaining media all related to Bitcoin Cash.*
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://bitcoincashpodcast.com/ https://blog.generalprotocols.com/
General Protocols Sponsorship for Q4 2025
https://youtu.be/0y38Q2YRFtk
In Q4 2025, General Protocols is supporting several ongoing projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q4 2025:
Electron Cash: *A Bitcoin Cash SPV wallet* https://electroncash.org/
Libauth: *An ultra-lightweight JavaScript library for Bitcoin, Bitcoin Cash, and Bitauth applications.* https://github.com/bitauth/libauth
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.* https://bitcoincashnode.org/en/
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.* https://cashscript.org/
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.* https://github.com/cculianu/Fulcrum
The Bitcoin Cash Podcast: *A podcast dedicated to Bitcoin Cash, aimed at accelerating BCH adoption, by providing news, updates and entertaining media all related to Bitcoin Cash.*
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://bitcoincashpodcast.com/ https://blog.generalprotocols.com/
GP Statement on CHIPs and 2026 Activation
As we approach the lock-in for the May 2026 upgrade, discussion around the Functions CHIP has intensified with continued scrutiny and investigation. This has resulted in more understanding of the trade-offs involved and exploration of alternative approaches, allowing stakeholders to make an increasingly informed opinion.
The deep work performed by Jason on creation of CHIPs has required significant effort to evaluate. It has also required discussion to elucidate a wide range of additional angles that increase confidence that all bases have been covered. That coverage has importantly included not only the immediate and longer term benefits, but also risks - more amorphous, harder to specify, and due to the one-way nature of consensus upgrades, critically important.
General Protocols has been convinced that in the space of possible alternatives, including EVAL, modified versions of Functions and doing nothing, define/invoke is the best choice for BCH and endorses CHIP-2025-05 Functions (Commit 26e2256) for 2026 activation. https://github.com/bitjson/bch-functions/tree/26e22566a18f2f3b542ff46a70d258d5da585cd8
General Protocols also endorses the following CHIPs for 2026 activation:
CHIP-2021-05 Loops (Commit bd3ebc7) https://github.com/bitjson/bch-loops/tree/bd3ebc76bfa2190255fd3b5fcd84ec8910652f4e
CHIP-2024-12 P2S (Commit c144f03) https://github.com/bitjson/bch-p2s/tree/c144f03fe11b6de0e924b2285b355370d0e658b8
CHIP-2025-05 Bitwise (Commit a432a19) https://github.com/bitjson/bch-bitwise/tree/a432a19bcbc597391d0f0a29ae62a902b575d1dd
****General Protocols Blog****
This article forms part of the General Protocols Blog, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings.
GP's view on the current CHIP landscape
In our previous article, we laid out two cost/benefit principles when we consider which proposals to support: https://read.cash/@GeneralProtocols/what-gp-looks-for-in-consensus-upgrades-7e06cdeb
Long-term prospects of Bitcoin Cash as widely used permissionless money for the world.
Short and long term usefulness of the Bitcoin Cash in all its aspects - currency, protocol and network - to General Protocol's current and prospective products, with a heavy bias towards practicality.
There are many proposals currently brewing across BCH channels and forums generating excitement - and sometimes frustration. Let's look at some of them.
**CHIP-2021-05 Loops**
Context: https://github.com/bitjson/bch-loops
Looping as a formal CHIP has been proposed since 2021, and has gone through little change over the years.
While the VM-Limits rules activated in 2025 accommodate some interesting but inefficient "unrolling" workarounds, looping's significant simplification and added flexibility in aggregating over arbitrary-sized transactions is too attractive to dismiss both for GP and BCH ecosystem as a whole.
Importantly, the proposal has seen active demand and discussion over the years, making it less likely to raise unknown vulnerabilities after a potential activation. The aforementioned VM-Limits rules added further confidence to its safety, making runaway resource consumption - a common objection to looping - very unlikely in general.
***General Protocols endorse CHIP-2021-05 Loops for a May 2026 activation.***
**CHIP-2025-05 Bitwise (Invert, RShift, LShift)**
Context: https://github.com/bitjson/bch-bitwise/
The Bitwise operations CHIP is an altered and expanded version of three opcodes deactivated in 2010 as part of the "panic attack" DoS fix that also disabled many other opcodes. Most of those were later reactivated in some form on BCH in May 2018, but OP_MUL only followed much later in 2022 when an expanded integer size made its usefulness more conspicuous.
The bitwise operations, though, were not included in the previous upgrades. Activating them will finally complete the arithmetic and logic suite of opcodes Satoshi included. Completing them is not just a matter of aesthetics - they make it much easier to emulate cryptographic functions outside the handful shipped with bitcoin's opcodes.
The CHIP itself is very new though, and in our opinion did not yet adequately document the original rationale for deactivation, as well as developments since. We urge parties interested in its speedy activation to actively explore and help complete its documentation, as well as usecases.
***With the conditions of adequate tests and investigation before September, and no issues emerging from investigation, General Protocols will endorse CHIP-2025-05 Bitwise for a May 2026 activation.***
**CHIP-2024-12 P2S: Pay to Script**
Context: https://github.com/bitjson/bch-p2s
The Pay-to-Script proposal is really three related but independent changes bundled in a single CHIP, their common trait being they all expand what's allowed in different parts of a transaction. They are as follows:
1. Remove the current standardness restrictions on locking bytecode, only keeping the maximum length restrictions for non-op_return outputs.
2. Expand token commitment size, see also CHIP-2022-02-CashTokens https://github.com/cashtokens/cashtokens
3. Increase standard allowed input bytecode size to consensus.
We expect this set of changes to make building multi-contract systems significantly easier, and we observed informal agreements from other parties in the nascent BCH smart contract ecosystem. Impressively, the author exercised restraint in easing locking bytecode constraints, such that ease of storing data in the valuable UTXO set is not increased, and the only expected long-term burden comes from expanded token commitment size.
***With the condition that adequate ecosystem consultation and documentation be completed before September, General Protocols endorse will endorse CHIP-2024-12 P2S for a May 2026 activation.***
With that said, we also urge interested parties to be aware of the increased technical and coordination burdens of many simultaneous upgrades. Readers should be aware that delays of their full evaluation, implementation and activation to later cycles are not only possible, but part of the expected process.**
**CHIP-2025-05 Functions (previously op_EVAL)**
Context: https://github.com/bitjson/bch-functions
It is important to understand that first and foremost, the proposal's author emphasized, **the proposal's purpose is code compression**. This purpose is consistent throughout its comparison to alternatives, and indeed in comparing the Functions proposal to its immediate predecessor Eval. https://bitcoincashresearch.org/t/chip-2024-12-op-eval-function-evaluation/1450/41
A large enough compression, even if quantitative in nature, can bring on qualitative change all by itself. This has been speculated to be the case for functions/Eval in making certain usecases such as zero-knowledge functions practical. We also have a precedence in Introspection opcodes: All transaction introspection operations were already possible after the introduction of Op_Checkdatasig in 2018, but much was grossly complex to the point of impracticality, until native introspection opcodes. This has been demonstrated in our very own AnyHedge contracts where the reduction in complexity was difficult to ignore. https://read.cash/@GeneralProtocols/anyhedge-case-study-the-positive-impact-of-native-introspection-and-better-math-9cfdb236
No such usecases where functions make a large difference, zero-knowledge included, has been demonstrated so far.
Less powerful alternatives to the current proposal also exist, mostly focused on offering similar efficiency without facilitated code mutability. Code mutability is a feature present in this proposal, but implicitly or explicitly disabled in other alternatives.
Two issues that have attracted concern are that the CHIP facilitates code mutability and code injection, which are broader powers than straightforward code compression. While they are largely considered features from the perspective of a general purpose programming language, they have costs, for example in reduction of ability to analyze programs for safety, robustness and malicious intent, an important issue for a network that aims to handle money for the world.
It has been claimed that code mutability and injection are necessary for maximum efficiency in ZK (Zero Knowledge) usecases. There has been no demonstration, however, how critical this is in real terms; or whether an alternative could be made good enough in practice.
We should note that there were BCH upgrades and proposals where theoretically beneficial changes turned out to be mediocre at best, and even unnecessary burdens at worst in practice. CTOR (Canonical Transaction Ordering, 2018) and Merklix trees (proposed, never activated) were two such changes: Offering theoretical conveniences at a low level, but in the case of CTOR the advantages never materialized after activation, and in the case of Merklix its benefits were never demonstrated anywhere.
The proposal's qualitative benefits are not yet clearly demonstrated, especially in a steel-man context vs alternatives. As we look forward to a number of lower-hanging fruits, perhaps it is prudent that this proposal should receive at least another year of deliberation.
***General Protocols urges further debate and exploration on CHIP-2025-05 Functions.***
**Confirmation-time improvements**
Context:
1. https://gitlab.com/0353F40E/fablous
2. https://bitcoincashresearch.org/t/spearheading-the-future-implementation-of-weak-blocks-intermediate-blocks-for-bch-proof-of-work/1333
3. https://github.com/gcash/bchd/blob/avalanche/avalanche/spec.md
4. https://arxiv.org/pdf/2306.12206
Security of a bitcoin transaction is famously accumulated over time and measured in "confirmations", as described in Satoshi's whitepaper. A faster confirmation, signaling a shorter time to secure transactions, is obviously desirable for UX (User Experience) in almost all usecases. While various schemes to shorten time to confirmation have tried to justify themselves on different grounds over the years, they generally attack from the following angles:
1. Discouraging doublespends before consensus proof-of-work is accumulated. This is the principle behind Double-spend proof and proposed Zero-Confirmation Escrow. Notably by definition, they do not address any need for proof-of-work security.
2. Increased information/granularity on proof-of-work. This is the principle behind faster blocktime and non-consensus weak-block proposals. While users desiring 2+ confirmations can also gain a slightly better UX by having more information, the most notable benefit generally comes in the form of faster time to **any** proof of work based guarantees, even if the guarantees is weaker than a traditional one-conf.
3. Increased expected security accumulation within the same duration relevant to usecases. Theoretically "addressing root of the problem", these could be more disruptive, technically difficult, challenging major bitcoin assumptions such as proof-of-work, or all of the above. Some of the approaches include improving efficiency of proof-of-work consensus (bobtail/tailstorm), utilizing new assumptions (BCH's very own 10-block rollback limit), or imposing new sources of security altogether (proof-of-stake Avalanche, linkage to the now defunct SmartBCH).
While many of these are not mutually exclusive, all solutions impose significant costs in one form or another. In the interest of having **any** improvements at all, it may be tempting to simply push for adoption of the lowest-apparent-cost solution. We must caution, however, that any adopted solution has the practical likelihood of becoming "the BCH solution to blocktime" over the medium term, as we have previously seen with Double-spend proofs. BCH is not quite in the position of being able to just try many things at once, especially for something as fundamental as transaction security signaling. Adopting a solution with less benefit/cost ratio than otherwise reasonable may be a disappointment difficult to swallow in the longer term.
Among these, advocates for solutions that touch the fundamentals (such as introducing proof-of-stake) or headline numbers (such as faster blocktime) of consensus should also make efforts to consider their impact in less familiar places. What makes marketing easier or harder? Are normally less active holders and ecosystem actors more likely to be concerned at these changes? Widely consulting is always necessary for CHIPs, but the legwork is especially important in these cases.
Everyone recognizes the benefit of doing something, but it may be worth doing it right at the cost of waiting a little longer.
***General Protocols encourages further exploration on broad categories of confirmation-time improvements, recognizing the need to balance between urgency of UX improvements and ecosystem cost.***
**UTXO Commitment**
Context:
1. https://bitcoincashresearch.org/t/chip-2021-07-utxo-fastsync/502
2. https://eprint.iacr.org/2019/611.pdf
Scalability lies at the center of BCH's longstanding disagreement with BTC, and few statements describe arguments of the BTC side better than "every node needs to store everything forever, so large blocks are ultimately not sustainable". UTXO commitment schemes remove syncing requirements for all but the most recent blocks, making that statement invalid. BCH aspires to become the world's permissionless money, so this seems like a no-brainer.
In practice, though, scalability requires more than syncing nodes for miners. Certain commitment schemes may emphasize low resource consumption, while others attend to the practical requirement of light wallets to see their balance in a post-history world. One proposal that goes all-in on the former is Josh Green / Verde's Elliptic Curve Multiset based protocol, which is speedy enough in prototype it is likely compatible with future commitment schemes on top of it.
As a company disproportionately staffed by BCH veterans, we have always maintained high interest in UTXO commitment schemes, and in particular Josh's proposal which is the most well-elaborated so far. Ecosystem interest in UTXO commitment and technical scalability improvements (as opposed to coordination improvements such as ABLA) has been on and off though, likely due to the perceived lack of urgency. We see scalability improvements as confidence boosters to the chain's defining selling point, and would like to generally promote more interest in them.
***General Protocols encourages more urgency and interest in CHIP-2021-07 UTXO Fastsync, as well as scalability-improving commitment schemes in general.***
****General Protocols Blog****
This article forms part of the General Protocols Blog, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings.
General Protocols Sponsorship for Q3 2025
https://youtu.be/rbXV3VtUs_Q
In Q3 2025, General Protocols is supporting several ongoing projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q3 2025:
Electron Cash: *A Bitcoin Cash SPV wallet* https://electroncash.org/
Libauth: *An ultra-lightweight JavaScript library for Bitcoin, Bitcoin Cash, and Bitauth applications.* https://github.com/bitauth/libauth
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.* https://bitcoincashnode.org/en/
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.* https://cashscript.org/
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.* https://github.com/cculianu/Fulcrum
The Bitcoin Cash Podcast: *A podcast dedicated to Bitcoin Cash, aimed at accelerating BCH adoption, by providing news, updates and entertaining media all related to Bitcoin Cash. Since January 2021, the Bitcoin Cash Podcast has produced 85 episodes and is still going strong.* https://bitcoincashpodcast.com/
CashConnect: *CashConnect is a versatile protocol intended to standardize application-to-wallet connections within the BCH ecosystem. It is still in its pre-alpha phase.*
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://bitcoincashresearch.org/t/cashrpc-protocol-to-attempt-to-unify-wallet-app-comms/1201 https://blog.generalprotocols.com/
What GP looks for in consensus upgrades
General Protocols as a company is broadly interested in two things, in order:
Long-term prospects of Bitcoin Cash as widely used permissionless money for the world.
Short and long term usefulness of the Bitcoin Cash in all its aspects - currency, protocol and network - to General Protocols' current and prospective products.
GP has been an active participant in the CHIPs Process [1] for BCH upgrades since its introduction in 2021. CHIPs is the first attempt at permissionless, consistent upgrades that invite network participation in and orderly manner in any Bitcoin branch. The first CHIPs document laid out some principles [2], recommendations for benefits [3] and costs [4], as well as comparison to alternatives [5].
Let's take a closer look at some specific proposals in the past, which benefits and costs we prioritize - or not!
**Past cases**
**Unconfirmed transaction chain limit (2021)**
Context:https://github.com/softwareverde/bitcoin-cash-chips/blob/master/unconfirmed-transaction-chain-limit.md
Lifting of the unconfirmed transaction chain limit was perhaps the single biggest improvement to BCH's user experience since the fork. The original 25-transactions limit relay policy at fork was crippling; the revised 50-transactions cap was still extremely limiting. These caps were already an annoyance in daily cash use, as seen in frequent payouts during BCH events. They would become debilitating as BCH gained more defi capabilities in later consensus upgrades, as UTXO chains pass around unrelated parties in quick succession.
This chain limit was the result of a mempool policy called Child-pays-for-parent (CPFP), an algorithm that optimized miner income when mempool is congested and choices have to be made. Importantly, BCH's community generally considers full mempools as something that should happen very rarely. Optimizing behavior during congestion at the cost of a large UX degradation during non-congested times would seem to make a lot less sense than other contexts where full mempools were not only frequent, but encouraged.
The CHIP proposed removing the chain limit entirely. It was radical at the time as CPFP's performance cost rises dramatically as unconfirmed chains get longer - most considerations accordingly explored how far could nodes plausibly extend the limit under the same paradigm.
It was not until BCHN actually tested removing CPFP mechanisms entirely that the community realized how little the chain limit mattered in performance, as long as CPFP was removed as a relay policy. It also had no negative impact on existing users; no known applications depend on the 50-tx limit to function.
The Unconfirmed Transaction Chain Limit CHIP therefore had a very large benefit to both BCH and General Protocols, while having essentially no cost outside of initial implementation. General Protocols decided to support the proposal.
**ASERT difficulty adjustment algorithm (2020)**
Context:https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2020-11-15-asert.md
ASERT came at a turbulent time for BCH. Coin price was down dramatically from a multiyear bear market, miner interest was waning, and the chain was facing another potentially destructive split from its then-lead developer's unilateral push to collect a consensus-enforced miner tax for himself.
BCH further faced an existential crisis as a proof-of-work coin: Constant mining, as opposed to opportunistically switching to BCH only when profitability peaks, was getting too unprofitable thanks to a flaw in its difficulty adjustment algorithm, exacerbated as a minority chain. At worst this could lead to a death spiral as fewer and fewer hashpower persist through the bad times; at best it led to frequent episodes of very long gaps between blocks, degrading user experience. ASERT smooths out profitability, incentivizing more consistent mining.
It did not come without a cost, though. Any change in difficulty adjustment impacts client software that depends on permissionlessly understanding blockchain headers, such as SPV clients. Electron-cash wallet, for example, had to push a major release, and users were forced to upgrade. Some wallets like Bitcoin Wallet for Android was never updated and fell off the map, only to be succeeded in spirit years later by Selene Wallet.
Despite the cost, the proposal addressed a sufficiently urgent problem for BCH in a reasonable way, with no attractive alternative. It had a significant cost, but the cost was far outweighed by consequences of inaction. Along with the rest of the ecosystem, General Protocols decided to support the proposal.
**Introspection opcodes (2022)**
Context:https://gitlab.com/GeneralProtocols/research/chips/-/blob/master/CHIP-2021-02-Add-Native-Introspection-Opcodes.md
Introspection was proposed and locked in during interesting times. SmartBCH, a sidechain attempt to attach Ethereum Virtual Machine to BCH, was still growing; there were talks that BCH may not need additional smart contract capabilities as sBCH takes advantage of existing EVM tooling to obsolete any demand on the UTXO side of things. sBCH would later implode for a number of converging reasons, but it was not known at the time (2021).
General Protocols' primary product on BCH, BCHBull [6], would not see beta until the next year. But it was already apparent that emulating covenant capabilities via OP_CHECKDATASIG, central to BCHBull and possible future products, was extremely limiting and complex. Introspection was not only significantly cheaper and safer, but also opened the doors to complex products elsewhere like Moria [7] and Fundme [8], which might not have been possible due to the high development and transaction cost associated with CDS covenant emulation.
While the expected cost to existing software and users was minimal as laid out in the CHIP, there was significant debate across Bitcoin forks about the optimal path to covenant capabilities. On a high level, fear of fungibility erosion was driven by the possibility of significant amounts of coins locked up in covenant chains forever. While most the BCH community did not take these philosophical concerns seriously, they nonetheless existed, and to this day still drives covenant-upgrade talks at BTC.
Due to abundance of caution for such a widely debated topic, General Protocols held back its support at first. Our product stood to benefit massively, but building confidence in the whole chain was more important - without which nothing could thrive including us.
Only after much further investigation along with the Cashscript crew did we find the costs miniscule, in the face of concrete, significant benefits. We could testify these first-hand due to our experience in designing smart contracts, and indeed it turned out most of the smart contracts after BCHBull would not have existed without Introspection. We decided to support the proposal.
**PMv3 (2021)**
Context:https://github.com/bitjson/pmv3/
PMv3 was a fascinating proposal. It was a radical departure from existing transaction format, it purports to do several different things at once. It was supposed to enable consensus-enforced tokens; it offered a path to full malleability protection; it enabled nifty contract setups that carry state from transaction to transaction. All of the benefits, at face value, were quite attractive.
Yet its problems were also many. Its token capability, a driving feature, was not very satisfying when examined in detail and design trials. It required significant development on top of existing software to take advantage of any of its benefits. As it was a big change in transaction format, possible breakage of existing setups would take time to be fully assessed.
Was the big cost worth the vague benefits? General Protocols wasn't sure, and did not support nor reject the proposal, only keeping up with its evaluation and alternatives. The proposal was eventually obsoleted by CashTokens [9], delivering most of its promised benefits at a much lower cost.
**Which proposals do we support? Which ones not?**
As we hopefully showed above, General Protocols does not have a rigid formula or "roadmap" for proposals it support - instead, we evaluate benefits and costs for each proposal individually, with heavy emphasis on practical usecases over abstract "purity" or nice-to-haves.
If a proposal has concrete, urgent and demonstrably high benefits over its alternatives, even significant costs can be overcome to warrant our support. On the flipside, if the benefits are vague, speculative and require disproportionate investment to realize, it would have a much harder time justifying its costs. Our judgement heavily skews to the practical side, and we do keep a healthy appreciation of the status quo as a low-cost alternative to any proposal that cannot sufficiently justify its costs.
It is important to note that even superficially "low-cost" proposals may not get our support or even serious consideration, if the changes are invasive or radical enough over its expected benefits. Debates and serious considerations have inherent opportunity costs all on their own - not just for us, but throughout the whole ecosystem. Hours, days and weeks spent looking at and iterating questionable proposals are time that could be spent on more slam-dunk proposals as well as the usecases themselves, time that BCH developers are always running short of.
**Referenced Links**
1. CHIPs Process:https://gitlab.com/im_uname/cash-improvement-proposals/-/blob/master/CHIPs.md
2. CHIPs Principles:https://gitlab.com/im_uname/cash-improvement-proposals/-/blob/master/CHIPs.md#background-assumptions-and-principles
3. CHIPs Recommendations and Benefits:https://gitlab.com/im_uname/cash-improvement-proposals/-/blob/master/CHIPs.md#motivation-and-benefits
4. CHIPs Costs:https://gitlab.com/im_uname/cash-improvement-proposals/-/blob/master/CHIPs.md#implementation-costs-and-risks
5. CHIPs Evaluation of alternatives:https://gitlab.com/im_uname/cash-improvement-proposals/-/blob/master/CHIPs.md#evaluation-of-alternatives
6. BCH BULL:https://bchbull.com/
7. Moria Money:https://v1.moria.money/
8. FundMe:https://fundme.cash/
9. CashTokens:https://github.com/cashtokens/cashtokens
****General Protocols Blog****
This article forms part of the General Protocols Blog, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings.
General Protocols Sponsorship for Q2 2025
https://youtu.be/VP4nGMyz48k
In Q2 2025, General Protocols is supporting several ongoing projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q2 2025:
Electron Cash: *A Bitcoin Cash SPV wallet* https://electroncash.org/
Libauth: *An ultra-lightweight JavaScript library for Bitcoin, Bitcoin Cash, and Bitauth applications.* https://github.com/bitauth/libauth
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.* https://bitcoincashnode.org/en/
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.* https://cashscript.org/
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.* https://github.com/cculianu/Fulcrum
The Bitcoin Cash Podcast: *A podcast dedicated to Bitcoin Cash, aimed at accelerating BCH adoption, by providing news, updates and entertaining media all related to Bitcoin Cash. Since January 2021, the Bitcoin Cash Podcast has produced 85 episodes and is still going strong.* https://bitcoincashpodcast.com/
BCH Foundation: *The purpose of the Bitcoin Cash Foundation is outreach and promotion of Bitcoin Cash as p2p electronic cash for the world through various communication initiatives.* https://bitcoincashfoundation.org/
CashConnect: *CashConnect is a versatile protocol intended to standardize application-to-wallet connections within the BCH ecosystem. It is still in its pre-alpha phase.*
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://bitcoincashresearch.org/t/cashrpc-protocol-to-attempt-to-unify-wallet-app-comms/1201 https://blog.generalprotocols.com/
General Protocols Sponsorship for Q1 2025
https://youtu.be/NLPYhBzZKz4
In Q1 2025, General Protocols is supporting several ongoing projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q1 2025:
Electron Cash: *A Bitcoin Cash SPV wallet* https://electroncash.org/
Libauth: *An ultra-lightweight JavaScript library for Bitcoin, Bitcoin Cash, and Bitauth applications.* https://github.com/bitauth/libauth
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.* https://bitcoincashnode.org/en/
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.* https://cashscript.org/
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.* https://github.com/cculianu/Fulcrum
The Bitcoin Cash Podcast: *A podcast dedicated to Bitcoin Cash, aimed at accelerating BCH adoption, by providing news, updates and entertaining media all related to Bitcoin Cash. Since January 2021, the Bitcoin Cash Podcast has produced 85 episodes and is still going strong.* https://bitcoincashpodcast.com/
BCH Foundation: *The purpose of the Bitcoin Cash Foundation is outreach and promotion of Bitcoin Cash as p2p electronic cash for the world through various communication initiatives.* https://bitcoincashfoundation.org/
CashConnect: *CashConnect is a versatile protocol intended to standardize application-to-wallet connections within the BCH ecosystem. It is still in its pre-alpha phase.*
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://bitcoincashresearch.org/t/cashrpc-protocol-to-attempt-to-unify-wallet-app-comms/1201 https://blog.generalprotocols.com/
GP on the VM-Limits and BigInt CHIPs: Statement and Recommendations for the Rest of the Ecosystem
We at General Protocols hereby formally announce that we support CHIP-2021-05-vm-limits: Targeted Virtual Machine Limits per commit 6b87d517081f2fdba6a50b8e7fb9147321def609, and CHIP-2024-07-BigInt: High-Precision Arithmetic for Bitcoin Cash per commit d1406b6984c5528983a029c79111646e95286b8c for activation on mainnet BCH in May 2025. https://github.com/bitjson/bch-vm-limits https://github.com/bitjson/bch-bigint
As a native BCH smart contract focused company, we expect the two proposals to enable simpler, more secure and more powerful uses for BCH as programmable money, in line with a streak of useful BCH Script upgrades that started in 2022. We are already seeing infrastructure preparations to take advantage of this in the work such as Cashscript, and we expect more projects to come online in the months to come. https://flipstarter.cashscript.org/en
The Bigints proposal was announced later than most other CHIP precedents in a barebones form, which did cause concern for us as we expressed in our previous assessment. We are nonetheless impressed by the rapid pace of its progress and the rigorous discussions that has taken place since our last assessment. The Bigints proposal integrates well with the VM-Limits CHIP, and both proposals would be in poorer shape without the other. In our opinion both CHIPs have met the bars for rigor established in previous years, and are now in sufficiently good shape for inclusion together. https://read.cash/@GeneralProtocols/general-protocols-assessment-on-frontrunner-bch-chip-proposals-august-2024-fdf6de1d?signature=38dcc8278b974e2fed21a189b45fc8e64a251b21c1617ad3b55dbcc44859d3db
This endorsement shall not be taken as an endorsement for latecoming proposals in general: Circumstances around the Bigints CHIP was extraordinary, and correspondingly extraordinary efforts were made to secure it in time both technically and socially. We believe we have contributed our share in offering constructive scrutiny through the process, and would like to see the bar remain high in terms of robustness and timeliness for future CHIPs.
**Recommendation for Ecosystem: Miners and Pools**
We expect the two CHIPs to increase commercial traffic on BCH and improve its appeal as a more powerful form of programmable money, increasing both transaction fees and coin value and therefore your revenue. Risks to the network seems adequately examined. We recommend support for the proposals.
**Recommendation for Ecosystem: BCH node developers**
The two CHIPS present significant work to implement, but no greater than some of the activated packages in the past such as CHIP-2022-02-CashTokens. Considering its benefit to the application developers, it seems well worth the workload. We recommend support for the proposals, and a compatible release as soon as possible.
**Recommendation for Ecosystem: BCH application and contract developers**
We expect the CHIPs to significantly expand what's possible for apps and smart contracts, as well as enabling simpler and more secure versions of existing contracts. We recommend support for the proposals.
**Recommendation for Ecosystem: Holders**
These proposals are expected to increase BCH's coin value through making it significantly more powerful as programmable money. We recommend support for the proposals.
**Recommendation for Ecosystem: Exchanges**
Exchanges are expected to only need the bare minimum for upgrade, swapping out their nodes just as the years before. We do not expect significant controversy for either of the proposals, therefore exchanges should not be concerned about downtime or making difficult choices. We do expect expanded smart contract usecases to lead to increased general trading volumes, there benefitting exchange profits. We recommend support for the proposals.
**Recommendation for Ecosystem: Retail and commercial users**
While we do not expect any immediate effects upon activation, as more smart contracts emerge we expect BCH's utility to improve for users, similar to how the Checkdatasig and Introspection upgrades enabled our own product, BCHBull, to serve latent stabilization and speculation needs among even the most ordinary retail users. We recommend support for the proposals.
General Protocols Sponsorship for Q4 2024
https://youtu.be/o-9_LqVVQ6s
In Q4 2024, General Protocols is supporting several ongoing projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q4 2024:
Electron Cash: *A Bitcoin Cash SPV wallet* https://electroncash.org/
Libauth: *An ultra-lightweight JavaScript library for Bitcoin, Bitcoin Cash, and Bitauth applications.* https://github.com/bitauth/libauth
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.* https://bitcoincashnode.org/en/
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.* https://cashscript.org/
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.* https://github.com/cculianu/Fulcrum
The Bitcoin Cash Podcast: *A podcast dedicated to Bitcoin Cash, aimed at accelerating BCH adoption, by providing news, updates and entertaining media all related to Bitcoin Cash. Since January 2021, the Bitcoin Cash Podcast has produced 85 episodes and is still going strong.* https://bitcoincashpodcast.com/
BCH Foundation: *The purpose of the Bitcoin Cash Foundation is outreach and promotion of Bitcoin Cash as p2p electronic cash for the world through various communication initiatives.* https://bitcoincashfoundation.org/
CashConnect: *CashConnect is a versatile protocol intended to standardize application-to-wallet connections within the BCH ecosystem. It is still in its pre-alpha phase.*
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://bitcoincashresearch.org/t/cashrpc-protocol-to-attempt-to-unify-wallet-app-comms/1201 https://blog.generalprotocols.com/
BCH Bull: Beginner strategies
So you now know how BCH Bull works, but do you know how to make it work *for you*? What do you have in mind, and how can BCH Bull help you get there?
**I just want to hold value in Dollars (or Euros, or gold... or BTC even)**
Your case is the simplest - you hedge your BCH in your asset of choice.
What you care about are:
1. Your desired duration of hedging. You would want to pick something reasonable - while you *can* terminate contracts early via Early Settlement, that can get quite pricey sometimes. You want to know roughly when you might need the coins for other purposes.
2. Minimize fees, or maximize returns. Yes, you often gets rewarded for taking the hedge side. Go to bchbull.com/premiums, scroll down to your asset of choice. Check for the green sign on the left boxes. Some assets may offer better premiums, but you would have to consider whether switching to that asset is worth it. https://bchbull.com/premiums
*Balance the two, and you'll hopefully be a happy camper.*
**I want to speculate, I want volatility, and I'm bullish on BCH.**
So you think BCH is going to go up - welcome to the club! Specifically, you think it's going to go up *relative* to some other assets - USD, gold, ETH, you name it. Time to click the speculate button.
What you care about are:
1. Your desired leverage. It's important to note that just hodling BCH is considered "1X" in BCHBULL terms, so all longs starting from 1.2x will net you *more* BCH than hodling as BCH goes up. The higher your leverage is, the more you gain in BCH when price goes up, *but* you can get liquidated earlier if price goes down, so be careful!
2. Your desired duration of longing. Same as hedging, you'll want to pick something reasonable. Getting out early can be expensive, doing multiple short contracts instead of one long contract can be expensive.
3. Your desired counterparty leverage. The higher the counterparty leverage, the easier it is for your counterpart to be liquidated, but the potential upside for this contract becomes more limited.
4. Minimize fees, or maximize returns. Yup, that's where the premiums come in, and you want to consider whether you want to go for the specific combination of duration, leverage and counterparty leverage that you really want, *or* maybe you're a little flexible to get the best premium. Start from bchbull.com/premiums then try different combinations, sometimes a difference of just a couple days may surprise you!
**I want to speculate, I want volatility, and I'm bearish on BCH.**
So you think BCH is going to go down, and you're gonna get more BCH on the way. Welcome to BCHBull's latest feature, leveraged shorts! Specifically, you want to bet that BCH will go down *relative* to some other assets - USD, EUR, BTC (!), you name it. We certainly hope BCH isn't going down versus BTC, but *if* that happens, you can get more BCH off that... https://bchbull.com/premiums.html
What you care about are almost identical to the longs above, just that instead of profiting when BCH go up, you profit when BCH comes down relative to your chosen asset. You get liquidated on your way up, and you may liquidate your counterparty on the way down. Check the premium page, play around with duration and leverages, and be the bear!
**I want to thread the needle and play market volatility both ways.**
**Neutralizing via matching hedges**
So you have some BCH and you decided you want to minimize risk. Longs have BCH downside risk, shorts have BCH upside risk, you don't want either, and want to get as close to hodl'ing BCH as possible.
The basic concept to understand here is **neutralizing** contracts: If you hold two opposing contracts - one long, one hedge or short - for any given price movement, they might add up to give you zero gain/loss. The way this happens is by having the same "nominal value" amount.
If you have two contracts, one long and one hedge/short have the same "nominal value" amount, then you will end up not gaining or losing no matter the price movement - unless you get liquidated, that is.
For hedges, this is easy: Nominal hedge = Your hedge input.
For shorts, Nominal hedge = Your short input * Your leverage. For example, a 5x short who put in $100 would have a nominal value of $500.
For longs, Nominal value = Your long input * (Your leverage - 1). For example, a 5x long who put in $100 would have a nominal value of $400. To get a matching $500 nominal value on this leverage, you would need to put in $125 in BCH instead of $100.
If you enter two contracts at the same time, one as long and one as short, with identical nominal values such as the examples above, you will not gain or lose a sat no matter how the price moves (until liquidation).
**Play the premiums**
One obvious way to play neutrality is by arbitraging premium differences. For example, you may see the following:
A 7-day USD hedge pays you 2% in premium, displayed on the BCHBull UI as "-2%".
A 7-day EUR 5x asks for a 0.5% premium fromlong you, displayed on the BCHBull UI as "+0.5%".
You can punch in two neutralizing contracts, and you may find out that they add up to a *_net_* premium in your favor. As long as you believe USD/EUR price won't move too much within 7 days, you can profit from this immediately by taking these two neutralizing contracts, and just get your capital back in 7 days!
Low risk, immediately profitable premium setups aren't always available. What if you want to add some prediction skill to this? That's for the next article: Playing different durations.
General Protocols Assessment on Frontrunner BCH CHIP Proposals, August 2024
As of August 19th, 2024, we at General Protocols would like to cautiously announce our support for ****CHIP-2021-05-vm-limits**** as of commit f59a7068b5538ec0b6baaf7302476c3b871da869 for November 2024 lock-in and May 2025 activation on BCH mainchain. This support is contingent on timely delivery of follow-up testing, some of which are already well underway, and aggressive social outreach efforts to actors in the BCH ecosystem. https://github.com/bitjson/bch-vm-limits/
We are also aware that a separate proposal, ****CHIP-2024-07-BigInt**** has been recently proposed as a complementary companion to the VM-Limits CHIP. We are a lot more reserved about this part given the timing of its announcement, the scarcity of accompanying work done, both technical and social, and the potential for a wide impact that would take time to assess. As a potential beneficiary of this proposal, we are not outright opposed to its implementation for this cycle. However, we would urge all actors across the BCH ecosystem to exercise extreme caution, and hold back support and assumptions about its activation for 2025 given its current state. https://github.com/bitjson/bch-bigint
**Support for VM-limits CHIP**
General Protocols is a company that prides itself on building robust smart contracts and tools tailor-made for BCH, and the expanded contract space in the VM-Limits CHIP would allow us to do a much wider set of things with shorter development cycle. For example, Anyhedge contracts could be made with more custom constraints, and compound contracts involving more than one oracle may become possible.
We find the constraints placed on CPU-intensive opcodes reasonable from a high level. This is, of course, still contingent on more detailed benchmarks to be published, as some of the restraints have been inserted only recently.
While later than some historical CHIPs, the ****implementation**** is also progressing at a satisfactory pace at the time of publishing. We would certainly love for other node teams to join and pick the code apart in the weeks to come to increase confidence. https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/merge_requests/1874
The lagging part of this CHIP so far is definitely the social part - much work still needs to be done in publicizing this proposal to a wider audience outside of the very most active developers and community members, not to mention forging consensus among actors through collecting explicit support. ***GP looks forward to helping with this important effort. If this CHIP is important to you, you should also get involved with review, feedback, and helping to bring important stakeholders into the process.***
**Caution for the BigInts CHIP**
We do not have a lot to comment on the BigInt CHIP other than its incomplete state. We do support this from a high level: Increasing integer precision safely on BCH has been done ****before****, and further increases would bring simplicity and robustness for many smart contract users on BCH including ourselves. It has, however, not made satisfying progress given we are less than three months from lock-in, and we find it difficult to recommend its inclusion given our historical ****emphasis**** on confidence-building for the network above all other things. It is still possible that developments above our expectations may happen in the coming weeks, but we would like to withhold our support for now. https://gitlab.com/GeneralProtocols/research/chips/-/blob/master/CHIP-2021-02-Bigger-Script-Integers.md https://read.cash/@GeneralProtocols/raising-the-bar-on-bitcoin-cash-upgrades-ae04238f
Goxed? Store value BETTER with BCH Bull!
The Mt. Gox saga finally comes to a close as Bitcoiners who held coins on the exchange 10 years ago begin to receive their payouts. Mt. Gox collapsed in 2014, long before Bitcoin split into BCH and BTC, so payouts to creditors will include equal amounts of the two coins.
Since the split, the narratives around each coin have diverged dramatically. How will those narratives affect the decisions of OG Bitcoin holders who have the opportunity to trade one for the other?
While BTC has shifted to being marketed as a “store of value”, its short term price volatility suggests the opposite.
And with minimal smart transaction features, BTC’s Decentralized Finance capabilities are extremely limited.
Bitcoin Cash, on the other hand, has upgraded its protocol in several innovative ways, making advanced DeFi products possible on the base layer. With derivatives products from BCH Bull, you can stabilize the value of your BCH holdings relative to US Dollars, Gold, and other assets, even BTC! That means you could hypothetically save in terms of BTC without ever touching the BTC blockchain.
If you’re getting 1 BTC from the Mt Gox settlement, and you want to make sure you have exactly 1 BTC worth of assets at some point in the future, just trade for BCH and create a hedge on BCH Bull. You’ll get 1 BTC worth of Bitcoin Cash when the contract settles, no matter how the prices move in the meantime, without needing to worry about how high fees will be when you want to move it.
Meanwhile, real businesses around the world are using BCH Bull to stabilize the value of their Bitcoin Cash holdings in terms of assets like the US Dollar, the Euro, gold, and silver.
You can also go long or short Bitcoin Cash with leverage against our supported assets. All Bitcoin Maximalists are cordially invited to visit BCHBear.com to short the BCH/BTC pair!
As long as you’re using Bitcoin Cash to do it, that’s bullish.
You just need a Bitcoin Cash wallet, you can swap BTC to BCH using SideShift right from the BCH Bull interface.
https://bchbull.com/
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://blog.generalprotocols.com/
General Protocols Sponsorship for Q3 2024
https://youtu.be/H9UeeBVI_WE
In Q3 2024, General Protocols is supporting several ongoing projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q3 2024:
Electron Cash: *A Bitcoin Cash SPV wallet* https://electroncash.org/
Libauth: *An ultra-lightweight JavaScript library for Bitcoin, Bitcoin Cash, and Bitauth applications.* https://github.com/bitauth/libauth
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.* https://bitcoincashnode.org/en/
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.* https://cashscript.org/
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.* https://github.com/cculianu/Fulcrum
The Bitcoin Cash Podcast: *A podcast dedicated to Bitcoin Cash, aimed at accelerating BCH adoption, by providing news, updates and entertaining media all related to Bitcoin Cash. Since January 2021, the Bitcoin Cash Podcast has produced 85 episodes and is still going strong.* https://bitcoincashpodcast.com/
BCH Foundation: *The purpose of the Bitcoin Cash Foundation is outreach and promotion of Bitcoin Cash as p2p electronic cash for the world through various communication initiatives.* https://bitcoincashfoundation.org/
CashConnect: *CashConnect is a versatile protocol intended to standardize application-to-wallet connections within the BCH ecosystem. It is still in its pre-alpha phase.*
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://bitcoincashresearch.org/t/cashrpc-protocol-to-attempt-to-unify-wallet-app-comms/1201 https://blog.generalprotocols.com/
General Protocols Sponsorship for Q2 2024
https://youtu.be/aGv3-xHsDPQ
In Q2 2024, General Protocols is supporting several ongoing projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q2 2024:
Electron Cash: *A Bitcoin Cash SPV wallet* https://electroncash.org/
Libauth: *An ultra-lightweight JavaScript library for Bitcoin, Bitcoin Cash, and Bitauth applications.* https://github.com/bitauth/libauth
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.* https://bitcoincashnode.org/en/
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.* https://cashscript.org/
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.* https://github.com/cculianu/Fulcrum
BCA: *Bitcoincashautist is a decisive, dedicated Bitcoin Cash community member who works tirelessly to improve the quality of BCH CHIPs (CasH Improvement Proposals), availability of information, and more.* https://twitter.com/bchautist
The Bitcoin Cash Podcast: *A podcast dedicated to Bitcoin Cash, aimed at accelerating BCH adoption, by providing news, updates and entertaining media all related to Bitcoin Cash. Since January 2021, the Bitcoin Cash Podcast has produced 85 episodes and is still going strong.* https://bitcoincashpodcast.com/
BCH Foundation: *The purpose of the Bitcoin Cash Foundation is outreach and promotion of Bitcoin Cash as p2p electronic cash for the world through various communication initiatives.* https://bitcoincashfoundation.org/
CashConnect: *CashConnect is a versatile protocol intended to standardize application-to-wallet connections within the BCH ecosystem. It is still in its pre-alpha phase.*
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://bitcoincashresearch.org/t/cashrpc-protocol-to-attempt-to-unify-wallet-app-comms/1201 https://blog.generalprotocols.com/
General Protocols Sponsorship for Q1 2024
https://youtu.be/WdFL4fWDKZg
In Q1 2024, General Protocols is supporting several ongoing projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q1 2024:
Electron Cash: *A Bitcoin Cash SPV wallet* https://electroncash.org/
Libauth: *An ultra-lightweight JavaScript library for Bitcoin, Bitcoin Cash, and Bitauth applications.* https://github.com/bitauth/libauth
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.* https://bitcoincashnode.org/en/
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.* https://cashscript.org/
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.* https://github.com/cculianu/Fulcrum
BCA: *Bitcoincashautist is a decisive, dedicated Bitcoin Cash community member who works tirelessly to improve the quality of BCH CHIPs (CasH Improvement Proposals), availability of information, and more.* https://twitter.com/bchautist
The Bitcoin Cash Podcast: *A podcast dedicated to Bitcoin Cash, aimed at accelerating BCH adoption, by providing news, updates and entertaining media all related to Bitcoin Cash. Since January 2021, the Bitcoin Cash Podcast has produced 85 episodes and is still going strong.* https://bitcoincashpodcast.com/
BCH Foundation: *The purpose of the Bitcoin Cash Foundation is outreach and promotion of Bitcoin Cash as p2p electronic cash for the world through various communication initiatives.* https://bitcoincashfoundation.org/
CashConnect: *CashConnect is a versatile protocol intended to standardize application-to-wallet connections within the BCH ecosystem. It is still in its pre-alpha phase.*
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://bitcoincashresearch.org/t/cashrpc-protocol-to-attempt-to-unify-wallet-app-comms/1201 https://blog.generalprotocols.com/
BCH Bull Case Study 01: A Sustainable Bitcoin Cash Farm in Nigeria - Max
**Meet Max and his Bitcoin Cash farm!**
Max, is an entrepreneur, trained accountant, and farmer in Southeast Nigeria. He has a history of community-focused projects within the Bitcoin Cash (BCH) ecosystem. Initially, Max started with a small vegetable garden, but he faced challenges due to issues like electricity, potable water, and irrigation. To address these issues, Max initially proposed a support loan within the BCH community, which was provided in March 2021, enabling him to work on water distribution projects in his community, including an irrigation system and a water tanker.
After successfully solving the water problem, Max expanded his efforts within the Bitcoin Cash community, this time successfully raising money through the non-custodial BCH crowdfunding platform, Flipstarter. This provided support for a hectare of farmland, which allowed him to expand his business, whilst increasing food security in his community. Additionally, he addressed the lack of electricity by proposing a solar energy system powered by BCH, which was funded and provided a solution for power supply.
Max's projects have not only improved his community's living conditions but also introduced BCH adoption. He has created projects that allow community members to purchase goods and services as well as earn income in BCH. Max also supports a charity program powered by BCH, assisting elderly individuals and widows in need.
*Max's farm produces a wide array of produce, from coconuts to oranges, blueberries, corn, cassava, and pineapples as well as managing poultry and other livestock!*
**Max's BCH-Powered Commerce and Local Trade**
Max's entrepreneurial vision has revolutionized his commerce and trade through Bitcoin Cash (BCH). From his farm, Max established a BCH minimart, pioneering a local economy driven by BCH. He conducts workshops, educating the community on BCH’s practical applications, thus fostering a growing network of BCH users. Max's innovative approach extends to his workforce, as he pays employees in BCH, creating a self-sustaining cycle of spending within his farm and minimart.
Max's endeavors go beyond his shop, permeating the region's economy. He incentivizes BCH usage through initiatives like the water tanker service, offering a 50% discount for BCH payments. This approach not only promotes BCH but also encourages its adoption in neighboring businesses. By actively embracing BCH for transactions, Max not only enhances local commerce but also sets a powerful precedent, showcasing the potential of cryptocurrency-driven economies in even the most localized settings. His efforts serve as a beacon for the integration of BCH into everyday transactions, illustrating its transformative impact on local trade and economic growth.
*Max's farm demonstrates an impressive array of activities, as well as a fully integrated Bitcoin Cash economy.*
**Navigating Naira Inflation and Crypto Volatility in Local Businesses**
Entrepreneurs like Max grapple with a dual challenge: the persistent inflation of the local currency, yet faced with the inherent volatility of cryptocurrencies. The Naira's inflation makes long-term financial planning for businesses exceptionally difficult. Fluctuating prices and uncertain inflation rates force entrepreneurs to constantly adapt, affecting product pricing and employee wages. This economic instability disrupts business operations, making it challenging to sustain profitability and growth.
On the other hand, volatility of digital assets like BCH poses unique challenges. The value of cryptocurrencies can swing dramatically, impacting businesses relying on them for transactions. Max, who advocates for BCH adoption, finds these fluctuations require constant monitoring. Striking a balance between the advantages of cryptocurrencies and the need for stability in financial planning remains an ongoing challenge, underscoring the necessity for innovative financial strategies and adaptive business models in the face of these economic uncertainties.
**Leveraging BCH Bull for Financial Stability**
With these challenges, Max has found BCH Bull, a tool he has actively embraced to manage these challenges. He initially experimented with it upon its launch, recognizing its necessity as a hedging tool. As inflation began to significantly impact his fiat currency, Max has now resumed using BCH Bull relying on its functionality since August 2023. Since his commercial activities are built around the use of BCH, using BCH Bull to stabilize his crypto funds makes the most practical and economic sense, rather than trade for stable coins on various other networks or custodial exchanges.
For Max, the concept of hedging is clear and practical. He employs BCH Bull as a fundamental part of his BCH fund management strategy. However, it has also evolved into a deeply personal approach due to his close ties with his businesses. Max's use of BCH Bull reflects a nuanced understanding of its dual role: as a strategic tool for business finance and as a safeguard for his personal financial stability. By leveraging BCH Bull, Max demonstrates a proactive approach to managing the challenges of both fiat inflation and crypto market volatility, ensuring a more secure financial future for his ventures and personal wealth.
Max now hedges BCH once per month, knowing his purchasing power is secure and safe, whilst keeping hold of Bitcoin Cash as his primary currency for accounting and business.
**Max's BCH Bull Experience: A Game Changer in Financial Management**
Max praises BCH Bull for its ability to shield him from the woes of local currency inflation, providing a stable financial foundation. Its unique feature of short and long hedging proves to be invaluable, allowing Max the flexibility needed in his money management practices. Max also appreciates the financial incentives; sometimes, he not only avoids inflation but receives a bonus for hedging.
While Max values BCH Bull, he highlights areas for enhancement. The lack of automated reminders for expiring contracts poses a challenge, requiring manual vigilance and attention to contract timelines. Additionally, Max expresses a wish for automatic contract renewal mechanisms, indicating a potential area for growth in the tool's user experience.
Max's feedback emphasizes BCH Bull's positive impact on his financial stability while also offering valuable suggestions for refinement. As he continues to utilize this tool, these insights provide crucial feedback for developers, ensuring that BCH Bull evolves to meet the evolving needs of users like Max, fostering even greater confidence in cryptocurrency-based financial management strategies.
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://blog.generalprotocols.com/
General Protocols Sponsorship for Q4 2023
https://youtu.be/RQYouMNrIQI
In Q4 2023, General Protocols is supporting a number of ongoing projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q4 2023:
Electron Cash: *A Bitcoin Cash SPV wallet* https://electroncash.org/
Libauth: *An ultra-lightweight JavaScript library for Bitcoin, Bitcoin Cash, and Bitauth applications.* https://github.com/bitauth/libauth
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.* https://bitcoincashnode.org/en/
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.* https://cashscript.org/
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.* https://github.com/cculianu/Fulcrum
BCA: *Bitcoincashautist is a decisive, dedicated Bitcoin Cash community member who works tirelessly to improve the quality of BCH CHIPs (CasH Improvement Proposals), availability of information, and more.* https://twitter.com/bchautist
The Bitcoin Cash Podcast: *A podcast dedicated to Bitcoin Cash, aimed at accelerating BCH adoption, by providing news, updates and entertaining media all related to Bitcoin Cash. Since January 2021, the Bitcoin Cash Podcast has produced 85 episodes and is still going strong.*
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://bitcoincashpodcast.com/ https://blog.generalprotocols.com/
General Protocols supports CHIP 2023-04 Adaptive Blocksize Limit Algorithm for Bitcoin Cash
In our last communication about a maxblocksize expansion plan, we listed four criteria that we think are important for a good adjustment algorithm: https://read.cash/@GeneralProtocols/general-protocols-opinion-on-bch-maxblocksize-scaling-6747bce7
Increases in maxblocksize must happen slowly over a long time.
The algorithm should leave reasonable headroom for rare bursts in usage.
The algorithm should reasonably reduce costs for operators in a usage downturn.
Finally, the algorithm should be tested against a reasonable collection of edge cases.
We have examined BitcoinCashAutist's CHIP, "2023-04 Adaptive Blocksize Limit Algorithm for Bitcoin Cash", and found the following: https://twitter.com/bchautist https://gitlab.com/0353F40E/ebaa
Even under extremely expansionist scenarios, the algorithm will stay slower than the rigidly scheduled BIP101, which was proposed by Gavin Andresen back in 2015 and acts as a relatively well known "safety limit" among the BCH community. https://gitlab.com/0353F40E/ebaa#risk-assessment https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki
The algorithm conservatively leaves more headroom than the once-popular BitPay proposal for median-based adaptive blocksize in most places. The more diverse the actual mined blocks are in size, the more headroom it leaves. https://github.com/bitpay/bips/blob/master/bip-adaptiveblocksize.mediawiki
The algorithm provides a slow path for reducing maxblocksize, both for long duration downturns and recovery from sudden spikes.
The proposal has reasonably addressed a variety of adverse scenarios, from runaway increases to a short term spam attack to not keeping up with demand. While it cannot possibly be perfect for every occasion and want, we believe it is at a sufficiently robust place when the risks are considered collectively.
Additionally, we found the following desirable traits in support of the proposal:
It already has an implementation that is ready to test.
Extensive simulations and comparison to alternatives have been described.
The proposal still has some room for improvement before deployment:
Most pools will likely inherit default "soft" blocksize caps from node implementations for a long time before they are incentivized by fees to change the default parameter. It is important for the proposal to recommend a starting point for such a cap to achieve short term robustness. Currently that limit stands at 8MB for BCHN, a popular choice for mining pools.
Upon activation, a modified blocksize adjustment algorithm does not automatically provide a robust means to drop un-upgraded nodes, which may persist indefinitely until maxblocksize increases from demand per the algorithm. While they may not pose immediate problems, such persisting un-upgraded nodes may become a risk in the future if they are used in significant economic activities. It would be beneficial for the proposal to recommend an activation strategy, whether automatic or manual, that reduces the risk. At the very least, there should be a discussion about this possible risk, even if it turns out to be remote.
Adopting a long term adaptive blocksize cap addresses a long running issue in BCH and reduces future social friction around upgrades, while inspiring confidence among users and entrepreneurs to invest in the ecosystem. With all the points above considered, we at General Protocols support this proposal for activation on BCH Chipnet in November 2023 and Mainnet in May 2024.
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://blog.generalprotocols.com/
A Focus on the Bitcoin Cash Ecosystem: 08 CHIPs
https://youtu.be/9rB83MocRrQ
**For a completely decentralized network, such as Bitcoin Cash, having a robust process for upgrading the network is of huge benefit to all stakeholders.**
In the BCH network, the CHIPs process is the accepted method for effecting modifications, enhancements, or novel introductions to BCH, following a structured and principled approach. A CHIP itself (Cash Improvement Proposal) is a document created within this process and is characterized by several key principles. https://gitlab.com/im_uname/cash-improvement-proposals/-/blob/master/CHIPs.md?ref_type=heads
Firstly, each CHIP has a designated owner who assumes full responsibility for its progress. This owner can be self-declared, with the singular ownership ensuring clarity and accountability throughout the CHIP process.
Secondly, the creation of a CHIP involves a comprehensive evaluation of all aspects, including technical, economic, and social considerations. This rigorous assessment guarantees that proposals are thoroughly examined from multiple angles.
Thirdly, the default stance towards any proposal is initially set to "preserve the status quo," irrespective of its origin. This cautious approach ensures that all ideas are subject to a rigorous scrutiny process.
A CHIP advances through the process by accumulating public commitment in stages. Starting from "no", individual stakeholders make public statements of gradually increasing certainty, for example, "maybe" and later "definitely, if the CHIP can resolve these issues". This gradual shift in commitment is driven by the allocation of resources and social capital, signifying the proposal's growing acceptance both to the CHIP owner and other stakeholders.
Additionally, the CHIP process includes specific milestones that serve two critical functions. Firstly, they highlight the progression of commitment or the lack thereof. Secondly, these milestones act as a timing and predictability mechanism, determining whether a CHIP, even with broad support, is in time for inclusion in the next annual upgrade, or if inclusion would need to wait for the following year's upgrade. This is important for less engaged actors, who make up the majority of users in any network, to keep their confidence in using the network.
While some may advocate for a more flexible approach, it is imperative to maintain a rigorous process. This is not because the process is flawless, but rather, without at least some rigor and structure, the inevitable need for clarity will result in either complete stagnation (as seen in many "leaderless" cryptocurrencies); or dictatorship and explicit voting, both more coercive options than desired to fill the void.
In summary, the CHIP process on the BCH network is designed to be systematic, accountable, predictable, non-coercive, and gradual, allowing for thorough evaluation and commitment before any proposed changes are implemented. This structured approach ensures the network's stability both in minimizing controversial, reckless changes and accommodating widely accepted, needed changes.
**Want to learn more? Follow these links:**
CHIPs outline: A process for consensus change
A list of CHIPs on BCH.INFO
A list of CHIPs on BitcoinCashResearch
The CashTokens Chip
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://gitlab.com/im_uname/cash-improvement-proposals/-/blob/master/CHIPs.md?ref_type=heads https://bch.info/en/chips https://bitcoincashresearch.org/c/chips/17 https://cashtokens.org/docs/category/cashtokens-chip/ https://blog.generalprotocols.com/
General Protocols Sponsorship for Q3 2023
https://www.youtube.com/watch?v=zzS71a_DEKY
In Q3 2023, General Protocols is supporting a number of on-going projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q3 2023:
Electron Cash: *A Bitcoin Cash SPV wallet* https://electroncash.org/
Libauth: *An ultra-lightweight JavaScript library for Bitcoin, Bitcoin Cash, and Bitauth applications.* https://github.com/bitauth/libauth
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.* https://bitcoincashnode.org/en/
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.* https://cashscript.org/
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.* https://github.com/cculianu/Fulcrum
BCA: *Bitcoincashautist is a decisive, dedicated Bitcoin Cash community member who works tirelessly to improve the quality of BCH CHIPs (CasH Improvement Proposals), availability of information and more.* https://twitter.com/bchautist
The Bitcoin Cash Podcast: *A podcast dedicated to Bitcoin Cash, aimed at accelerating BCH adoption, by providing news, updates and entertaining media all related to Bitcoin Cash. Since January 2021, the Bitcoin Cash Podcast has produced 85 episodes and is still going strong.*
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://bitcoincashpodcast.com/ https://blog.generalprotocols.com/
General Protocols: Opinion on BCH Maxblocksize Scaling
**Background**
The primary motivation for BCH's forking event in 2017 was an impasse in increasing the blocksize maximum, so the relevance of further blocksize increases to accommodate transaction volume needs no introduction to the BCH community, a community focused on getting to global usage on the L1 blockchain. Maximum blocksize discussed for the rest of this writeup is defined as the maximum size of a mined block, beyond which it'll be rejected by the majority of the network both by hashrate and economy. Note that there is an independent variable "soft limit" that is self-imposed by the miners and is strictly below maxblocksize, that is not relevant to this discussion.
We have had two one-time increases to this number in the past:
From 1MB to 8MB at the initial fork in 2017, and https://documentation.cash/protocol/forks/bch-uahf
From 8MB to 32MB in 2018. https://documentation.cash/protocol/forks/hf-20180515
The 32MB limit has not been moved since 2018, and demand has not been high due to slow growth in usage. While short bursts of "stress tests" that were conducted explicitly to challenge the limit were done from time to time, average long-term blocksize has been well below 500kB. It is important to note that in 2021 the default non-consensus "soft limit" shipped with BCHN has been increased from 2MB to 8MB, which has proven useful in accommodating some burst scenarios.
**Problem statement**
While average usage today is well over two orders of magnitudes away from challenging the current 32MB maxblocksize limit, two factors make it desirable to address it today:
One time increases in maxblocksize are an ongoing and unpredictable effort. While the CHIP process offers some stability and transparency to the effort, it nevertheless subjects the network to regular episodes of uncertainty regarding what some would consider its raison d'etre. Putting a predictable, sane plan into action reduces that uncertainty and increases confidence for all parties - users, businesses, infrastructure providers and developers. https://gitlab.com/im_uname/cash-improvement-proposals/-/blob/master/CHIPs.md
In the event of rapid adoption, the social makeup of BCH's community can inflate and diversify rapidly, destabilizing efforts to address the problem, possibly resulting in a chaotic split as witnessed with BTC in the past. A plan adopted right now will carry with it the inertia necessary to combat such destabilizing tendencies.
**Considerations**
Some crypto enthusiasts, using a Satoshi quote, correctly note the mechanistic ease of changing the maxblocksize in the code while missing important impacts beyond changing a single number:
On the low side, a small maxblocksize, even when the blocks are not congested, may deter commercial usage and development activity. This is due to the fact that business and development investment are long-commitment activities that often span months or even years. If entrepreneurs and developers cannot be offered confidence that the capacity will be there when they need it, they are less likely to make the investment of their precious time and money.
On the high side, a maxblocksize that is too large for current activity invites adverse, unpredictable conditions that typically consist of short bursts of noncommercial traffic that push the limits. The network impact of these activities is more subtle: they generate additional, volatile cost for infrastructure and service providers that may be difficult to justify. It is important to note that contrary to intuition, most of the cost to operators come from human operation and development complications, followed by processing power that scales with sizes of single blocks, with storage and bandwidth costs coming a distant last. We have observed this phenomenon in certain other cryptocurrencies, where very high throughput that did not come from commercial activity ultimately resulted in businesses ceasing to operate on their chains, reducing the network's overall value. It is important to note that we do not view all existing operators' continued existence as sacred; rather, we take the reasoned view that increased investment in infrastructure should be justified by corresponding commercial, value generating activities.
Historically, changing the maxblocksize comes with a heavy social cost each time it happens, with the risk of community and network fracture. Satoshi's quote makes sense back in the days when he made the decisions by himself, less so today when the majority of the network needs to come to consensus. A longer lasting plan up front that minimizes each of these potentially centralizing decision points can make the network more robust.
In short, the aim of a good scheme regarding maxblocksize adjustment should offer the maximum amount of **predictability** to all parties: users who want steady fees, developers who want stable experiences, entrepreneurs who want to reduce uncertainty in growth, and service providers who want to minimize cost while accommodating usage.
**Alternatives**
With the criteria stated above, let's examine some alternatives:
**Outright removal of consensus blocksize limit**: The general purist argument is that miners would resolve any disagreements on their own without a software imposed limit. In reality, without an effective way to coordinate an agreement, each node can have vastly different capabilities and opinions on the sizes that are tolerable. The result is therefore either network destabilization and split without coordination, or opaque, centralizing coordination outside the protocol. Neither scenario are likely to offer confidence or stability.
**One-time increases to maxblocksize**: While extremely simple in execution under the BCH context, as described above it subjects the network to regular episodes of uncertainty and social cost, and thus is less ideal for long term growth. At every manual increase, concerns of all parties have to be reconsidered, sometimes under adverse social conditions without the benefit of inertia.
**Fixed schedule**: Have the maxblocksize increase on a rigid schedule, such as BIP101 or BIP103. Also simple in execution, these schemes additionally offer a possible scenario where if demand roughly stays in line with the schedule, no manual adjustment is needed. It is impossible to perfectly predict the future though, and such schemes will inevitably diverge from real world usage and cost, requiring frequent revisits to their parameters. Each revision can incur larger social costs than even one-time increases due to the complexity of schedules as opposed to just sizes.
**Algorithmic adjustment based on miner voting**: Adopted by Ethereum, the scheme proposes that miners (and pools, by proxy) vote for the maximum block capacity on fixed intervals, with the result tallied based on a fixed algorithm that then adjusts maxblocksize up or down at the next period. While this scheme can work well with a well-informed and proactive population of pools, our current observation is no such population exists for BCH - miners and pools typically only intervene when a crisis happens, which may not be ideal for user confidence. BCH is additionally a minority chain in its algorithm, which may complicate incentives when it comes time to adjust maxblocksize.
**Algorithmic adjustment based on usage**: Multiple attempts exists, including an older dual-median approach and a newer, more sophisticated WTEMA-based algorithm. These schemes generally aim to algorithmically adjust maxblocksize based on a fixed interpretation of past usage in terms of block content. While far from perfect, we see these schemes as our best path forward to achieve reasonable stability, responsiveness, and minimization of social cost for future adjustments. https://bitcoincashresearch.org/t/asymmetric-moving-maxblocksize-based-on-median/197 https://bitcoincashresearch.org/t/chip-2023-01-excessive-block-size-adjustment-algorithm-ebaa-based-on-weighted-target-exponential-moving-average-wtema-for-bitcoin-cash/1037
**Criteria of a good algorithm**
In our opinion, a good maxblocksize adjustment algorithm must address the following concerns:
For predictability and stability in service operators, any increases must happen over a long window. We have observed some adjustment algorithms where it's possible to double maxblocksize over a matter of hours or days - the volatility they allow reduces the utility of an algorithmic approach.
The algorithm should aim to accommodate commercial bursts such as holidays, conventions, and token sales, such that user experience is not impacted by fee increases in the vast majority of times. Note that while a rapid-increase algorithm can satisfy this for a user, it'll conflict with # 1 above in that it does not offer a predictable, stable course for operators - it is therefore likely preferable to just keep a healthy maxblocksize with a large buffer well above average usage.
The algorithm should aim to reduce costs for operator in times of commercial downturn. It is inevitable in BCH's many more years and decades of operation that it'll see ups and downs, and it's important that higher operating costs justified during boom times do not unreasonably burden services during the bust years. During a long downturn, a reasonable limit that defends well against unpredictably high bursts of costs (see "Considerations" above) can mean the difference between keeping or losing services. Such adjustments can happen slowly, but should not be removed altogether.
The algorithm should be well-tested against edge cases that may cause undesirable volatility. This is especially important considering the history of BCH's difficulty adjustment algorithm, which was plagued by instability for years both in the Emergency Adjustment era of 2017-2018, and fixed-window-based era of 2018-2020. Blocksize algorithms must learn well from this experience and aim to minimize potential vectors of trouble. https://documentation.cash/protocol/forks/bch-uahf https://documentation.cash/protocol/forks/hf-20171113
**Additional notes on miner control**
Some may say that usage-based algorithms take control out of the hand of miners; in our opinion this is not true. Miners today have an additional control vector in the form of a "soft cap" that allows them to easily specify maximum size **for the blocks they themselves mine** that is below network-wide maxblocksize. Adjusting this cap allows them an input into any usage-based algorithm, as the algorithms depend on the size of past blocks actually mined.
It is also important to stress that while the quality of any algorithm adopted must be very high, it is not necessary to be perfect. A large part of the value of the algorithm is that it relieves social costs going forward. In the case where an algorithm is found to need adjustment or even determined to be inadequate, it is certainly possible for the ecosystem to change it - through a CHIP or other possible systems - just like any other consensus rule.
**Author:** imaginary_username
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://blog.generalprotocols.com/
Key issues for next generation wallets to support CashTokens and UTXO Smart Contracts
Tiers of token wallets
CashTokens on BCH is a unique facility that satisfies two value propositions at once:
Traditional "tokens" where fungible or non-fungible tokens represent items of value, and are transferred and traded on a public blockchain to take advantage of its permissionless security properties.
Computation "tokens" where information is passed among both onchain contracts and off-chain entities for more complex operations.
Generally when developers talk "CashTokens wallet" they refer to 1), which is better understood, and we'll describe its requirements briefly. To unleash the full power of CashTokens on BCH though, we will need to address 2) in detail as well.
Conventional token-handling
Traditional token-handling wallets shall be expected to have the following features:
Sending
Receiving
Easy identification of Category IDs
Access to history and transaction details(for full featured wallets) or balance (for minimalists)
Detailed description of NFT characteristics (mutable, mintable...)
Ability to handle BCH in parallel
Noncustodial backup, through seed words or otherwise
Sending tokens to requests, such as a version of BIP21
It can also optionally have the following features that are can immediately yield a large improvement to quality of life:
Minting, if a standard is agreed upon
Identification of tokens, perhaps through Metadata Protocol
Sending BCH in a single output along with tokens
Sending tokens to Payment Protocols (such as a version of BIP70 or json-payment-protocol).
Other advanced features available to BCH such as fusion, shuffle, coin-management are desirable, but may not be immediately needed for "ready to go" functionality.
Note that even in a setup where these advanced features are available for native BCH, they may not be available to fungible tokens due to liquidity, demand or general maintenance hurdles, even if the implementation is theoretically straightforward.
Information-carrying tokens and smart contracts
The primary advantage of CashTokens over other UTXO token protocols lies in its ability to interact as information-carrier within an expressive BCH context. Without at least one competent wallet to take advantage of that this functionality can be stunted for a very long time. Facilitating it requires, as prerequisite, that the wallet be able to:
**Contexts** : Display different *contexts* in interface, depending on the contract being handled. More on this below.
**External Interactions** :Ability to interactively exchange information with external, non-node entities. An external example here is MetaMask, which is able to interact with web pages; an existing BCH example is Cashfusion, which interacts with the Cashfusion server. Early wallets may want to weigh their scope on whether to include ability to interact with servers in general.
**Script-spending**: Given a template and sufficient supporting information, spend a UTXO in a custom way, perhaps with interaction steps to fetch additional information.
**UTXO Discoverability**: Given a template and private seed or backup, query servers using custom filter criteria and fetch spendable UTXOs, along with possible additional information required to spend them. This is important in the UTXO context, as there is no singular, per user abstracted account where everything goes to and from. For some contracts discoverability from seed may be impractical, in which case suitably secure wallet backups need to be specified.
**Interaction history backup**: Conventional wallets generally converge onto backing up by BIP39 seeds, from which an entire P2PKH history can be retrieved directly from the blockchain. Interactive script wallets have no such luxury - just as in the case of UTXOs, the wallets must either backup its history directly, or have templates where custom discovery-from-seed methods are specified.
**Template verification and use** : Custom interactions can be tremendously insecure, a problem which MetaMask worked around by prompting trust on individual website certificates. We can do better - a templating system independent from the Web such as Bitauth can facilitate a permissionless, trust-once-per-usecase system that is much more secure.
These capabilities shall form a generalized baseline upon which countless customizations are possible via templates, and the ability of CashTokens to transfer information will lie at the heart of many of these contracts. We'll explore CashTokens primitives in custom contracts in another article.
**On contexts**
Conventional wallets typically has one context, or at most two if we separate BCH and token spending, as seen in Electron-Cash-SLP. It is, however, impossible for one interface to account for all possible script usecases, many of whom will require customized input and output elements. It is therefore important for wallets to accommodate possible different interfaces, perhaps via tabbing, specified in each template's context.
At the most basic, a "universal" interface is conceivable where templates specify all needed script input fields in their raw requirements such as num/binary-strings/public key..., and the wallet simply serializes the inputs to be used as-is in Script. This can, however, be very user unfriendly, especially for elements that gather from an external source, such as an oracle, instead of from the user. On the other hand, it would be unwise to allow arbitrary interaction and code-running with a remote server, as any vulnerabilities introduced by one template is no longer contained within its context.
On EVM wallets like MetaMask, contexts are usually granted by permitting access to web domains. The EVM/MetaMask model, however, suffers from high trust on domain name owners, as well as opaque and possibly unbounded permissions given to websites that can be changed in arbitrary ways. We assert that a trust-once-per-usecase "template" model, similar to how users traditionally trust downloaded software, is more appropriate for our purposes.
A good balance can be struck for a template-based wallet, if it adheres to the following rules:
**A template must not run arbitrary remote code.** The only data that can be fetched from a remote server are direct inputs to Bitcoin Cash script, or (mutable) parts of Bitcoin Cash script itself. Any non-Script code must be local, and requires an explicit template update to change.
**Template contexts must be isolated.** Templates shall not automatically pass information among themselves upon execution, without explicit user permission. They shall each have their isolated seed derivation path, backup file, interface instructions, etc. The wallet shall enforce this at low level design; failure to do so will result in contagion risk from a malicious template that the user inadvertently imported. While this contagion risk may be acceptable in a casual or small-community context, it is not scalable to wider, less sophisticated pools of users and developers.
**No persistent permissions for mutable interactions.** Certain interactions, such as fetching a piece of Bitcoin Cash Script from external sources, are "mutable": they do not simply fill inputs on already trusted Script, but may generate additional contexts that are not explicitly trusted yet. Each of these interactions must be explicitly granted permission each time. Developers who wish to streamline user experience should seek to minimize such interactions, and seek to contain all of their Script in the initial template itself.
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://blog.generalprotocols.com/
General Protocols Sponsorship for Q2 2023
https://youtu.be/IJxcq-L6KeQ
In Q2 2023, General Protocols is supporting a number of on-going projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q2 2023:
Electron Cash: *A Bitcoin Cash SPV wallet* https://electroncash.org/
Libauth: *An ultra-lightweight JavaScript library for Bitcoin, Bitcoin Cash, and Bitauth applications.* https://github.com/bitauth/libauth
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.* https://bitcoincashnode.org/en/
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.* https://cashscript.org/
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.* https://github.com/cculianu/Fulcrum
BCA: *Bitcoincashautist is a decisive, dedicated Bitcoin Cash community member who works tirelessly to improve the quality of BCH CHIPs (CasH Improvement Proposals), availability of information and more.* https://twitter.com/bchautist
The Bitcoin Cash Podcast: *A podcast dedicated to Bitcoin Cash, aimed at accelerating BCH adoption, by providing news, updates and entertaining media all related to Bitcoin Cash. Since January 2021, the Bitcoin Cash Podcast has produced over 70 episodes and is still going strong.*
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://bitcoincashpodcast.com/ https://blog.generalprotocols.com/
A Focus on the Bitcoin Cash Ecosystem: 07 CashTokens
https://youtu.be/81fJNke4yJI
CashTokens are a new feature of the Bitcoin Cash network, scheduled as part of the May 2023 BCH upgrade. It allows anyone to create their own tokens on the BCH blockchain and creates numerous possibilities for developers, businesses, and entrepreneurs who want to create custom tokens for various purposes. Whether you want to create a loyalty program for your business, a rewards system for your website, or a tradable loan, CashTokens makes it easy and accessible on-chain.
One of the biggest advantages of CashTokens is that they are extremely fast and inexpensive to use due to their UTXO design and the high throughput of the Bitcoin Cash network. This makes them perfect for everything from occasional personal banking to a basis for a high-frequency, smart contract-based trading platform
Like Bitcoin Cash itself, CashTokens is completely decentralized. This means that there is no central authority controlling the issuance or distribution of tokens. Instead, anyone can create a token and use it as they see fit.
The CashTokens upgrade is a major step forward for the Bitcoin Cash ecosystem, and it has the potential to revolutionize decentralized finance using a UTXO blockchain.
Want to learn more? Follow these links:
CashTokens project on GitHub
What are CashTokens? (YouTube explainer video) https://github.com/bitjson/cashtokens https://www.youtube.com/watch?v=T7rzmPlZqxI
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://blog.generalprotocols.com/
A Focus on the Bitcoin Cash Ecosystem: 06 AnyHedge
https://www.youtube.com/watch?v=OFFtsUIaJRk
AnyHedge is a smart contract on Bitcoin Cash mainchain, written by General Protocols.
AnyHedge allows you to take leveraged long positions, or hedge your fiat value in a peer-to-peer manner. One party in the contract stabilizes the value of their Bitcoin Cash in their chosen asset, whilst the other party chooses to speculate with leverage. The combined funds of the contract ensure that all eventualities of any price movement are covered within the locked funds of the contract, and therefore there is no counter-party risk.
AnyHedge is a permissionless, non-custodial, and on-chain solution to price volatility, and trustless leverage trading. The potential of the AnyHedge contract is vast, such as on-chain futures through a decentralized exchange, or auto-integration of price stabilization for merchant apps, all with secure, near-instant, always low-fee transactions. https://generalprotocols.com
BCH Bull is one of the first apps built with AnyHedge. It's super easy to take contract positions—all on-chain. And since it's built on Bitcoin Cash, you don't need to wait on confirmations to start trading.
The Paytaca wallet is the first Bitcoin Cash wallet to also integrate the AnyHedge protocol, so users can create contracts directly from their wallet. https://www.bchbull.com https://www.paytaca.com/
**Want to learn more? Follow these links:**
AnyHedge.com
AnyHedge whitepaper
BCHBull.com
BCHBull contract simulator
Paytaca.com https://www.anyhedge.com https://anyhedge.com/whitepaper/introduction/ https://bchbull.com https://www.bchbull.com/thecontract.html https://paytaca.com
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://blog.generalprotocols.com/
General Protocols Sponsorship for Q1 2023
https://vimeo.com/795023460
In Q1 2023, General Protocols is supporting a number of on-going projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q1 2023:
Libauth: *An ultra-lightweight JavaScript library for Bitcoin, Bitcoin Cash, and Bitauth applications.*
Electron Cash: *A Bitcoin Cash Simplified Payment Verification Wallet*
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.*
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.*
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.*
BCA: Bitcoincashautist is a dedicated Bitcoin Cash community member, working on improving the quality of BCH CHIPs (CasH Improvement Proposals).
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://github.com/bitauth/libauth https://electroncash.org/ https://github.com/cculianu/Fulcrum https://cashscript.org/ https://bitcoincashnode.org/en/ https://twitter.com/bchautist https://blog.generalprotocols.com/
General Protocols Sponsorship for Q4 2022
https://vimeo.com/775261458
In Q4 2022, General Protocols is supporting a number of on-going projects within the Bitcoin Cash community. We have a strong commitment to scale our sponsorships as revenue grows. In the future, we will evaluate further sponsorship opportunities for other worthwhile projects in the expanding Bitcoin Cash ecosystem.
Here are the projects we are supporting in Q4 2022:
Libauth: *An ultra-lightweight JavaScript library for Bitcoin, Bitcoin Cash, and Bitauth applications.*
Electron Cash: *A Bitcoin Cash Simplified Payment Verification Wallet*
cculianu/Fulcrum: *A fast & nimble SPV server for Bitcoin Cash & Bitcoin BTC.*
CashScript: *CashScript is a high-level programming language for smart contracts on Bitcoin Cash.*
BCHN: *A professional, miner-friendly node that solves practical problems for Bitcoin Cash.*
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://github.com/bitauth/libauth https://electroncash.org/ https://github.com/cculianu/Fulcrum https://cashscript.org/ https://bitcoincashnode.org/en/ https://blog.generalprotocols.com/
General Protocols Statement on CashTokens and P2SH32 CHIP Proposals for the May 2023 BCH Upgrade
CashTokens
CashTokens is a scripting and transaction format modification plan for Bitcoin Cash, proposed by Jason Dreyzehner in February of 2022. It has since been widely promoted, intensely debated over in public among many BCH developers and interested community members, and is in final stages of testing and implementation before commitment for network-wide activation in May 2023 per the CHIP process. https://github.com/bitjson/cashtokens
Due to the proposal's name, it was widely expected to be a straightforward "consensus tokenization" proposal for BCH, comparable to colored coins and SLP protocols that came before it. CashTokens, however, is designed with UTXO smart contract interactions as a priority, and it should be viewed as powerful, message-carrying general computing "tokens" instead of limited-function tradable asset-carriers. At General Protocols, we believe we are in a position to take full advantage of the proposal once it is activated.
There are several specific design choices we like about CashTokens, that are especially relevant to our goals as a company:
1. Non-fungible tokens and contract abstraction
General Protocol's current and planned product lineup are all P2SH-based smart contract derivatives that lock up BCH as backing. One difficulty we face is the fact that contracts are mostly static once formed. Transferring ownership of contracts permissionlessly is necessary for liquid markets to form trading these contracts, which enables much more efficient service.
As of 2022, transferability is possible with proper covenant setups. These setups, however, are both cumbersome - they consume significant space within unlocking scripts - as well as difficult to standardize, as wallets will need to recognize, integrate scripting libraries and support each new contract in order to transfer and trade them.
With the CashTokens proposal, the contracts themselves do not need to be transferred, but can instead pay out to non-fungible tokens that can themselves be transferred. Wallets can be configured to support sending and receiving NFTs with minimal effort, and in one step enable transferability of all future contract permutations.
NFT capabilities such as commitments (allowing localized state on a token), minting (allowing duplication) and mutability (allowing changing of state, likely encumbered by covenants) as specified in the CashTokens proposal further augment transferability by enabling more complex setups. While these capabilities can likely also be emulated using complex covenant setups, having explicit capabilities in the protocol again should greatly lower barriers of entry for both contract and wallet builders. We will explore these interactions in future posts.
2. Preserving the BCH design philosophy: Self-contained transactions
Bitcoin-like UTXO chains, including BCH, derive much of their advantages over account-based chains like Ethereum from their design. In UTXO chains, each transaction is self-contained for evaluation with minimal input from the global state (which generally only includes the UTXO set). One can either spend the outputs, or one cannot. This self-contained design enables better scalability and less complexity on UTXO chains.
Unlike some other prior proposals, CashTokens transactions are entirely self-contained. There are no additional global state or encumbrances like metadata and global covenants to refer to while evaluating a CashTokens-enabled transaction, keeping execution localized. We believe this is important for preserving BCH scalability, which is a fundamental value proposition of the coin.
3. Backwards compatibility
We cannot overstate how important it is for both our company and the BCH ecosystem as a whole that upgrades preserve existing software assumptions as much as possible. Not only are breaking upgrades detrimental to adoption as companies weigh costly retooling against benefits of continuing operations on BCH, these breakages have also acted as triggers for community and eventually chain fragmentation in the past.
CashTokens, as far as we understand, does not break existing software. Services that do not want to deal with tokens can simply ignore the scheme's existence, and would only need to invest work-hours if they wish to recognize and participate in CashTokens transactions.
Contrary to certain previous token schemes like SLP where unaware wallets can accidentally burn tokens, it is nigh impossible for an unupgraded wallet to ruin a CashTokens output, spending would simply be unavailable. This is a long-requested trait from the community that should further increase the proposal's appeal.
4. Non-genesis category ID
One interesting CashTokens design choice is the use of txids of input transactions to Genesis as category IDs of generated tokens. This setup enables generation of covenants that use tokens generated in the same transaction in its clauses.
A possible alternative setup, as discussed by community members at the design phase, may have the category ID locked to the txid of the Genesis transaction. A covenant including the generated tokens will, under this setup, have to be generated separately or in subsequent transactions. We believe the atomicity made possible by CashToken's design will enable easier design of complex covenant setups with less trust assumptions in the future.
P2SH32
Scripting on BCH is generally done as P2SH (pay-to-scripthash) contracts, which is the lifeblood of GP's current and future business plans. As outlined in the P2SH32 proposal, P2SH suffers from a cryptographic weakness that affects security assumptions among multiple trustless parties at high amounts. While sophisticated mitigations are sometimes available, designing them can be challenging, and may introduce further difficulties down the line. This weakness not only makes it difficult for GP to accommodate very large amounts, it can even affect our day-to-day operations as a BCH company, such as multisig spending. https://gitlab.com/0353F40E/p2sh32/-/blob/main/CHIP-2022-05_Pay-to-Script-Hash-32_(P2SH32)_for_Bitcoin_Cash.md
The solution brought forth by the P2SH32 proposal is straightforward, does not break existing software, and we believe will provide a solid foundation for GP to build our business upon.
And for these reasons, as well as the very well explored rationale sections, General Protocols will like to declare our support for the CashTokens and P2SH32 proposals. We understand that minor bugs/insufficiencies may still be discovered, and we'll encourage the ecosystem to put opinions up as we approach commitment.
Version Restriction and Relaxing Transaction Size Restrictions
Also on the table for commitment are two more proposals: Transaction Version Restriction and Relaxation of Transaction Size Lower Bounds. We at General Protocols do not directly benefit from these changes, but do view them as necessary and straightforward cleanups that should simplify upgrades and mining on BCH going forward. We support both of these proposals. https://gitlab.com/bitcoin.cash/chips/-/blob/master/CHIP-2021-01-Restrict%20Transaction%20Versions.md https://gitlab.com/bitcoin.cash/chips/-/blob/master/CHIP-2021-01-Allow%20Smaller%20Transactions.md
****General Protocols Blog****
This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://blog.generalprotocols.com/
@GeneralProtocols
