@JonathanSilverblood 8 January 2021 edited

Can we get native transaction introspection on Bitcoin Cash?

In the November 2018 upgrade of Bitcoin Cash, a new feature was added that allows developers to verify external signatures provided to a transaction. This in turn opened up the doors to do what is called transaction introspection, where a transaction on the network can enforce spending rules based on the transaction information itself, such as who the recipient can be and how much it can spend. Unfortunately, due to various restrictions this support can only verify some of the transaction data, has a significant operational cost and requires a deep understanding of how the Bitcoin Cash transaction signature model works. A better way Instead of making developers go through a re-verification trick in order to obtain limited information about a transaction it is possible to add a new feature to the protocol that gives developers direct, safe and easy to understand access to relevant contract data. https://read.cash/@pein/bch-covenants-with-spedn-c1170a02 By adding **native** introspection to the protocol, we would reduce implementation risk, reduce transaction complexity and empower developers to build new usecases. Before adding new features to Bitcoin Cash, it is important to properly evaluate what the impact of such features will be and make sure that relevant stakeholders are aware of and have the opportunity to take part in the development process. That said, every proposal has to start somewhere, and currently we have set up a working group consisting mainly of node and library developers and are in the process of evaluating the technical feasability and what impact different implementation options might have for the Bitcoin Cash network. Cost, Benefit and Demand Evaluation As a step in the process to build consensus and get a proposal implemented I have written up an assessment of the idea, it's impact on the network and who the stakeholders are. This should be seen as an initial draft and I invite interested parties to reach out to me to talk about their views and needs when it comes to transaction introspection so we can make better decisions, together. Initial cost to the network Native introspection will use up some of the currently available opcodes. Depending on implementation detail, this cost might be small (single opcode, templated data) or it might be significant (every transaction data can be accessed through a unique relevantopcode). Since this would be a consensus change, all node software that validate consensus would need to implement the feature. A limited number of libraries and developer tools that offer advanced scripting functionality would need to implement the feature. Wallets, mining pools, exchanges and services does not have to be updated and will continue to function as normal. Ongoing cost to the network Adding native introspection could increase complexity for any future technical changes to the Bitcoin Cash transaction format. Benefit to the network Reduces barriers to entry for new developers that want to build smart contracts using transaction introspection. Improves contract safety by eliminating implementation risks that comes with the complexity of the current re-verification trick used as a workaround. Allows for new usecases to be developed as native introspection can provide more information on a transaction than the current re-verification trick. Allows for larger and more complex smart contracts to be developed as native introspection takes up less scripting space compared with current re-verification trick. For transactions that uses introspection, the transaction size can be reduced which lowers the cost on the network in terms of bandwidth and long-term storage. For transactions that uses introspection, the network processing cost would be reduced since there is no longer any need to do an additional signature verification. Existing demand in the network General Protocols made AnyHedge, a volatility risk-trading contract. bitjson created CashChannels, reccuring payments for Bitcoin Cash. https://gist.github.com/bitjson https://blog.bitjson.com/cashchannels-recurring-payments-for-bitcoin-cash-3b274fbfa6e2 haryu703 created Hamingja, a loyalty points system using non-tradable SLP token. https://github.com/haryu703 https://github.com/SLPVH/hamingja Licho have created a Last Will contract to manage inheritence. https://github.com/KarolTrzeszczkowski https://github.com/KarolTrzeszczkowski/Electron-Cash-Last-Will-Plugin Licho also created Mecenas, a smart contract for recurring payments. https://github.com/KarolTrzeszczkowski https://github.com/KarolTrzeszczkowski/Mecenas-recurring-payment-EC-plugin Tobias Ruck created be.cash, a refillable, offline wallet in the form of a credit card. Casues Cash built an modified Mecenas to support recurring payments in USD. https://gitlab.com/bchplease/causes.cash/-/tree/master/contracts p0oker created an SLP Vending contract that mints tokens on-demand. https://twitter.com/p0oker https://github.com/p0o/yield-farming-bch-smart-contract Mistcoin has produced minable SLP tokens. https://mistcoin.org/ Future demand in the network Flipstarter was researching funding contracts as a way to improve usability, which may be possible with better introspection. General Protocols are looking to build more non-custodial services and can enable more usecases with better introspection. haryu703 is working on an SLP swap/trading contract. https://github.com/haryu703 Licho is considering to implement traditional games, like NIM. https://github.com/KarolTrzeszczkowski https://en.m.wikipedia.org/wiki/Nim Tobias Ruck is looking into a non-custodial on-chain gambling product. James Cramer is experimenting with SLP Mint Guard, to protect minting batons. https://twitter.com/James_Cramer https://github.com/simpleledger/Electron-Cash-SLP/blob/cashscript-dev/lib/cashscript/slp_mint_guard.cash James Cramer is experimenting with SLP Vault, to help reclaim unclaimed tokens. https://twitter.com/James_Cramer https://github.com/simpleledger/Electron-Cash-SLP/blob/cashscript-dev/lib/cashscript/slp_vault.cash James Cramer is experimenting with making tokens with minting schedules. https://twitter.com/James_Cramer https://github.com/simpleledgerinc/slp-mint-contracts James Cramer is experimenting with SLP Dollars, tokens freezable by the issuer. https://twitter.com/James_Cramer https://github.com/simpleledgerinc/cashscript/blob/master/examples/slp_dollar.cash p0oker is building a BCH staking contract that mints tokens over time. https://twitter.com/p0oker p0oker is also building an SLP exchange contract to sell NFTs. https://twitter.com/p0oker Current opposition from the network There is currently no known opposition to native introspection. Costs for delay / stagnation Continued use of the inefficient re-verification trick makes the blockchain larger than it needs to be and could have a negative impact on initial block download times and storage requirements. Requirement to use a difficult technical workaround in order to achieve transaction introspection could result in loss of opportunity as development costs and barrier to entry remains high. Complexity of the technical workaround in order to achieve transaction introspection could result in otherwise successful businesses having technical problems with their implementation that results in loss of profits and damages reputation of both the company and Bitcoin Cash as a network. Some applications and usecases are not possible with the re-verification trick but depending on technical implementation details may be possible with native introspection, not serving these usecases on BCH might result in competitors building these products and gaining theses users instead. Where do we go from here? The next step from here is to write a formal draft proposal and engage with a broader set of stakeholders. If you have a need or interest in native introspection, or have a strong opinion on why native introspection should be rejected, you're welcome to join us and make your voice heard on our Telegram group. https://t.me/transactionintrospection