-
Removal of the Transaction Chaining Limit
-
Currently a maximum depth of 50 transactions may be chained together without a block confirmation. The original need for this was inherited from a problem unique to BTC dubbed “Child Pays For Parent” in order to resolve transactions that were “stuck” due to full blocks and high average transaction fees. Since BCH does not have this problem, we have no (or limited) need for Child Pays For Parent, and therefore can remove the maximum chained transaction limit. This proposal also suggests the removal of Child Pays For Parent, or at least sets the maximum depth of CPFP to 1.
-
In some scenarios, a user may unintentionally receive BCH they cannot spend until a block is mined. This greatly degrades the user experience and degrades BCH as fast electronic cash in these scenarios and often leads to situations that confuse the user.
-
Users will always be able to spend coins received to them that they are able to unlock.
-
An uncoordinated rollout may (allegedly) degrade the security of 0-conf transactions.
- Payment Protocol ‘next’.
-
Description in a couple sentences what the change is technically
Our wallets and point-of-sale apps currently use a mix of payment protocols, and none of the wallets actually fully follow the bip70 protocol. Its a mess.
This project aims to be a long-running project in order to iterate and improve the payment protocol as shared between the many different stake-holders. -
Problem it’s trying to solve.
Benefits are many. In short it is a much better user-experience all round, but here is a list:- We should be able to make an advanced payment protocol work between two mobile users so neither has to have a server, a certificate etc. They just need to be in the same room.
- Merchant gets notified about progress in steps instead of one “done”.
- makes social engineering near impossible.
- Payments are checked by merchant before sending to miners.
- Risky transactions are either rejected or a higher fee is demanded.
- Double Spend risk goes down considerably.
- Customer doesn’t require Internet connection if they can use bluetooth or animated QR.
- The customer wallet automatically records extra information like who is being paid.
- The customer wallet learns both the BCH value and the Euro/USD value and thus
can inform the customer if the exchange rate is fair. - There is never any doubt, at both parties, if a payment has succeeded or failed.
- A return-address can automatically be included to refund within the law.
- Merchant can request payment to any script or use any transaction features.
-
Potential positive impact on ecosystem
I believe that the number one reason we are not growing faster is the user experience for merchants and buyers. Both on the Internet as well as in brick/martar stores there is a lot that we can still improve upon. The positive impact is hard to measure, but essentially this will be a boon for adoption. -
Potential negative impact on ecosystem
We already have 3 payment protocols, none of them universally supported, none of them, ehm, “foolproof”. But they are out there and they are to be replaced. The problem with a new standard is that its a new standard.
- Fee Research
-
Description in a couple sentences what the change is technically
This is research that should enable a miner to select transactions to put in a block based on days-destroyed or ratio of inputs/outputs. -
Problem it’s trying to solve
There is a basic problem in the client that we centrally plan the fee. Practically all wallets hardcode it to 1sat/byte. This is not an open market and as we move on to bigger blocks the lack of market forces make solving things like spam difficult. It also makes it very hard to improve user experience by prioritizing transactions as well as making it hard for miners to actually getting paid more fees by people that are in a hurry.
This research should find out a best default for miners to use which allows us to solve congestion by prioritizing real economic traffic over chats or rapid payments using Coin-age of spent coin (days-destroyed).
This research also aims to help scaling by keeping the UTXO small and avoiding stuck coins by making cheaper transactions based on Ratio of inputs to outputs in one transaction.
Last, this research should allow us to remove the dust limit, or at least severely lower it. -
Potential positive impact on ecosystem
Removing centally planned rules and giving the miners the ability to literally define their input model based on fees is a long term requirement. We may not want to face that we need this eventually, but it doesn’t hurt researching it now. -
Potential negative impact on ecosystem
None that I am aware off.
Xthinner propagation protocol
Description: An improved block propagation protocol that has less “failure rate” and less, yet still very desirable, efficiency improvements compared to Graphene. Details by Jonathan Toomim
Problem it solves: Block propagation improvements cut back on orphan rates and is necessary to maintain mining diversity when blocks get larger.
Potential positive impact: Bigger blocks unlocked! Also, a nice side effect is it also cuts back on the impact additional transactions have on orphan rate, making them desirable for inclusion at lower fees.
Potential negative impact: Any new communication protocol will have to undergo evaluation and testing to make sure it does not have vulnerabilities exploitable for DoS or worse. We will also have to determine how it interacts with other block compression protocols like Graphene, and existing Xthin/Compactblocks, where switching determination is itself a source of additional workload on limited developer time.
- 256-bit P2SH addresses
- P2SH addresses are currently 160-bit, see BIP16. I propose another standard script “OP_HASH256 <32-byte data> OP_EQUAL”. These scripts should get the same consensus rule as bip16 scripts, i.e., in addition to checking the hash, the last item on the input stack, the redeemScript is evaluated. Moreover wallets should support cashaddr addresses with type P2SH (1) and size 256 (3) and translate them to these kind of output scripts.
- Currently only 160-bit addresses are supported, which are prone to collision attack, especially in the setting where p2sh scripts are used for smart contracts between two or more parties. A malicious party could produce a collision, give the other party an innocent looking public key that allows them to redeem the p2sh address using a colliding scripts for which they have full control.
- Secure smart contracts without complicated key commitment schemes to avoid collision attacks. Very simple extension of a widely-used and well-tested script type.
- This is both a consensus change (soft fork) and a wallet infrastructure change. If wallets don’t support the new address format, they obviously cannot be used to fund a smart contract using the new addresses. This also affects withdrawal addresses on exchanges or hardware wallets. The wallet change doesn’t have to be deployed by all wallets at the same time, though, since a different wallet can be used to fund the smart contract address.
this may very well be the beginning of a new transaction format!
- Xthinner proto-
Wait… im_uname stole my idea and is trying to take credit for it himself. Fine…
- Blocktorrent protocol
- Better block propagation method that splits blocks into independently verifiable IP packet-sized chunks. Allows blocks to be transmitted in a swarm at the speed of Bittorrent instead of Napster.
- Scaling
- Enable scaling to the 1 GB/ (3k tx/sec) level and beyond
- A lot of new code and 0-day risk
Both Blocktorrent and Xthinner are opt-in and require no backwards-incompatible protocol changes. They can be deployed asynchronously and permissionlessly by nodes.
- Blocksize limit increase after Xthinner and/or Blocktorrent
- Increase the default block size limits for BCH, potentially according to a default schedule like BIP101
- Prevent a repeat of 2015-2017 in which blocksize increases weren’t performed before they were needed
- Fidelity effect
- Orphans; distraction from other projects
Link to an ongoing discussion regarding improved math capability, especially larger integers and multiplication.
- Block time reduction
- Reduce the target block time to e.g. 2.5 minutes or 1.0 minutes after Blocktorrent is active
- User experience improvement
- Improves confirmation times. Makes solo mining easier (lower variance). Reduces chain limit pressure.
- Somewhat complicated. Requires changing halving schedule, coins per block, and some opcode changes for height-based locktime. Also increases baseline block orphan rate and may reduce scalability (but Blocktorrent may mitigate this).
This item is probably more like 2022 or 2023, because it’s a huge change, but I’m including it here because I think it’s fascinating and worth looking into.
- Block DAG (e.g. Jute)
- Convert the blockchain into a block DAG in order to neutralize the incentive problem with orphans. Instead of marking entire blocks invalid and throwing them out, we only throw out individual invalid transactions.
- Allows for very fast block times (~6 sec)
- Claims to solve selfish mining. Makes mining variance a non-issue. Massive UX improvement. Dramatically enhanced scalability (no need to keep orphan rate ≤ 3%). Reduces effect of network latency on revenue.
- Huge changes. Changes block header format. Changes game theory. Threat model and security claims have not been fully reviewed by third parties.
Please calm down, you were being credited and nobody else saw his post as taking credit.
Also, this site is about collaboration first and foremost. It would be nice to aim to share ownership of ideas, that makes things go much smoother.
It was just a joke. I’m sorry that wasn’t clear.
FWIW, I got it and thought it was funny. 
I am not very technical but think about it from the perspective of onboarding any use case that might bring in a very high amount of usage
1. Name: Default blocklimit behavior to be adjustable
2. Description in a couple sentences what the change is technically:
Changing the default blocksize limit behavior to be dynamic, however miners could change this setting and set their own limit
3. Problem it’s trying to solve
Even though limit is currently adjustable, there can be some friction on changing the settings to allow larger blocks. Having the default behaviour be an adjustable limit would bring confidence to people / usecases that will require a very high number of transactions and assurement that they will not be driven out by fees
4. Potential positive impact on ecosystem
Large businesses wanting to onboard a lot of users or a high number of transactions will be able to do it with a higher confidence of maintained lower fees (would answer the concerns of heads of state if they want to transact on BCH or large businesses with millions of users building their infrastructure on top of BCH)
5. Potential negative impact on ecosystem
Could be abused by some people if not implemented in the best way.
Can affect miner revenue (however, they will always have the option to set their new limit manually,i.e. opt-in)
The adjustable limit could exceed the network capacity or have guardrails that will act as a blocksize limit
We introduced a new customisable dividend tool that is automated in the Zapit wallet as demonstrated here. We had to hardcode a limit of 900 addresses due to the 50 transaction limit (as each SLP transaction can have only 18 outputs).
Most of the token projects with some sort of utility will have to send dividends/airdrops to well over 900 addresses which isn’t possible due to the current 50 transaction limit. Of course one can always send out manually but its a huge blow to user experience which we at Zapit are focusing on.
The dividend tool can be used by any regular individual without much knowledge about BCH since everything is automated but the 900 address limit is still a problem if larger projects want to use the tool.
We also reward users using a payment interface that has millions of transactions per day. To tap into that market, we need to make sure that the limit is at least raised before we move forward with onboarding more users.
As we want to be able to send rewards every time users make a transaction with that payment interface, if there are more than 50 users that have to be rewarded within 10 minutes, we face a problem.
while the 50 limit will likely be worked on in the near future, isn’t the limit for 18^50 instead of 18*50? It’s just slightly more complex arithmetic 
Name
Multiple OP_RETURNs
Description in a couple sentences what the change is technically
Change in either standardness rules regarding OP_RETURN to allow multiple outputs with OP_RETURN in the same transaction, or change in interpretation of OP_RETURN itself to use it as a separator within the same OP_RETURN output.
Problem it’s trying to solve
Making OP_RETURN based protocols interoperable.
Potential positive impact on ecosystem
By supporting multiple OP_RETURNs in a way that makes it possible to have interoperable OP_RETURN protocols, we signal to developers that are interested in making such protocol that BCH desires their business. This would allow new usecases as well as empower existing usecases, ultimately working towards more adoption and a stronger network effect for BCH.
Potential negative impact on ecosystem
Depending on developer preference, could be a point of contention.
Depending on implementation, could end up encouraging more data storage on-chain.
Depending on implementation, could disrupt existing OP_RETURN based protocols or tooling.