BCHNopen_in_new |
Donations: 1.1339 BCH
|
|
BCHDopen_in_new |
Donations: 1.0166 BCH
|
|
Bitcoin Unlimitedopen_in_new |
Donations: 0.6005 BCH
|
|
Bitcoin Verdeopen_in_new |
Donations: 0.0613 BCH
|
This proposal defines a method for nodes to generate, distribute, validate, and consume UTXO snapshots via the BCH P2P network.
These snapshots allow for new peers to synchronize to the current state of the network without processing the entire blockchain block-by-block.
This method of synchronizing allows new nodes to join the network within a couple of hours (or less), instead of the current average of 8+ hours.
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.
Update: Possibility added with CashTokens and BiggerIntegers.
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.
This proposal replaces several poorly-targeted virtual machine (VM) limits with alternatives which protect against the same malicious cases while significantly increasing the power of the Bitcoin Cash contract system
This proposal defines a method for nodes to generate, distribute, validate, and consume UTXO snapshots via the BCH P2P network.
These snapshots allow for new peers to synchronize to the current state of the network without processing the entire blockchain block-by-block.
This method of synchronizing allows new nodes to join the network within a couple of hours (or less), instead of the current average of 8+ hours.
Furthermore, this method of synchronizing (alongside block pruning methods) allows for BCH to
Bitcoin Cash has upgraded to 64-bit integers and now with the advent of CashTokens the BCH VM enables complex applications, this poses the need both for higher-order math and for allowing overflows in intermediate calculations.
Now, shortly after the CashTokens upgrade there are already multiple different Constant ProductMarket Maker (CPMM) contracts live on the network which carefully have to consider strategies for multiplication overflows.
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.
Guarantee that old UTXOs spent without a miner fee attached will make it into a block. These are also known as "Priority Transactions".
The Deep Link Payment Protocol is meant to be used for communication between mobile wallet app and other applications.
With this protocol, the communication wallet application and other applications will be very smooth.
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.
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.
The idea of automating adjustment of blocksize limit has been entertained for a long time. The code-fork of BCH launched by BitcoinUnlimited actually implemented the dual-median algorithm proposed by Imaginary_Username.
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.
Spedn is a high level smart contracts programming language compiled to Bitcoin Script.
It is designed for explicitness and safety.
Originally an idea by Bitcoin Unlimited, Bitjson continued it and today "treeless ZCEs work today and are also a useful construction for improving finality in more complex applications (e.g. DEXs)."
Zero-Confirmation Escrows (ZCEs) are contracts which enable instant, incentive-secure payments on Bitcoin Cash. They’re particularly useful in point-of-sale, ATM, and vending applications where payers have no prior or ongoing relationship with the payee.
Refuse sending BCH transactions to addresses starting with a 3.
Completed: https://github.com/Electron-Cash/Electron-Cash/commit/e6a195b77adbfb4419808cef607c18ae3557c710
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.
Pay-to-Script-Hash-32 is a long-term solution for 80-bit P2SH collision attacks. It introduces a new address type for smart contracts that is cryptographically more secure.
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.
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
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
https://gitlab.com/snippets/1883331
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.
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.
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.
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.