Is there a room for OP_DATASIGVERIFY in Bitcoin 0.1? I'll argue that it is already there and in more powerful form than the one proposed by various developer teams. It's there but is more expensive. What do I mean by this?

Bitcoin 0.1

First I want to define what I mean by Bitcoin 0.1. It's Bitcoin as Satoshi designed it. Bitcoin with enabled opcodes. Bitcoin without artificially introduced "temporary" limits. Bitcoin without unneeded complexities which bloat base layer. It's incredibly powerful Bitcoin capable of doing the heavy lifting.

OP_DATASIGVERIFY implementation

Now, I'll try to sketch an implementation of OP_DATASIGVERIFY in Bitcoin script, without going into more in-depth details. Just want to show that everything needed for signature verification is already there and that we don't need to introduce another opcode to achieve this.
As I wrote earlier, in Bitcoin 0.1 we have all opcodes enabled, and we don't have artificial limits. No block size limit, no script size limit, no 'IsStandard()'... Another important thing is that opcodes there operate on big numbers. In it we have all the ingredients to construct OP_DATASIGVERIFY. We can build the kind of OP_DATASIGVERIFY that fits our needs by choosing a cryptographic algorithm, choosing parameters of the algorithm/curve...

Let's, for example, try to implement kind of OP_DATASIGVERIFY which verifies Elliptic Curve Digital Signature - the algorithm used when transacting coins in Bitcoin. Receipt for this implementation can be found on Wikipedia. I'll ignore the first part which checks the validity of the public key and concentrate on more juicier details of Elliptic Curve arithmetic.
The first step is to check the validity of signature by checking that r and s are within [1, n-1]. That's easy - use OP_WITHIN
Next two steps depend on our implementation. If it expects hash of a signed message on a stack, then we may continue with step 4. On the other hand, if we require the whole message, we use (or create) a hash function, for example, OP_SHA256 and OP_LEFT/OP_SPLIT (or OP_RSHIFT...) if needed after that.
The fourth step looks challenging. Multiplicative inverse in modular arithmetic needs to be calculated. To solve it we use "extended Euclidean algorithm", and pseudo code is on Wikipedia. Here we need arithmetic operations OP_DIV, OP_ADD, OP_SUB, OP_MUL, OP_LESSTHAN, OP_GREATERTHAN, and flow control opcodes like OP_IF. Yes, we need to loop. We can do it using an unrolled loop, that is we unroll the loop in a way to copy loop code X times where X is the max number of iterations. After (or before) each round we check loop condition to exit (jump to an end) if it is satisfied. Receipt for creating loops like this in the script can be found in Dr Craig Wright's text "Simple Loops.pdf".
Step 5 is modular multiplication. Opcodes for this operations are OP_MULTIPLY and OP_MOD, of course.
In step 6 we need to multiply elliptic curve point with a number and to do the addition of elliptic curve points. Sounds complicated? Let's use "double and add" algorithm for the multiplication. I'll not go into details of an algorithm, like didn't for "extended Euclidian algorithm" in step 4, just will use provided pseudo code.
Again, we need a loop, and we can unroll it as we did in step four, above. Max number of iterations is the max number of bits of a number that is multiplying the point (for Bitcoin's secp256k1 it is 256). 'di' in the algorithm from the above link/picture is the value of a bit at position i. We can get it by masking a bit at that position (OP_AND), and if the result is greater than 0 we add points Q and N, else we double point N. Bitcoin script doesn't know how to add/double elliptic curve points. But these can be done using just arithmetic operations (OP_SUB, OP_ADD, OP_MUL, OP_DIV) as we can see it on the same Wikipedia page.
And finally, OP_VERIFY in the last step.


My goal here was not to present complete and precise implementation of OP_DATASIGVERIFY, or to make a pseudo code for it, but to show that all ingredients are already in Bitcoin 0.1 and that Satoshi's opcodes are more than enough for achieving that functionality. Implementing it is not easy. People writing code in assembler know what I'm talking about. For this type of things, we need a higher level language which will compile to Bitcoin (script). This kind of script and transaction using it would be big, even thousands of bytes big, which implies much higher mining fee. If we introduce OP_DATASIGVERIFY as an opcode instead, that kind of transactions would be cheap as cash and would interfere essential property of Bitcoin as P2P cash.


10 of 10 reviewers say it's worth paying for

0 of 10 reviewers say it's not worth paying for
  earned 60.0¢
Nice, I was also thinking this would be possible. As you say though it could easily exceed the existing limits on script length (520 bytes max for P2SH) and on number of used opcodes.
(By the way the new ABC opcode is called OP_CHECKDATASIG -- you refer to it as OP_DATASIGVERIFY or OP_CHECKSIGVERIFY in a few places.)
   2yr ago
10.0¢ 25.0¢ 25.0¢
  earned 25.0¢
@markblundeberg You are right. OP_CHECKDATASIG is called by ABC. Some earlier developers (from BU) called it OP_DATASIGVERIFY.
There was an error in last paragraph where I called it OP_CHECKSIGVERIFY instead. Now I edited it.
   2yr ago
  earned 0.0¢
good for you, now let us develop our own ideas for how DSV and dont threaten to doublespend and reorg our BCH and were cool. dont like other peoples proposals? too fucking bad, BCH is permissionless. Compete on the open market through price mechanism instead of destroy other peoples projects becuase your own are inferior. Go fuck youself.
   2yr ago
  earned 0.0¢
Hey Rob, next time you speak, make sure you understand whats going on. This blog tells us we need limits removed in order for your little shitty project to work and retain value on 1 chain at no cost of degrading its security long term. This is why it needs to be locked.
   2yr ago