Hello Ryan! In your Youtube video “ Dear Roger: Why DSV is a Million-Fold Subsidy ”, and accompanying article , you argue that OP_CHECKDATASIG is bad because it’s a “subsidy” that “alters the economics of Bitcoin”. In this article I will go through some of your arguments, and try to explain why I see things differently.

Subsidies

A subsidy is when some good or service is artificially supported by directing resources to it. The reason subsidies are bad is that they use force to direct the resources to the favored area. This means that the economic structure will be different than it would be if freely decided by individual choice, creating a net loss of value to the system.

The fact the a subsidy is non-voluntary is very important. This is what causes it to be harmful.

There are other things that can cause changes to economic structures, such as technological improvements. The introduction of farm machinery, for example, will change how resources are allocated in the economy, resulting in fewer people working as farmers and more as mechanics. This “changes the economics” of the system. But in this case, the change is of net benefit to society, and results in greater prosperity overall.

So the fact that a thing can cause something to be less expensive does not automatically make it a subsidy. Technological improvements also make things less expensive, and are of great benefit to society. OP_CHECKDATASIG (CDS) fits into this category. It is non-coercive, it a simply a technical improvement. This means that if it causes changes in resource allocation, we can expect those changes to be of net benefit.

Economic in one Lesson

As you point out in the video “ Bitcoin at Scale ”, as Bitcoin Cash grows and scales massively, we can expect the economic structure to evolve. Different actors may charge money for some services that are now free, and other things may become more efficient and easier to provide inexpensively. This is a good thing. We can’t predict exactly how the future network will be structured, but we can trust that if resources are allocated economically, they will be allocated in a sustainable way that matches people’s wants with the costs of providing for them.

You mention Hazlitt’s book “Economics in one Lesson”. The central message of the book was to consider the “unseen” effects of things as well as the “seen”. This means that we shouldn’t try to centrally plan things according to a preconceived notion of what is important. The argument that CDS “should” cost more falls exactly into this trap! The same goes for the argument that Scripts “should” be priced only according to their length. This would be an attempt to design the system based in our prediction of how different actors will choose to price their services in the future. Better to let these decisions be provided by the free market.

Providing a technical tool that people can choose to use, and producers can choose to supply, is a good thing. The idea that we need to “understand the economic implications” before making improvements is a form of central planning. It would be akin to wanting to prevent the mechanization of farming without conducting a study about the impact on the job market for farmers.

Maybe an efficient OP_CHECKDATASIG will be used more than a 1-million instruction long Script version would have been. But this would be a good thing, it would show that it is providing utility to the system.

The Money Function

A few times you state that a subsidy is justified for OP_CHECKSIG because “CHECKSIG is for money and DSV is not”. I don’t think this distinction is accurate.

Both OP_CHECKSIG and OP_CHECKDATASIG simply create conditions deciding when money can be sent. OP_CHECKSIG checks that a signature has been supplied matching a public key and signing some transaction data. OP_CHECKDATASIG checks that a signature has been supplied matching a public key and signing some other supplied data. In both cases they just define when money can be sent.

For a good opcode design, we don’t want to create a system that assumes exactly how it will be used in the future. It’s better to create a flexible scripting language and let the users and application developers find novel unanticipated uses. I have begun compiling a short list of uses of CDS that I have noticed people working on (See Appendix A below). It seems that the evidence is that people are using it in novel ways. This is a good sign that the opcode is a generally useful instruction. You will also notice that all of the uses involve using Bitcoin Cash as money.

OP_CHECKDATASIG in Script

The approach you advocate is to implement OP_CHECKDATASIG in Script first, to assess its economic effects. Let’s do a thought experiment to imagine how this could play out.

