[Bitcoin-ml] Bitcoin Cash Roadmap

[Tom Zander]

I have little to no problems re-enabling some more  innocent script 
functions if there is a good usecase.

Your propsal blog is not providing any usecases, though.
It also suggests a new opcode that is insanely expensive to implement 
because it uses pubkeyhash. Which is neither indexed, nor unique.

Needs more work.

On Tuesday, 8 August 2017 23:40:34 CEST G. Andrew Stone via bitcoin-ml 
wrote:
> 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


-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel