[Bitcoin-ml] Bitcoin Cash Roadmap

[G. Andrew Stone]

I would like to see some script opcodes re-enabled and a few additions to
enable functionality that does not exist in Bitcoin today that could drive
a lot of use onto BCC.

As an example, this article explains how we could have binary options with
an opcode that checks the signature of data on the stack rather than the
transaction:
https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-decision-based-spending-8e7b93d7bdb9

Since the signature checking code is already written for checking
transactions, this would be very easy to add.



On Tue, Aug 8, 2017 at 12:06 PM, Antony Zegers via bitcoin-ml <
bitcoin-ml at lists.linuxfoundation.org> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20170808/08da513d/attachment.html>