Can we get native transaction introspection on Bitcoin Cash?

9 737
Avatar for JonathanSilverblood
3 years ago

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.

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

Future demand in the network

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.

$ 19.98
$ 5.88 from @TheRandomRewarder
$ 5.00 from @F.B.
$ 4.50 from @majamalu
+ 11
Avatar for JonathanSilverblood
3 years ago


The data has been analyzed in a very beautiful way.great article sir

$ 0.00
3 years ago

Wouldn't the increase in transaction validation time be an ongoing cost also?

$ 0.00
3 years ago

No, if anything that would be a cost-reduction since you wouldn't have to do the extra signature check.

$ 0.00
3 years ago

Do you mean making a new operationto refer to the transaction fields?

$ 0.00
3 years ago

Yes - the basic idea is to add new opcodes that push transaction information to the stack.

$ 0.00
3 years ago

I remember reading an actual draft technical spec for this somewhere some time ago.

$ 0.00
3 years ago

There has been two published draft specs, one by Jason and one by Tobias. They are mostly the same, with only some minor difference. Jason have since implemented his spec in libauth and found out that his assumptions was a bit off and is reworking it, and together we're going to draft up a new proposal and try to get Bitcoin Cash improved.

$ 0.01
3 years ago

Can you consider shifting discussion to a public forum like

$ 0.36
3 years ago

I don't fully understand the suggestion as I do not code. I do think this sounds great though! Thanks for pushing the envelope forward :-)

$ 0.00
3 years ago