The smart contract technology permits the creation of new protocols that can be implemented on top of bitcoin’s protocol itself. This signals the development of complex scripts, that are far beyond the requirement of a single digital signature. A research paper, which has been published a few days ago, introduced a new concept of private key locked bitcoin transactions, which represents an innovative type of transactions that permit atomic verification of a specific private key (which belongs to an asymmetric pair of keys) throughout the process of execution of the script.
What Are Private Key Locked Bitcoin Transactions?
Although the present hash locked bitcoin transactions permit the usage of a symmetric key to unlock the value of a transaction, or even a private key that belongs to an asymmetric pair of keys, considering that a private key can only be verified using the correspondent public key can inspire the development of a more secure and simple approach.
Symmetric keys are forms of arbitrary characters, as they are strings of bits. Consequently, the only way to certify the validity of a given symmetric key is to confirm that it successfully decrypts data which was initially encrypted using that same key.
On the other hand, anyone can check if a private key and a public key match a pair. This can easily be achieved using the Elliptic Curve Digital Signature Algorithm ECDSA; you just have to multiply, the integer that represents a given private key, by a base point on the elliptic curve, a predefined system parameter, which would result in a point on the curve that corresponds to the public key. The bitcoin protocol uses a secp256k1 implementation to formulate ECDSA operations which includes a mathematical function that multiplies a given generator by a specific scalar (secp256k1_ecmult_gen). This function is utilized to calculate ECDSA digital signatures.
By developing novel bitcoin opcodes, a new crypto opcode can be implemented to perform this validation statement OP_CHECKKEYPAIRVERIFY which will pop outside the two values of privKey and pubKey, which correspond to ECDSA’s private key and public key respectively) and verify that the two keys match a pair. Alternatively, if the two keys match a pair, the opcode will roll back to the stack’s two operands and the transaction execution process will start.
OP_CHECKKEYPAIRVERIFY execution would fail whenever the validation process doesn’t ensue and so, the stack would remain unchanged. This will guarantee that the opcode can only be implemented in the form of a soft fork via utilizing one of the unused OP_NOPx opcode, in a way that closely resembles what has been done previously with OP_ CHECKLOCKTIMEVERIFY (OP NOP2) and OP_CHECKSEQUENCEVERIFY (OP NOP3).
Utilizing this new form of opcode can construct a transaction output in a way that will only be executed, if and only if, the private key and the public key in question match a pair. The following represents a scriptPubKey of such transaction output along with the scriptSig required to spend it:
ScriptPubKey: pubKey OP_CHECKKEYPAIRVERIFY OP_NIP OP_CHECKSIG
ScriptSig: sig privKey
The script will initially confirm that the private and public keys represent a matching key pair. It is worth mentioning that the stack value will remain unchanged, if the validation process is completed successfully. Accordingly, before confirming the signature validity via OP_CHECKSIG, the value of the private key should be taken off the stack, due to the fact that it is not needed throughout the process of signature validation. On the other hand, executing OP_NIP will take the private key off the stack. In the end, OP_CHECKSIG will start the process of signature validation with the corresponding public key. When the signature is validated successfully, the script will terminate and the funds will be redeemed by the predesigned payment receiver.
Although utilizing the proposed OP_CHECKKEYPAIRVERIFY opcode is seemingly useful in the creation of bitcoin smart contracts, practically speaking, this opcode is nonexistent. OP_CHECKKEYPAIRVERIFY can be proposed in the form of a BIP. Meanwhile, the authors of the paper proposed using an existent ECDSA vulnerability to achieve the same goal, which is creating transaction outputs that are reliant on revealing specific private keys to be successfully spent and redeemed. This vulnerability is an innate property of the ECDSA signature scheme, which permits sound implementation of the key verification process.
TheBitcoinNews.com – Bitcoin News source since June 2011 –
Virtual currency is not legal tender, is not backed by the government, and accounts and value balances are not subject to consumer protections. TheBitcoinNews.com holds several Cryptocurrencies, and this information does NOT constitute investment advice or an offer to invest.
Everything on this website can be seen as Advertisment and most comes from Press Releases, TheBitcoinNews.com is is not responsible for any of the content of or from external sites and feeds. Sponsored posts are always flagged as this, guest posts, guest articles and PRs are most time but NOT always flagged as this. Expert opinions and Price predictions are not supported by us and comes up from 3th part websites.
Advertise with us : Advertise
Our Social Networks: Facebook Instagram Pinterest Reddit Telegram Twitter Youtube
