[Bitcoin-ml] Bitcoin Cash Roadmap

[Christopher R. Halbersma]

Anthony, 

Step 3: Medium-term simple consensus changes – next hard fork ~Nov
> 2017
> 
>    - Simple malleability fix (similar to BIP-140 “normalized TXID”)

Would it make sense to skip BIP-140 and go straight to FlexTrans?

CRH

On Tue, 2017-08-08 at 09:06 -0700, Antony Zegers via bitcoin-ml wrote:
> I am posting this here for discussion. Hopefully this can serve as a
> preliminary framework to help the Bitcoin Cash implementations
> coordinate with each other. It is not intended to be definitive, or
> comprehensive. I’m sure there are things I have missed, and people
> will have different priorities and ideas.
> 
> The first priority is to work on maintaining the reliability and
> stability of the Bitcoin Cash network. There is lots to do here, and
> much work already in progress. It is also important to work on
> improvements to make Bitcoin Cash easier for users, to lower
> confusion, and help them avoid pitfalls.
> 
> Although less immediately urgent, it is also good to have a sense for
> what the next steps are envisioned, and have time to coordinate
> details of the vision between the different projects. This will
> hopefully help Bitcoin Cash continue on a path of rapid technological
> progress and innovation.
> 
> Proposed Roadmap:
> 
> Step 1: Implement non-consensus changes to help make Bitcoin Cash
> network reliable, stable, and separate from Bitcoin network
> 
>    - NODE_CASH service bit
>    - New network magic
> 
> Step 2: Improvements to make Bitcoin Cash easier for users, and lower
> confusion
> 
> Wallets:
>    - New derivation path for HD wallets (load balances for pre-split
> outputs from Bitcoin derivation path, but generate from new path for
> receiving and change addresses)
>    - URI prefix: change “bitcoin:” to “xbc:”, “bitcoincash:”, or
> similar
>    - New address version (and eventually move to new format like
> bech32/BIP-173)
> 
> Client-specific changes:
>    - Change install and data directories
>    - Change names of binaries
> 
> Step 3: Medium-term simple consensus changes – next hard fork ~Nov
> 2017
> 
>    - Simple malleability fix (similar to BIP-140 “normalized TXID”)
>    - Remove transaction size limit
>    - Remove OP_RETURN anti-replay rule
>    - Increase block size limit - 8x again? (64MB)
> 
> Hard fork decisions:
> 1. What changes should be included in the next hard fork?
> 2. When should the next hard fork be planned? (1 Nov? later?)
> 3. How should it be coordinated? Flag day again like UAHF? Some other
> coordination mechanism?
> 4. Would it be better to combine several changes in a hard fork
> event, or aim for a series of smaller (more frequent / regularly
> occurring) hard forks?
> 
> Step 4: Longer-term improvements on the radar
> 
> Non-consensus-changes:
>    - XThin/Compact Blocks - can they be made interoperable?
>    - Other block relay improvements (Expedited / Compact Block “high-
> bandwidth” mode)
>    - Weak blocks / sub-chains
> 
> Consensus-changes:
>    - Schnorr signatures (hard fork ~Feb 2018)
>    - Smoother and more resilient difficulty adjustment (eg.
> DarkGravityWave or digishield)
>         Advantages: increases hash-rate stability to co-exist with
> Bitcoin while sharing the same POW. Tighter feedback between market
> prices and hash rate. Facilitates future chain splits.
>         Disadvantages: Possibly contentious. Difficult to coordinate.
>     - Improved method for making changes to consensus rules
> 
> 
> Antony
> (aka Mengerian)
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20170808/ed7d4c52/attachment.sig>