[Bitcoin-ml] Bitcoin Cash Roadmap

Сергей Кучмаренко kuchmarenkoss at mail.ru
Tue Aug 8 16:46:18 UTC 2017


Hello
Can anyone help buy L3 + 5pieces and c9-1pieces of 15-20 August
I will be very grateful


>Вторник,  8 августа 2017, 19:12 +03:00 от Antony Zegers via bitcoin-ml <bitcoin-ml at lists.linuxfoundation.org>:
>
>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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20170808/f76c771e/attachment.html>


More information about the bitcoin-ml mailing list