Published on: 2015-11-29T23:41:43+00:00
In a bitcoin-dev mailing list discussion on November 27, 2015, Mats Jerratsch proposed the introduction of a new general OP_CRYPTO to enable various types of crypto operations in script. His suggestion involved using a prefixed 0x01 byte to push "OP_CRYPTO" onto the stack, with OP_CRYPTO examining the top item on the stack to determine its action. This proposal would not require a softfork and could allow for expandable multi-byte pushes. Jerratsch also discussed certain constructions that could potentially disrupt the signature scheme but were either too large or costly to compute.As a response, it was suggested to include additional crypto ops into a BIP (Bitcoin Improvement Proposal) for a check-verify crypto toolkit op. Practical uses in the near future were mentioned for base-point multiply on secp256k1 (CHECKPUBPRIVPAIR) and Schnorr-signature of transaction with secp256k1 curve (smaller, faster, more-anonymous N-of-N multisig). Other suggestions included general point addition/multiply on secp256k1, SHA3-256/SHA2-512/SHA3-512, and ECDSA/Schnorr signature of value from stack. It was also noted that if the segregated witness soft-fork is feasible, any opcode could be re-enabled/changed/added as a soft-fork, not just converting a NOP into CHECK_foo_VERIFY. Therefore, it was recommended to observe the progress of the segregated witness soft-fork before drafting a BIP or similar proposal.Furthermore, onion-routing has been proposed as a means to enhance privacy while utilizing a payment network. In this approach, each node only knows the preceding and succeeding node in the payment route, without having information about its position, the payer, or the payee. However, the use of preimage-hash pair R-H in payments within the network can compromise privacy by reducing the number of nodes an attacker needs to control. To address this issue, it was suggested to employ private/public EC key pairs instead of RIPEMD-160 for preimage-hash construction. This would require a method to derive a private key from a public key on the blockchain. One possible approach is to utilize one of the currently unused OP_NOP codes, allowing for deployment through a softfork. Alternatively, a Non-Interactive Zero-Knowledge Proof (NIZKP) can be used to demonstrate that a node can recover a preimage based on certain information, but these calculations are computationally expensive.
Updated on: 2023-08-01T16:55:54.181027+00:00