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:
  1. 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.
  2. 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.
Embrace the free market Ryan!


5 of 5 reviewers say it's worth paying for

0 of 5 reviewers say it's not worth paying for
  earned 15.0¢
There is no provable demand for DSV, just conjecture that if you add it the use will happen. There is no analysis of the long term cost of the burden of it being added to the protocol, and the value it adds to make it worthwhile. The six month hard fork process allows devs to just keep throwing arbitrary things into the protocol, as long as all the other devs agree amongst themselves to accept it.
If devs were really serious about only adding things that were improvements there would be a checklist that features and changes had to pass, before things like this could even be considered being added. Instead, the devs gotta devs process seems to be standardised and locked in, and any question that their devving is unnecessary or requires analysis is tutted at.
Where is the analysis? Please stop devving in unproven technical debt.
   9mo ago
10.0¢ 20.0¢ 25.0¢
  spent 10.0¢
I just don't understand how anyone can think making something "EASIER" is a bad thing, as a NOOB in the Bitcoin Dev world - there is no way I could do a multi step script. I'm still struggling with simple steps like dealing with Bitcoin Built in limitations(I've been working on a mempool too long error for a week now and still feel I'm no closer to solving). I really don't care about the TECHNICAL details - how much more a miner will be inconvenienced etc. I want to know if an AVERAGE developer like myself will spend months vs days trying to create FUTURE incentives/onboarding options/etc. I know that I could currently do what I envision with DSV and being able to used op_return instead, but this is not a signed option and is VERY Public.
So from my point of view, if Ryan wishes to call it a subsidy, then GOOD, because if I'm not given "EASIER" to work with tools - I will not end up creating what I envision. To me, I need stuff like this, and to tell you the truth - there are not many Ryan X Charles, Mengarian's or even Craig Wright's who will EVER be able to pull off complicated Rabin Signature methods. BY NOT allowing new features onto Bitcoin you actually STIFLE innovation and make Bitcoin development much more costly.
So where do we have the trade off - the miner that makes "pretty good profit" eating the cost. Developer's that are struggling to even get work, NOW, but when the floodgates do open there wont be enough of us, and half of us will be "Half ASS" good enough. Or do the merchants/exchanges/ wallets/apps have to neglect features because they are to costly or do they have to fork out more money to buy off the few devs to make "their product" work. Finally if the company that can fork out the money to pay the FEW available devs- how many other companies will be excluded from having their apps developed in a timely manner because the devs are all in use??
EASY is the answer - there is NO EXCUSE not to make it easier if we can.
   9mo ago
20.0¢ 10.0¢
  spent 20.0¢
All we can do is explain how subsidies for things that are secondary to Bitcoin's main use case are dangerous, but we can't understand them for you.
At this point, the best we can do is wish you the best in figuring it out, so you're not upset when miners don't implement it.
   9mo ago
  earned 0.0¢
I cannot say this for sure, but the claim that DSV is a "subsidy" slightly reminds me of claims like "BCH is fiat" or "Lightning is P2P while BCH isn't". Things, that are somehow true, when you skew the definition. No clue about techincals behind this, but it sounds like someone telling me the sun is a "subsidy" and better to use candles instead. That of course has nothing to do with subsidies. I could be very well wrong on that one, because I only understand half of what Ryan is saying. But it seems far from assured, that the thing we are talking about is actually a subsidy. I hope this isn't being called a subsidy, just because it somehow is cheaper?
   9mo ago