This proposal includes two new BCH virtual machine (VM) operations, OP_BEGIN and OP_UNTIL, which enable a variety of loop constructions in BCH contracts without increasing the processing or memory requirements of the VM.
Right now every wallet software does slightly different things with transaction preparation, which makes it possible for chain analysis to fingerprint transaction and detect which wallet is being used. It would be nice if at least we could have all P2PKH transactions look ‘the same’ so this isn’t possible.
Updating this to match the MAX_SCRIPT_SIZE would effectively eliminate it as a roadblock to complex use cases, while still serving its purpose for DOS prevention.
The basic idea is that we look at recent block history. We calculate recent usage and use it to set a new limit that is much higher. We adjust every time a new block is found. With this the blocks are unlikely to ever go full, even at load peaks.
Transactions shall have as a version number of no other value than 1 or 2.
Blocks that have transactions which violate this rule shall be deemed invalid.
CashTokens are a Bitcoin Cash virtual machine-enforced scheme for issuing, validating, and redeeming tokens. CashTokens enable on-chain token sales, transferable synthetic assets, decentralized exchanges, and prediction markets on Bitcoin Cash.
Support integers larger than 32 bit for the purposes of improving the capability of smart contracts.
Previous discussion on this: https://youtu.be/XmH3A7Q0BJw?t=5400
Facilitate large scripts by moving them off-chain but tying them to a simple verify-only smart contract on-chain.
Allow for denominations smaller than 1 satoshi.
Guarantee that old UTXOs spent without a miner fee attached will make it into a block. These are also known as "Priority Transactions".
Allow miners to come to consensus on double spend transactions before they have been mined into a block (pre-consensus).
Taproot is an interesting technology to enable multiparty privacy on a bitcoin.
Refuse sending BCH transactions to addresses starting with a 3.
Storage of human-meaningful transactional metadata on a per-transaction basis. Enriches the blockchain stored technical identifier with contextual information, such as who the sender is, what unit of account the sender was using, what exchange rate the sender used for calculating the technical amount and similar data.
Blocktorrent is a method for breaking a block into small independently verifiable chunks for transmission, where each chunk is about one IP packet (a bit less than 1500 bytes) in size. In the same way that Bittorrent was faster than Napster, Blocktorrent should be faster than Xthin(ner).
Support for better, more detailed block-level metadata.
Prevent deep re-org attacks by penalizing alternate chaintips by a factor that is calculated by averaging the delays (in seconds) of each opposing block.
A non-interactive fungibility solution for transactional privacy.
the consumer will make a special ZCF transaction that pays the merchant and simultaneously posts a security deposit. If the transaction is honest, the consumer can later reclaim his deposit. If he tries to double spend, he necessarily reveals a second signature over the same public key which is then used by miners to claim his deposit for themselves. Pretty clever!
Introduce a set of improvements (phase 1) and extensions (phase 2) to improve both the performance and functionality of the Graphene block relay protocol.
This opcode would allow for significant size optimization to covenant transactions.
A Proof-of-Work Target that Minimizes Blockchain Mining Variance
This draft reusable address format, if widely adopted, seeks to provide a major improvement over existing systems in terms of net gain in all five areas, as well as more flexibility in choosing desirable compromises depending on usecases under one common format.
Using weak proof-of-work for instant confirmations on Bitcoin Cash.
Modified fee structure to allow for an order of magnitude decrease in fees for typical transactions (not strictly a consensus change, but an important change being included with the release).
Currently on hold.
A high level smart contracts language for Bitcoin Cash, designed for explicitness and safety.
Improved xthin that leverages canonical transaction ordering.
OpenCAP is a protocol that defines the standard by which cryptocurrency wallets can communicate with servers to relate aliases to cryptocurrency addresses.
The protocol allows for the decentralization of the alias -> address relationship.
This rule prevents a hash griding attack, where SPV wallets can confuse a 64 byte transaction for a merkle node. The amount of entropy in each 32-byte sections of the transaction is insufficient to prevent a preimage attack. In this case, a valid transaction could be found with a hash equal to the first, or last, 32 bytes of a 64-byte transaction.
CashDB delivers a specialized storage dedicated to the UTXO dataset of Bitcoin Cash. This component is intended to support livechain apps such as Bitcoin ABC or ElectrumX.
A generic overlay network based on IPFSâ€™s libp2p.
Add "cash" in addition to "bit" as a term for 100 (one hundred) satoshi or 1/1,000,000 (one one-millionth) of a bitcoin cash BCH (i.e. 0.000001 BCH). Further, we propose the unofficial ISO code "XCH" to represent a cash unit (millionth of a BCH unit). -- UPDATE: For French translations only.
By expanding the upper bound of arithmetic inputs to 9223372036854775807, contracts can efficiently operate on values larger than the total possible satoshi value of any transaction output (approx. 2100000000000000). This enables contracts to manage balances of any size, clearing the way for large, public decentralized applications.
This proposal adds a set of new virtual machine (VM) operations which enable BCH contracts to efficiently access details about the current transaction like output values, recipients, and more – without increasing transaction validation costs.
Update to inform other nodes of double spend attempts immediately to improve the reliability of 0-conf transactions.
Original implementation progress: https://gitlab.com/FloweeTheHub/thehub/merge_requests/10
We propose to make presence of multiple OP_RETURN outputs qualify as standard transactions subject to the existing 223 byte limit for OP_RETURNs across all outputs of the transaction.
Safely increase or remove the 50 chained transaction limit.
Allows faster re-spending of unconfirmed transactions.
Trustless, obfuscated coin consolidation. A complement to CashShuffle privacy/fungibility.
A high level language enabling basic smart contract functionality on Bitcoin Cash.
Improved sigops counting.
OP_REVERSEBYTES reverses the bytes of the top stackitem.
Added support for MuSig, a new way to handle signatures on Bitcoin.
Revise Difficulty Adjustment Algorithm
Provide an alternative to the ElectrumX Electrum server by leveraging the more efficient Electrs Electrum server in Bitcoin Unlimited.
As per existing standardness checks, enforce that all pushed data is a minimal representation at the script layer.
OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY will be upgraded to accept Schnorr signatures in a way that is compatible with batch verification.
Original Satoshi codebase had lots of design decisions that limit the block size, like saving blocks in files of max 128MB. Memory usage was also spiking on large blocks and many other things.
Successfully tested 250MB block parallel validation on testnet.
This moves the txid indexer out of the full node which solves stability and maintenance problems. For instance you're node would go offline for some hours if you wanted to start a txid index.
Additionally add several other indexers with APIs of their own and each of which that can be enabled disabled separately.
CashID is an open protocol that allows secure authentication based on the public key cryptography infrastructure that is currently present in the Bitcoin Cash ecosystem. Each user can prove to a service provider that they control a specific Bitcoin Cash address by signing a challenge request, as well as provide optional metadata.
Cash Accounts is a naming system that can be used alongside regular bitcoin addresses and payment codes to simplify the process of sharing payment information.
The Hash-DB is a database written specifically for the Bitcoin Cash UTXO set.
The goal is to get a massive multi-threading UTXO database optimized based on the behavior of blockchain.
The goal of 20.000 transactions per second has been safely reached.
Supporting CB in BU would strengthen the connections between the BU peers and the rest of the network, without having to rely on intermediates.
Schnorr signatures are provably non-malleable and allow multiple parties to collaborate to produce a signature that is valid for the sum of their public keys. This is the building block for various higher-level constructions that improve efficiency and privacy.
With the last protocol upgrade, the enforcement of the CLEANSTACK rule made it impossible to recover funds from Segwit transactions. With the upgrade, there will be an exception to this rule to enable recovery of these funds once again.
Implemented as part of the Neutrino Wallet for Bitcoin Cash, Neutrino (BIP 157 & BIP 158) allows the creation of lightweight SPV wallets with strong network level privacy.
Re-activate the following additional opcodes: OP_MUL, OP_LSHIFT, OP_RSHIFT, and OP_INVERT.
CashShuffle is a protocol for allowing users to combine their transactions with others, creating obfuscation. It builds upon CoinShuffle and adds a matching service. As such, it is a more complete and usable protocol.
Simple Ledger Protocol (SLP) uses the meta data in OP_RETURN for the issuance and transfer of tokens in conjunction with standard transaction outputs that each represent a number of token units specified by the sender.
Support faster syncing by downloading a previous UTXO set from IPFS.
An efficient method of announcing new blocks.
BCH node extended version and configuration fields for transporting a generic key-value map that is meant to hold the configuration and version parameters to communicate capabilities with other nodes (such as transmission protocols like Graphene).
For a transaction to be valid, only a single non-zero item must remain on the stack upon completion of Script evaluation. If any extra data elements remain on the stack, the script evaluates to false. This is the same as BIP 62 rule #6.
BIP 135 extends the semantics of the signaling bits to cover arbitrary consensus changes, referred to under the general term 'forks'. The same range of version bits is used for signaling.
Re-enable the previously disabled opcodes which were part of the original Bitcoin design. This should enable smart contract compilers, and a variety of functionality on Bitcoin Cash.
Start accepting blocks up to 32MB by default.
To disincentivize the use of other methods to embed data into the chain, in particular via P2SH, the default datacarriersize is raised from 80 byte to 220 bytes, so it becomes the "cheapest" way of embedding data into the chain.
Enable faster spending of UTXOs, up to a chain of 500 (from 25).
The Bitcore backend is difficult and slow to setup, it is also only useful for a very small number of use-cases (this JSON server being the main one), but its API is used by a lot of projects out there.
In the spirit of FOSS, this project gives choice to users of this API and at the same time allows a bit of healthy competition.
This bitcore server uses a Flowee the Hub node for its transaction data and a Flowee Indexer for the rest.
Mitra (previously Nimbus) is a new transaction version to expand smart contract capability on Bitcoin Cash.
Switch the standard denomination of Bitcoin Cash to 'bits' (1 millionth of a Bitcoin) and switch the ticker from 'BCH' to 'BIT'.
Follow up discussion: https://www.reddit.com/r/btc/comments/k1lhgf/proposal_switch_ticker_from_bch_to_bit_shift/
Require 8% of each block reward to be sent to a specified Bitcoin Cash address.
Implemented and live on the ABC / IFP chain.
Shorten block mining target from 10 minutes to 1 minute, decreasing the average time for new transactions to make it into a block.
As per BIP 147, enforce that the dummy element in OP_CHECKMULSIG(VERIFY) is a null stack element. This will go into effect at the consensus layer.
The dummy element has been repurposed to flag for Schnorr mode when it is non-null, superseding the need for NULLDUMMY.
Atomic swaps using Electron Cash.
This project has been abandoned with the intention of eventually being replaced with atomic swaps that leverage Schnorr signatures using hidden payment channels.
BLS signatures allow combining all signatures in a block to a single signature. We can use key aggregation and a m-of-n multisig scheme without additional communication rounds without needing to rely on random number generators.
A Token Layer Protocol on Bitcoin Cash
A simple, yet powerful way to provide more human friendly front ends. The main use is to identify the user by name -or nickname- and mobile phone so wallets have data from users and users can pay to human understandable names instead of cryptographic hashes.
Enable representative tokens via GROUP.
This was effectively rejected by the community in favour of SLP.
Enable Binary Contracts via OP_DATASIGVERIFY. Superseded by OP_CHECKDATASIG(VERIFY).