Refuse sending BCH transactions to addresses starting with a 3.
Allow miners to come to consensus on double spend transactions before they have been mined into a block (pre-consensus).
Shorten block mining target from 10 minutes to 1 minute, decreasing the average time for new transactions to make it into a block.
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.
Revise Difficulty Adjustment Algorithm to further improve block times using a new PID control algorithm
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 Proof-of-Work Target that Minimizes Blockchain Mining Variance
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!
Switch the standard denomination of Bitcoin Cash to 'bits' (1 millionth of a Bitcoin) and switch the ticker from 'BCH' to 'BIT'.
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.
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.
OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY will be upgraded to accept Schnorr signatures in a way that is compatible with batch verification.
Introduce a set of improvements (phase 1) and extensions (phase 2) to improve both the performance and functionality of the Graphene block relay protocol.
Trustless, obfuscated coin consolidation. A complement to CashShuffle privacy/fungibility.
Update to inform other nodes of double spend attempts immediately to improve the reliability of 0-conf transactions.
Implementation in progress at: https://gitlab.com/FloweeTheHub/thehub/merge_requests/10
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.
Provide an alternative to the ElectrumX Electrum server by leveraging the more efficient Electrs Electrum server in Bitcoin Unlimited.
A high level language enabling basic smart contract functionality on Bitcoin Cash.
Enable faster spending of UTXOs.
As per existing standardness checks, enforce that all pushed data is a minimal representation at the script layer.
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.
Re-activate the following additional opcodes: OP_MUL, OP_LSHIFT, OP_RSHIFT, and OP_INVERT.
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.
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.
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.
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.
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.
Revise Difficulty Adjustment Algorithm
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).
Transactions shall be considered invalid if an opcode with number greater than 96 (hex encoding 0x60) appears in a scriptSig.
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.
OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is valid with respect to a message and a public key. OP_CHECKDATASIG permits data to be imported into a script, and have its validity checked against some signing authority such as an "Oracle".
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.
Transactions that are smaller than 100 bytes shall be considered invalid. This protects against a Merkle tree vulnerability that allows attackers to spoof transactions against SPV wallets.
With the exception of the coinbase transaction, transactions within a block must be sorted in numerically ascending order of the transaction id. This proposal is also known as Lexical Transaction Order. It simultaneously removes the existing Topological Transaction Order constraint.
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.
A (now withdrawn) proposal to add OP_REVERSE to Script.
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.
Consider all blocks in size up to 128MB to be valid by default.
Re-activate the following additional opcodes: OP_MUL, OP_LSHIFT, OP_RSHIFT, and OP_INVERT.
Enable Binary Contracts via OP_DATASIGVERIFY. Superseded by OP_CHECKDATASIG(VERIFY).
Loosen the restriction on the number of instructions executed per script (currently 201) to 500.