Lately, there’s been a lot of conversation directed at adding a canonical transaction ordering (CTOR) process to the Bitcoin Cash protocol. Then there’s the topic of whether or not the BCH developers should add the opcode OP_Checkdatasig (CDS) into the codebase. Some believe CDS will be beneficial to Bitcoin scripting applications and allow for all types of smart contracts and decision-based transactions. However, others think adding CDS is unnecessary, and may compromise network security.
OP_Checkdatasig: The Possibility of Oracles, and Cross-Chain Atomic Contracts
There’s a lot of discussion concerning the Bitcoin Cash (BCH) network hard fork coming this November. One of the topics is an implementation called OP_Checkdatasig (CDS) that’s been added to the Bitcoin ABC clients’ roadmap and codebase. Basically, CDS is an opcode that could theoretically enhance the BCH protocol’s scripting ability. When Satoshi created bitcoin, the software included a scripting system much like the programmable language Forth. In addition to the scripting, the codebase also included script words otherwise known as ‘opcodes.’ There are quite a few opcodes and all of them do various commands or binary functions but most of them were disabled long ago.
- OP_Checkdatasig is referred to as OP_Datasigverify in the same context throughout this article.
Some people believe that certain opcodes could add a ‘programmable money’ feature to the network. OP_Checkdatasig (also referred to as OP_Datasigverify or DSV) could possibly enable the creation of decentralized oracles that check the validation of certain signatures, and return two different outcomes in an autonomous fashion. Essentially the oracle determines a definitive outcome without the need for a third party or custodian’s decision. Oracles are the foundations of a smart contract because the software itself decides when and who to release the funds to based on the completion of meeting or not meeting certain requirements. When Bitcoin ABC announced version 0.18.0, included within the client is the addition of CDS and the development team’s announcement details the feature will be used for oracles and contracts.
“[Checkdatasig] will enable uses such as the use of oracles and cross-chain atomic contracts,” explains the Bitcoin ABC development team.
Pay To Identity
There are multiple posts people can read on the subject of CDS and the theoretical use cases. Mark Lundeberg has written a proposed use case of CDS called “Pay To Identity” which would allow the BCH protocol to determine the validity of a users identification.
“[Pay To Identity] is a mechanism where a Bitcoin Cash payment is made to a personally identifying string (real name, email address, social media handle, etc.) instead of directly to a cryptographic key,” Lundeberg details. “The payment can only be claimed by the recipient if they generate a public key and get it certified by a trusted identity verifier.”
This certification signature is confirmed in script via the new opcode OP_Checkdatasig.
Two posts authored by Bitcoin Unlimited’s lead developer Andrew Stone explain the possible use cases of CDS as well. Stone’s post,“Bitcoin Scripting Applications: Decision Based Spending,” gives a comprehensive look at how data and signatures can be verified in an autonomous manner.
Stone also determines “whether [common use cases] they are expressible in the Bitcoin scripting language and if they are not determined and propose the extensions are needed to support the use case.” In the enable binary contracts BUIP078 Stone gives a lot of color when describing what the opcode could do in the future as well.
“[The opcode] allows a script to validate the signature on arbitrary data using the same ECDSA algorithm (and code) used to validate the signature on Bitcoin transactions,” explains Stone’s BUIP078. “This opcode therefore enables the use of an external ‘oracle’, which is a very important too to enable external information to be imported into a transaction. Once the data is part of a transaction it is useful to be able to manipulate it to check various conditions on that data.”
Bitcoin Unlimiteds’ BUIP078 also states:
To enable the simplest form of programmable money we must have additional opcodes that either access data from prior blockchain transactions, or verify data and signatures pushed onto the script’s stack.
Can Rabid Signatures Work Without Introducing OP_Checkdatasig?
The blockchain firm Nchain and Craig Wright have been against adding concepts like OP_Datasigverify or CDS to the protocol and the opcode is not added to the Bitcoin SV client. Wright talked briefly about the opcode and oracles in a video with Reina Nakamoto on August 26. “There are so many problems with things like Datasigverify that people don’t think of — The first one is the entire concept is flawed,” Wright explains. “The idea is that you are going to have ‘permissionless oracles’ is what they try and sell.”
On Reina Nakamoto’s Youtube channel Wright further states:
The reality is there is no such things as a permissionless oracle. An oracle exists in the world so if its actually creating something signed in a special format for use in bitcoin gambling. That oracle is not un-permissioned.
Moreover, last week Nchain’s senior researcher, Owen Vaughan, published a post on a subject called Rabin signatures. Vaughan details that Rabin signatures allow the verification of signatures in Bitcoin Cash script without introducing OP_Checkdatasig.
“All computationally expensive operations (key generation, signature construction) are performed off-block — Only the simple step of verifying that holds is performed within script,” Vaughan writes. “The existentially unforgeable property of the solution allows extra functionality to be added to the Bitcoin Cash platform without compromising the security of the network, nor changing the core protocol itself.”
We will continue to develop this solution using Rabin signatures, and will seek to collaborate with others on this work. Nchain does not intend to seek patent protection for its work on this solution; instead, Nchain will publish its work in this area for public review and usage.
OP_Checkdatasig is slated to be added to the Bitcoin Cash network if the miners decide to unanimously run with Bitcoin ABC’s roadmap. However, as news.Bitcoin.com has reported during the past few weeks, Nchain has an entirely different roadmap in mind for November. Instead, the Nchain development team, Bitcoin SV, and the hashrate that uses the client are shooting for a 128MB block size increase. Bitcoin SV also wants to introduce some opcodes to Bitcoin Cash protocol including OP_MUL, OP_LSHIFT, OP_RSHIFT, OP_INVERT, alongside removing the limit of 201 opcodes per script.
What do you think about OP_Checkdatasig and oracles in Bitcoin Cash? What do you think about Rabid signatures and the opinions opposing the opcode? Let us know what you think about this subject in the comment section below.
Images via Shutterstock, Nchain Logo, and Pixabay.
Need to calculate your bitcoin holdings? Check our tools section.