Without going into any history or context, what are the practical implications of solving the problem you’re trying to solve?
Bitcoin Cash already has a very powerful programming language – by solving an issue with how transactions are formatted, we'll be able to build advanced, Decentralized Finance (DeFi) applications which scale better than those on "global state" networks like Ethereum.
What use-cases would be enabled, and why should they be accommodated?
PMv3 would allow BCH developers to build almost any kind of decentralized application currently possible on other "smart contract"-focused cryptocurrency networks, including prediction markets, synthetic assets, and decentralized exchanges.
What groups or stakeholders benefit from fixing the problem/implementing the feature/etc? Who from those groups openly supports your specific initiative?
Businesses and developers will be able to quickly innovate using BCH's existing contract language, without waiting for permission or network upgrades. Most of these efforts would likely be new companies or decentralized, autonomous organizations.
PMv3 doesn't have any public commitments yet, but General Protocols, Software Verde, Richard Brady, and Tom Zander have provided valuable review and feedback.
There may be many ways to go about trying to fix a problem, or enable a use case. What differentiates a good solution from a bad one? How should a solution/implementation be measured?
Other than PMv3, more advanced contracts could be enabled by:
- extending the existing virtual machine to support global state (like Ethereum),
- adding an entirely new virtual machine system,
- or finding new ways to use the existing virtual machine and consensus rules
A good solution should minimize changes to the system, and it should particularly avoid implementing new or untested systems. For example, a totally new virtual machine system should probably be researched and reviewed for several years before deployment. Likewise, a major extension which expands the scope of the existing VM should also have several years of research and review.
A great solution should utilize as much of the existing infrastructure as possible, minimizing total implementation cost and avoiding technical debt.
This might be an appropriate place to talk about the context of the problem, and/or current implementation. But make sure to keep it to the point! We don’t need a history lesson, just enough to know why you’ve decided on the criteria you’re presenting.
SmartBCH – is a BCH sidechain which runs decentralized applications designed for Ethereum. SmartBCH alone requires a trusted peg between the sidechain and the BCH mainchain, but with PMv3, the SmartBCH peg can be designed to rely on a more secure BCH contract.
Solidity, Mitra – these are existing proposals for novel virtual machines that would be deployed in addition to the existing VM. Solidity has ~5 years of development now, but is still unlikely to be ready for production in the next 2 years.
GROUP Tokens – this is a proposal to add a new, hard-coded token system into BCH consensus rules. Depending on the precise implementation, this could enable some advanced contracts, but would still require some solution like PMv3 for cross-contract interfaces.
Parent Inspection Opcodes – parent inspection opcodes could allow contracts to "query" information about the transactions which pay into the current transaction. However, these opcodes would massively increase validation costs, as fast access to the data within most historical transactions would be required by all validating nodes. (Note: no proposal for this exists, this example is given to demonstrate a poor solution.)
Feel free to give a general overview of the implementation, but please only get as technical as is necessary to explain how it has the properties of a good solution/implementation you previously laid out. Make sure to cover each of the criteria laid out in section 2, referring back to each one as it’s covered!
PMv3 is a solution which allows us to use the existing virtual machine in a new way. Right now, BCH contracts are limited to two types of validation:
- current transaction – the contract can validating details about the current transaction (e.g. require a particular
locktime) - future transactions – the contract can validated details about future transactions (e.g. require payment back to the same contract)
The existing transaction format inadvertently prevents one final direction of validation: past transactions. Because every transaction must include it's proof information, transactions with contracts which attempt to inspect their parent transaction can become very large. PMv3 solves this issue by allowing transactions to "compress" that history into a hash.
PMv3 has the characteristics of a great solution described above: it does not rely on any new virtual machine or extension, but instead allows the existing VM infrastructure to be used for advanced decentralized applications.
By otherwise following the existing v1/v2 transaction format, PMv3 also makes implementation as simple as possible for consensus-validating software, minimizing implementation cost and technical debt.
What products would need to be updated, then reviewed, tested, etc to implement your proposal?
All fully-validating node software, all chain indexing software, and most SPV wallets.
How serious are the consequences of not updating?
Fully-validating nodes which do not update might begin to follow a non-upgraded chain.
Users and businesses of consensus-validating software who do not update will experience errors in user interfaces or may begin to follow a non-upgraded chain.
End-wallet users of BitPay, Bitcoin.com wallet, Edge, Blockchain.com Wallet, Jaxx Liberty, Exodus, Trezor (and other Blockbook-based wallets), and Ledger will not need to update their wallets. (These wallets may implement PMv3-based features in the future which users will need to upgrade to access, but existing applications will continue to work if backend node infrastructure is upgraded.)
What secondary costs can you imagine, and how might you mitigate them?
- Will employees need to be retrained?
No – users shouldn't see a change in wallets or application interfaces.
- Will anything need to change for end-users?
No – there has been discussion of a v3 CashAddress format, but a thorough review of the wallet ecosystem indicated that would not measurably improve user experiences. As such, most users will not need to update their wallets, and no user experience changes are expected.
- What is the likelihood for contention over the change?
Given the following scale:
Low– changes only affecting full-validating nodes, other software can ignore upgrade (e.g. new opcode activation)Moderate– changes affecting most consensus-validating software (e.g. difficulty adjustment algorithm change)High- changes affect most client-side software (e.g. 2017 BCH sighash upgrade)
PMv3 is a Moderate change – the change requires updates to all consensus-validating software, rather than the smaller subset of only fully-validating nodes. This requires more ecosystem coordination to update affected software, but does not require updates to most end-user wallet clients or offline signing software.
(Consider providing a short cost/benefit analysis. Why do you think the benefits are worth the costs and risks?)
While this kind of upgrade is more disruptive than a change affecting only fully-validating nodes, it also offers significant, user-facing benefits. By allowing BCH to participate in Decentralized Finance (DeFi) development, existing holders, users, and businesses can expect PMv3 to make BCH much more attractive as a currency and platform for commerce.
- Suggested Stakeholders
Who do you think benefits from the implementation of the discussion item on the Bitcoin Cash network?
Decentralized application and sidechain developers have will have the opportunity to build their systems directly on BCH. Holders, businesses, and all users of BCH can expect growth in the network as more decentralized application development migrates to BCH.
Which of those stakeholders openly support your proposal?
No public commitments yet.