Hi Ryan. I notice you started your video response to my last article with flattery and compliments. Well, if you think you can butter me up and I’ll go easy on you, then you’re in for a surprise!

Just kidding, I appreciate the kind words. The sentiment is mutual.

I will go through the four main points you made in a comment below my last article, and some of the stuff you said in the video. I hope this will help to clarify things. There are many parts of what you say that I agree with. But there are some things that I disagree with that affect the way everything fits together.

Overall, I am still of the opinion the OP_CHECKDATASIG (CDS) is not a subsidy, and does not present a problem for the economics of the system.

I'll go through your four major points one at a time:

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.

Sure I agree it seems possible to do this. It does seem conceptually “cool” that many things can be implemented in Script.

To my knowledge, no-one has written an actual code sample doing ECDSA in Script though, and it might be quite difficult to implement. In your article about implementing it in Script, you sort of hand-wave away the details (“One can now do a thought experiment on how to fully implement ECDSA in Script”). Things like unrolled loops-within-loops are very cumbersome, and it seems that implementing complex functions in Script is quite unwieldy.

It could turn out to be difficult and bug-prone to implement ECDSA in Script. The current ECDSA implementation in node and wallet software, used in OP_CHECKSIG and OP_CHECKDATASIG has undergone years of optimization and debugging, and it’s security and attack vectors are well understood and are handled in a known way .

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).

Yeah, I also agree with that part. I thought this was part of the shared background information that everyone agrees on.

It’s important to also note, however, that the computation needed for OP_CHECKDATASIG implemented in Script would be dramatically higher again than the native implementation (as you noted, optimized in Libsecp256k1). This means that we know for sure that there is a downside to implementing ECDSA in Script.

It’s also not clear that pricing Scripts by length is a good proxy for their actual computational cost. There is a good description of some of the difficulties in this reddit thread .

The computational costs of OP_CHECKDATASIG, on the other hand, are well understood and predictable. Because it’s the same computation as OP_CHECKSIG, this is an operation that people are familiar with. This should make it fairly straightforward for miners and validators to calculate their costs, and what they would want to charge for payment, if the cost ever becomes significant for them.

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).

This is where you lose me. Who said it lowers the cost? Why does it have to be given away for free? There’s no rule that Scripts have to priced my length. Sure, it’s just 1-byte of opcode, but that doesn’t prevent miners and other services from charging more for it than other opcodes. In fact, it is already treated differently: uses of CDS are count towards the “SigOps” count (same as OP_CHECKSIG) which is limited in blocks (Another one you can add to your list ).

You did a nice video about “ Bitcoin at Scale ” where you talk about this concept. You detail how, in the future, providers of different services could charge for them, and compete on the market. For example, archival nodes could charge for serving up historical records of the block chain. Why not apply the same reasoning to OP_CHECKDATASIG, and let the providers of Script computation services decide what they should charge for it?

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").

Much of your argument here seems to revolve around the concern that non-money uses could crowd out money uses. This is the same argument people made about allowing OP_RETURN data to be embedded in transactions. I wrote an article about why this is not something we need to worry about. Basically the overall point is that we should trust the free market to allocate resources effectively. If people are willing to pay for something, then it has value. And if something becomes burdensome to provide, providers can figure out a way to be compensated for providing it. I thought you agreed with this approach, I seem to recall at the time you liked the article.

Note: I have noticed you changed your phrasing around whether CDS is “used for money”, to now say that, while CHECKSIG is a “requirement” for sending money, CHECKDATASIG is not. I agree that this is technically true. But you could say the same thing about all of Script in general. If we only wanted things “required” for money to function, we could remove Script entirely and restrict all transactions to the P2PKH template. The fact that we have Script implies that it’s valuable to be able to attach more elaborate spending conditions to the money.

Tying it all together

If OP_CHECKDATASIG were just some random complicated instruction, then I think your criticisms would have more validity. In general, I don’t think it’s a good design to make complicated instructions in a scripting language that are overly specific to one use. This is why I was not supportive of the “Group” proposal, for example.

OP_CHECKDATASIG has two major things going for it though, that make it different from some random arbitrary complicated instruction:

An ECDSA signature check fits into the category a basic building block, not overly tailored to one particular use-case. It’s the kind of thing that can be used and combined in many ways. This makes it suitable as an instruction in a scripting language. It’s exactly the same internally as what is implemented in OP_CHECKSIG. This means that the costs and risks are well understood. It also means that the code machinery is necessarily already present in every node and wallet. All OP_CHECKDATASIG does is give more flexible access to this machinery.

While I agree with focusing design effort on optimizing the money properties of Bitcoin Cash, we shouldn’t fear that idea the “non-money” use cases will crowd out use as money. Just like Memo.cash, Simple Ledger Protocol, and other non-money uses, they should all be allowed if they are provided by a free market of miners, validators, etc.

We can’t predict the future economic structure, nor should we try to. Making a simple, efficient tool like OP_CHECKDATASIG is simply adding to the capabilities of Bitcoin Cash that will help make it even greater than it already is.