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.


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.


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.
  1. CDS is implemented in a 1-million instruction long Script (with unrolled loops, etc.), costing around $5 to get mined.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.


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
  1. Cold Wallet Timeout (OP_CHECKSIGFROMSTACK): https://bitcoinops.org/en/newsletters/2018/10/09/
  2. 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:
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:
That answers my question exactly. Thanks!


3 of 3 reviewers say it's worth paying for

0 of 3 reviewers say it's not worth paying for
  spent 20.0¢
Hi. I have a few questions.

Isn't it a subsidy to make something cheaper when it actually costs the same?
Does DSV make things cheaper for miners? I don't mean in network costs (I understand that it does make that cheaper), but the computation itself. Is it 1 million times cheaper than running the full 1-million instruction Script sequence? Unless it does, I prefer your thought experiment scenario OP_CHECKDATASIG in Script.
   2yr ago
  earned 55.0¢
Good article.
I entirely agree with the point that the money function is not different from CHECKSIG VS CHECKDATASIG.
If the argument is "CHECKSIG is used more than anything else for P2P Cash", then I would point to the common methods of multisig, escrow, and smart contract (for example ChainBet).
There's nothing very special about CDS in this context because its just another signature to check. It would be no more costly than an additional multisig signature being required, yet opens up more use cases.
   2yr ago
25.0¢ 20.0¢ 25.0¢ 25.0¢
  spent 20.0¢
Thank you for compiling the list of use cases. That by itself is valuable.
Serious Questions and observations...
1) You never addressed the Ryan's key issue: When code loops you cannot predetermine how expensive it is to execute. Deterministic cost based on length is compatible with the economics of bitcoin. What to charge for script that is unknowably expensive to execute?
2) As a miner, by what mechanism can I charge users based on how expensive it was to execute the script? I can only know this after the script has run. I would like to know your proposal for how to charge for using this opcode.
   2yr ago
  earned 0.0¢
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.
Yes, of course. This is why we first revive some basic operations like multiplication and big number support. With this in place doing OP_CHECKDATASIG in Script becomes trivial. 100 bytes maybe.
   2yr ago
10.0¢ 20.0¢ 10.0¢
  earned 5.0¢
I'm still not convinced money should be running these scripts at all.
   2yr ago
20.0¢ 25.0¢
  spent 20.0¢
The best rebuttal I've read in a long time. 👏
   2yr ago
  spent 10.0¢
First of all, thank you for your write up. You make a solid case.
I believe this was exactly Ryan's intention; to point out that there are reasons to debate this before blindly going forward, and with that I agree wholeheartedly. We should be mindful of the unintended consequences and potential for change to the economics.
If OP_CHECKDATASIG becomes widely used, it will increase the cost of mining, and this will ultimately be passed on to users. It could be passed only to those users of that op_code, but this will create a more complex fee environment. OR, it could be passed on to all users in aggregate. There's a valid concern here with the economics.
What if there's another operation that someone comes up with that uses a million times more computation than OP_CHECKDATASIG? There is an undeniable tension between creation of useful functions and the externalized computational overhead they impart.
Perhaps this is inevitable -- in which case we need to be thinking hard about completely overhauling the Bitcoin fee paradigm to be something more similar to Ethereum where fee scales with computation.
   2yr ago
10.0¢ 20.0¢
  earned $3.40
Thank you for your thorough and detailed response.

The definition of "subsidy"

Dictionary.com offers the third definition of subsidy as "a grant or contribution of money". By making this complicated and CPU-intensive operation the same cost as OP_AND, the network is saving people who use CDS somewhere in the ballpark of 1 million satoshis. That is a subsidy.
> The fact the a subsidy is non-voluntary is very important. This is what causes it to be harmful.
It is true that government-sponsored subsidies are fundamentally different than free market subsidies because of the use of coercion. However, things that are voluntary can still be a net loss. Since we do not know what the economic consequences of CDS are, there is a chance (like most subsidies) to have unintended negative consequences that outweigh the benefits.
> But in this case, the change is of net benefit to society, and results in greater prosperity overall.
Where is your evidence for this key claim? Indeed, it makes all the difference whether CDS is actually a net win. You do not offer any evidence for this and nor has anyone else. The negative consequences have not been worked through.

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!
You seem to have missed a key part of my argument. CDS actually does cost more because it is far more expensive in terms of CPU usage than any of the operations (except CHECKSIG). The cost per byte of the script tells us what the protocol would charge without this opcode in place.
The script cost tells us what the miners charge. The quantity of CPU cycles tells us the cost of computation. CDS reduces the fees paid to miners while not simultaneously lowering the CPU cost. An expensive operation is now almost free while still coming at a cost to the miners. Hence it is a subsidy.
> The idea that we need to “understand the economic implications” before making improvements is a form of central planning.
But a group of devs deciding add this opcode without understanding the economic implications is somehow not central planning? Sounds like doublespeak to me. The idea that it is somehow better to not understand the implications while still being instituted by a tiny minority if people is ridiculous.

The CHECKSIG comparison

CHECKSIG is critical for the sending of money and Bitcoin would not function without it. CDS is not critical and Bitcoin works without it. They are not comparable. It makes sense to subsidize CHECKSIG. It does not make sense (given presently available evidence) to subsidize CDS.

The Big Picture

No one has yet refuted my central claims.
  1. It is possible to implement CDS in Script and if done so the rate of fees paid to miners is many orders of magnitude higher than the fees paid for a single opcode like CDS.
  2. The actual CPU cost of CDS is dramatically higher than every other opcode besides CHECKSIG because ECDSA signature verification requires orders of magnitude more CPU cycles (and CHECKSIG is an exception because it is critical to the sending of money).
  3. Because CDS changes the rules in such a way as to dramatically lower the cost irrespective of the CPU cost relative to other opcodes, it is a subsidy. Something that is naturally expensive (as expressed in the current protocol and also as measured by CPU cycles) will be given away nearly for free with CDS (while still being expensive in terms of CPU cycles).
  4. The consequences of this are that other use-cases that require long scripts, and even the very sending of money itself (because by subsidizing CDS, miners now have fewer CPU cycles left over for CHECKSIG), are now more expensive. We do not know what use-cases those are or who is harmed (exactly like the book "Economics in One Lesson").
It is possible that CDS is a net win. No one has actually demonstrated that. I doubt that CDS is a win for the same reason I doubt most subsidies are win when no one bothers to think through the complete set of consequences. It is likely that when someone thinks it through, or when we see it used in reality, that we discover the unintended negative consequences and that we regret them.
   2yr ago
25.0¢ 50.0¢ 20.0¢ 25.0¢ 25.0¢ 25.0¢ 25.0¢ 25.0¢ 25.0¢ 25.0¢ 25.0¢ 25.0¢ 50.0¢ 10.0¢
  spent 10.0¢
RXC apparently believes in things being "naturally" expensive, as if the cost of given operation is some divine decree casted upon him by the gods surrounded by singing angels. In 2018, we have someone who believe more efficient things are subsidies, and arbitrarily cumbersome contraptions dreamed up in his head is "natural". You can't make this shit up.
   2yr ago
20.0¢ 10.0¢
  spent 20.0¢
hi Ryan, Your argument has its own inner logic, but that doesn't mean it makes good sense overall. The fact that we could create a version of CDS that's a million times less efficient to me only means that's there's really no good way to do it without actually adding the op code. The question then becomes "do we actually want to add it?" While it is true that signature validation may be an expensive operation, we do signature validation all the time; this is just a slight variation on it, so its quite a minor change. You could say that me calling it a "slight variation" is a spin in favor of adding it, and I could say that calling it a "subsidy" is a spin against adding it. In reality, its checking a signature against data rather than the transaction. In both cases its for the money function. It's true that CHECKSIG is more fundamental; but that doesn't mean CHECKDATASIG is radical. It could come down to philosophy "don't change bitcoin" vs. "lets improve it to help adoption". I personally feel the change can help more than the costs of adding it. This is something that is hard to measure, and it is not realistic to tell people to add it "manually" and "see how it goes". Finally, I think the personal appeal to Roger and the timing of it just ahead of the fork have political overtones. We can speculate your motivations for the concern. They seem clear to me though. Whether that is good or bad depends on one's position.
   2yr ago
  spent 20.0¢
Yes, I was also questioning the idea of it being a definitive "subsidy". Thanks for the article!
   2yr ago