CDS is implemented in a 1-million instruction long Script (with unrolled loops, etc.), costing around $5 to get mined. This functionality becomes popular. Application and wallet developers notice that the 1MB Script is repeated in many transactions. They develop a standardized template to make it easy to work with. The Script-CDS becomes a common pattern that is repeated exactly in many transactions. Miners notice that exactly the same Script byte sequence is repeated in many transactions. To improve transaction network propagation, they realize they can compact this standard pattern using a 1-byte code. Using this networking compression, the transactions can be communicated compactly on the network. Nodes and wallets receiving this 1-byte code know to replace it with the full 1-million instruction Script sequence when they receive transactions. Node implementers realize that they can save disk space by using the same 1-byte network encoding that represents Script-CDS. When the software finds this encoding when reading from disc, it knows to replace it with the 1-million instruction long Script-CDS. Wallet implementers notice that this popular 1-million instruction Script is exactly equivalent to the ECDSA signature check in OP_CHECKSIG which they already have implemented efficiently in every wallet. They realize that they can make the wallets run far better by substituting in their native ECDSA implementation when they detect the standard Script CDS pattern, rather than running the long Script through the interpreter. Everyone substitutes 1-byte encoding for the 1-million instruction Script CDS. Services such as miners, validators, and archival nodes price their services to give discounts for Script-CDS, compared to other long non-template Scripts. Through competition of services, the price of Script-CDS drops to be the same as the 1-byte OP_CHECKSIG opcode.

Conclusion

Engineering the prices within the Bitcoin Cash system to fit a pre-defined structure, deciding which should be expensive and which cheap, is a form of central planning. When you talk about doing a “ proper economic analysis on DSV of computing the benefits and costs to all parties ”, this is central planning! The lesson in “Economics in one Lesson” is that it is impossible compute the Unseen costs, we must let individuals choose for themselves, and let order emerge through price signals on the free market.

OP_CHECKDATASIG is not a subsidy. It is a technical improvement.

Appendix A - List of OP_CHECKDATASIG Use Cases:

This is a list of use-cases for Op_CHECKDATASIG that have emerged since it was created. It is non-exhaustive

Oracles: https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-decision-based-spending-8e7b93d7bdb9 Zero-Conf Forfeits: https://gist.github.com/awemany/619a5722d129dec25abf5de211d971bd Digital Good Purchase via PGP Signature: https://gist.github.com/markblundeberg/af59d7cd234cbdb14dcf9e00f0ea2c17 Pay to ID: https://gist.github.com/markblundeberg/bd28871548108fc66d958018b1bde085 Cold Wallet Timeout (OP_CHECKSIGFROMSTACK): https://bitcoinops.org/en/newsletters/2018/10/09/ Stablecoin: https://www.yours.org/content/futures-based--stable-coin--asset-solution-b784632e457f Enforced multi-sig signing order - Excerpt from chat from “[WG] OpCodes” Telegram Channel:

Jason Dreyzehner:

A bit of an abstract question: consider an unlocking/locking script combination where more than one signer is needed to create the unlocking script (like a multisig transaction). Is there any construction which requires that the signers sign in a particular order? I know e.g. that the order of signature pushes is important in OP_CHECKMULTISIG, but is it possible for a signature’s *construction* to depend on another signature?

(I think not, but I’m not quite sure yet.)

[8:51:06 PM]Antony Zegers:

I think you could do that with the new OP_CHECKDATASIG

You would just need to construct the script so that the same value was passed into OP_CHECKDATASIG as the message, and also passed into OP_CHECKSIG as the signature

…...

I came up with at Script as an example. If the scriptPubKey is:

OP_2 OP_PICK <pubKey2> OP_CHECKDATASIGVERIFY OP_DUP OP_HASH160 <pubKey1Hash> OP_EQUALVERIFY OP_CHECKSIG

Then the scriptSig to spend it has to be:

<sig1> <pubKey1> <sig2>

Where <sig2> is the signature of "<sig1>" as the message. This means it can't be created until after <sig1> has signed the transaction

[9:09:59 PM]Jason Dreyzehner: