SORA-QAI tec info

Project Name: SORA L1 Blockchain
Version info: v3.67.14
Date: May 17, 2024 complete!
Author: SORA-QAI

SORA-QAI:
https://github.com/FromHDDtoSSD/SorachanCoin-qt/commit/c74ef646ae2fccb9ef324b330fc0a18e4bc557f5

I, Structure of scriptPubKey

This transaction leverages the properties of the traditional OP_CHECKMULTISIG and has been implemented via a soft fork. In this section, we will detail the structure of scriptPubKey.

CScript() << OP_1 << ECDSA publickey << SORA-QAI public key ID << SORA-QAI extended INFO << OP_3 << OP_CHECKMULTISIG

Structure of OP_1 and OP_3

The structures of OP_1 and OP_3 are treated as standard transactions. In this context, the first script corresponding to OP_1 has been assigned an ECDSA public key.

The Remaining Two Elements

The remaining two elements are scripts that would normally be ignored. As a constraint, their size is 33 bytes, which is typically used to store a compressed ECDSA public key. Therefore, according to this rule, we store the ID of the new SORA-QAI public key and its extended information.

Combination of 0x02, the Remaining 32-Byte Area, and CKeyID

First, let’s explain the location of the SORA-QAI public key. The leading byte is 0x02. Typically, this area is used to store a compressed ECDSA public key, where the binary format begins with 0x02 or 0x03. To make this recognizable as a standard transaction, we allocate 0x02 as the leading byte. This allocation leaves 32 bytes available. Here, recall the CKeyID, which is a hash structure and consists of 20 bytes.

Conversion of the SORA-QAI Public Key

The SORA-QAI public key is converted to 20 bytes using CKeyID. The remaining 12 bytes are filled with 0x00. This allows us to distinguish it from an ECDSA public key, as the probability that the last 12 bytes of an ECDSA public key’s binary format would all be 0x00 is virtually zero.

Storing SORA-QAI Extended Information

The next 33 bytes are used to store the extended information for SORA-QAI. The first byte is 0x02, followed by a byte for version information. The next 20 bytes are free, and the remaining 10 bytes are filled with 0xFF.

II, Structure of scriptSig

The structure of scriptSig is assembled as follows.

CScript() << OP_0 << ECDSA signature << SORA-QAI publickey << SORA-QAI signature

Utilizing OP_0 and Its Resulting Side Effects

OP_0 exists as a common bug workaround in blockchain. It adjusts the stack when the number of items does not match at the end. This fact indicates a side effect where the stack and the 33-byte area in scriptPubKey do not have a one-to-one relationship. Therefore, additional information for SORA-QAI can be stacked behind it.

Impact if Strict Enforcement is Applied

If strict enforcement is applied, the structure of OP_1 to OP_3 requires a total of one stack. Therefore, it is not possible to stack additional items.

III, Implementation via Soft Fork

There are two types of implementations via soft fork. The first is SegWit. By cleverly serializing CTransaction and assigning a dummy empty vector to CTxIn as a flag, old nodes will ignore the elements after CTxIn. Thus, even if the serialization after CTxIn is shifted by one byte (as the dummy empty vector is serialized as a single byte, 0x00), it will not cause an error. Therefore, old nodes will pass it without issue.

The second method, which we have adopted this time, effectively utilizes the workaround for OP_CHECKMULTISIG. This approach also avoids errors on old nodes.

IV, Advantages and Disadvantages of Each Soft Fork

SegWit

Advantages:

• Fee Reduction: By moving scriptSig to a dedicated area, it can be excluded from the transaction size calculation, reducing fees.
• Transaction ID Uniqueness: ECDSA signatures lack uniqueness (as not using random numbers can lead to private key leakage), posing a risk of signature alteration and transaction ID change before being included in a block. Moving scriptSig to a dedicated area excludes it from the transaction ID hash calculation, maintaining the uniqueness of the transaction ID.

Disadvantages:

• Lack of ECDSA Verification: Since CTxIn becomes a dummy with 0, old nodes do not perform ECDSA verification and simply pass it through.
• Complex Code Changes: There are many code changes, making verification and adding new features more complex.

SORA-QAI Method Utilizing OP_CHECKMULTISIG Workaround

Advantages:

• Reuse of Existing Code: By extending OP_CHECKMULTISIG and integrating the new address format into base58, a large part of the existing verified code can be reused, making it easy to introduce new features.
• Quantum & AI Resistance: Quantum & AI-resistant signatures have uniqueness, and combining this with multisig ensures the uniqueness of the transaction ID. Altering the ECDSA signature invalidates the quantum & AI-resistant signature, rendering the transaction invalid.

Disadvantages:

• Transaction Fees: Since scriptSig is used as is, transaction fees do not change.
• Lack of Transaction ID Uniqueness: If verification is limited to ECDSA, the nature of the signature means the transaction ID lacks uniqueness. However, Quantum and AI-resistant signatures are unique, which, combined with multi-signature, ensures the uniqueness of the transaction ID. This is because altering the ECDSA signature would invalidate the quantum and AI-resistant signature, rendering the transaction invalid.

V, Detection of SORA-QAI Transactions

To detect this transaction, we examine the scriptPubKey, specifically the SORA-QAI public key ID part. This part was intended for the stack used by compressed ECDSA public keys. Therefore, it is converted to 20 bytes using CKeyID, and the remaining 12 bytes after the leading 0x02 are always filled with 0x00. This characteristic is used to detect SORA-QAI transactions.

Structure of SORA-QAI public key ID
0x02 | SORA-QAI public key ID (20 bytes) | 0x00 (12 bytes)

VI, Detection of SORA-QAI Version Information

To detect the version information of this transaction, we examine the scriptPubKey, specifically the SORA-QAI extended INFO part. This part was also originally intended for the stack used by compressed ECDSA public keys, so it begins with 0x02. The byte following this is the version information.

Structure of SORA-QAI extended INFO
0x02 | Version | SORA-QAI free field (20 bytes) | 0xFF (11 bytes)

VII, SORA-QAI Hash Target

First, obtain the ECDSA hash using SIGHASH_ALL. Then, stack the information into CScript in the following order, and hash it using CHashWriter.

CScript() << ECDSA signature << ECDSA public key << SORA-QAI public key ID << SORA-QAI free field INFO << ECDSA SIGHASH_ALL hash << Version << nHashType

Including ECDSA Signature in the Hash Target

As a result, changes in the ECDSA signature will alter this hash. Since ECDSA signatures utilize random numbers, the contents of a valid signature can vary, causing the transaction ID to change. However, the Quantum & AI-resistance signature of SORA-QAI is unique. If the hash target changes, the signature becomes invalid, ensuring that there is no risk of a modified transaction ID being included in a block by miners.

VIII, base58 and bech32

There are two address formats: base58 and bech32. Generally, P2PKH uses the base58 format, while SegWit adopts the bech32 format. These formats are distinguished by their structure, but implementation-wise, they can be used freely. Therefore, SORA-QAI is initially implemented using the bech32 format.

Mechanism for Distinguishing Address Formats

When multiple address formats are implemented, how are they distinguished? First, the address is decoded to obtain the binary data. A part of this binary data contains an identifier that distinguishes the address format. From this identifier, the structure of the scriptPubKey is determined, and the appropriate processing is applied.

Hard Fork and Soft Fork

This brings us to the issue: Can we easily add a new address format in that part? No, it is difficult. If a new format is added arbitrarily, old nodes cannot interpret the new format and will treat it as an error. This will prevent consensus from being achieved, necessitating a hard fork to update the nodes.

However, as experienced in running a blockchain, requesting a hard fork is extremely challenging. Therefore, a soft fork, which gradually transitions to achieve consistency, is preferred. Soft forks include mechanisms to make the new format recognizable by old nodes. SegWit is one such example, and SORA-QAI has implemented similar sophisticated measures.

IX, Soft Forks and the SORA-QAI Approach

Soft forks like SegWit utilized a structure where a dummy element is added to the serialization of CTransaction. SORA-QAI, on the other hand, focused on the structure of P2SH.

SegWit Approach

As mentioned earlier, adding a dummy to CTransaction results in the element count of CTxIn being zero in old nodes, treating it as a transaction with no inputs. When this is included in a block, old nodes interpret it as having no inputs and pass it through without further processing, thus avoiding errors.

SORA-QAI Approach

SORA-QAI leveraged the structure of P2SH and the workaround for OP_CHECKMULTISIG (OP_0). By utilizing these two methods, SORA-QAI was able to implement a soft fork with minimal changes, reusing existing, well-verified code. Reusing existing code is the safest approach since it has already undergone thorough testing.

X, Structure of SORA-QAI Verification

The verification structure for SORA-QAI transactions involves the following steps:

1. Identification of SORA-QAI Transactions
   First, identify whether the transaction corresponds to SORA-QAI.
2. Conditional Branching Based on Version Information
   Next, perform conditional branching based on the version information.
3. Investigation of All Stacks
   Since the blockchain stack has a variable structure, all stacks are investigated. This is necessary because data can be placed arbitrarily.

Checking the Association Between the Public Key in scriptSig and scriptPubKey

Compare the CKeyID of the public key stored in scriptSig with the SORA-QAI CKeyID stored in scriptPubKey. If they match, it confirms that scriptSig is associated with the corresponding scriptPubKey.

Constructing the Verification Hash and Performing Validation

Once it is confirmed that the public key in scriptSig is associated with scriptPubKey, construct the verification hash. This constructed hash, along with the public key and the Quantum & AI-resistance signature, is used for validation. It is important to exclude the nHashType embedded in the last byte of the Quantum & AI-resistance signature.

If this validation fails, EvalScript immediately fails, preventing consensus and thereby ensuring the validity of the Quantum & AI-resistance verification.

Passing to OP_CHECKMULTISIG After Quantum & AI-Resistance Verification

If the Quantum & AI-resistance verification is successful, the process is passed to OP_CHECKMULTISIG. Since scriptSig and scriptPubKey contain the ECDSA verification public key and signature, ECDSA verification is then performed.

XI, Passing EvalScript Verification:
Aligning the Stack for OP_CHECKMULTISIG’s OP_0 Workaround

EvalScript includes verification flags, one of which is specifically for verifying the OP_0 workaround in OP_CHECKMULTISIG. During verification, when OP_0 is reached, it requires that the stack is empty. However, we must consider why this workaround was necessary.

If the stack’s position and number were strictly one-to-one, this workaround wouldn’t be necessary. Therefore, by exploiting the lenient nature of stack position and number, we temporarily mimic a standard state only for this check. After successfully passing this check, we quietly remove the extra SORA-QAI stack to maintain consistency.

By This Mimicry, Introducing a Completely Different Verification Algorithm as Multisig into OP_CHECKMULTISIG

The lenient nature of stack positions and counts applies to old nodes as well. Therefore, while old nodes cannot verify SORA-QAI and will ignore it, they will still perform ECDSA verification reliably.

XII, P2SH and scriptPubKey

In P2SH, the CScriptID of the scriptPubKey is stored as the P2SH scriptPubKey. During the preprocessing phase of EvalScript, a script concatenation process occurs, where the original scriptPubKey, calculated from the CScriptID, is called and concatenated. This combined script is then processed by EvalScript.

Relationship Between P2SH and base58

P2PK, P2PKH, and P2SH are implemented in the base58 format. As mentioned earlier, decoding base58 reveals an identifier binary at the beginning. This identifier is used to call P2SH, but it remains in the base58 format. In SORA-QAI, to utilize bech32, an additional process is applied to embed bech32 in this identifier part.

Handling base58 Calls with bech32 Addresses

First, base58 and bech32 can be distinctly differentiated. When a base58 call is made with a bech32 address, the internal processing is switched to bech32 while passing the processing to P2SH. During this process, pay attention to the bool operator== in the base58 processing part. This operator is used for comparisons between base58 addresses. When bech32 is incorporated into the base58 internal processing, the binary structures are fundamentally different, making this operator unsuitable for comparison. Therefore, ensure that comparisons are done using ToString instead.

bool operator==(const CBase58 &a, const CBase58 &b) const { return a.ToString() == b.ToString(); }

Compatibility with SegWit

Introducing bech32 into SegWit allows for concurrent operation with SORA-QAI. This is feasible because SegWit operates through different mechanisms, such as P2WPKH, ensuring that the processes can be distinctly separated.

Registration and Identification of SORA-QAI Addresses

SORA-QAI addresses can be registered by constructing their scriptPubKey as P2SH. Once registered, they are processed in conjunction with bech32. The key consideration here is how to handle the wallet balance calculation.

A wallet’s balance is shown as the cumulative total of unspent scriptPubKeys that it owns. Therefore, it is essential to enable the wallet to recognize SORA-QAI scriptPubKeys.

Steps for Implementation:

1. Address Registration: Register the SORA-QAI scriptPubKey as P2SH and associate it with the bech32 format.
2. Identification Addition: Update the wallet’s balance calculation logic to recognize SORA-QAI scriptPubKeys.
3. Balance Calculation: Ensure the wallet calculates and displays the balance including unspent SORA-QAI scriptPubKeys.

XIII, Assembling SORA-QAI scriptSig

To utilize an unspent SORA-QAI scriptPubKey, assembling the SORA-QAI scriptSig is necessary. The assembly process is as follows:

1. Check with Solver:
   • Confirm that the SORA-QAI stack exists in the scriptPubKey.
2. Assemble scriptSig:
   • Use the already existing ECDSA SIGHASH_ALL hash.
   • Sequentially sign based on the hash and assemble the scriptSig.
3. Pass EvalScript:
   • Ensure that the assembled scriptSig passes EvalScript and gets approved.
4. Release to Memory Pool:
   • Release the approved script into the memory pool.

Mechanism of Quantum & AI Resistance

Traditional cryptographic algorithms such as ECDSA, Ed25519, and RSA are based on the discrete logarithm problem. Essentially, they rely on the difficulty of solving certain mathematical problems without knowing specific periodicity, making brute-force attacks impractical.

Quantum Computing Approach

Quantum computers use parallel computation to explore many candidates simultaneously and can detect periodic patterns. Initially, candidate solutions have equal probability amplitudes. If the quantum state collapses, only one solution is randomly obtained.

Role of Quantum Fourier Transform

The quantum Fourier transform converts these candidate solutions into periodic information, where information corresponding to the period has the highest probability amplitude. As a result, quantum computers can efficiently obtain this high-probability periodic information.

Importance of Quantum & AI Resistance

Quantum computers can efficiently perform inverse calculations that are difficult for classical computers, potentially deriving private keys from public keys or signatures. Therefore, developing new cryptographic algorithms that are resistant to quantum and AI-based attacks is crucial. These new algorithms must have mathematical structures that are difficult for quantum computers to solve and designs that are robust against AI attacks.

XIV, Implementation of Quantum & AI-Resistance Multisig

ECDSA, Ed25519, and RSA use periodic keys, where security is ensured by the unknown periodicity. However, using the same type of periodic keys in multisig is ineffective. Thus, we utilize non-periodic keys.

Non-Periodic Keys and Hash Functions

Non-periodic keys leverage the properties of cryptographic hash functions. The main characteristics of cryptographic hash functions include:

• Collision Resistance: The probability that different inputs produce the same output (hash value) is extremely low.
• Unpredictability: Even a slight change in the input generates a significantly different hash value (avalanche effect).
• One-Way Function: It is extremely difficult to reconstruct the original input from the hash value.

Quantum & AI Resistance Multisig

We implemented quantum & AI-resistant multisig using keys based on these properties. Unlike ECDSA, which requires randomness in signatures, the signatures made with quantum & AI-resistant private keys are unique. While there is a non-zero probability of generating the same valid signature due to hash collisions (different inputs yielding the same hash value), in SORA-QAI, this probability is as low as 1/2^128, making it negligible.

By combining periodic and non-periodic keys, SORA-QAI ensures robust security against Quantum and AI-based attacks, leveraging the inherent strengths of both types of cryptographic elements.

XV, Compatibility Between Traditional ECDSA (P2PK, P2PKH, P2SH) and SORA-QAI

Traditional ECDSA (P2PK, P2PKH, P2SH) uses addresses that start with “S”. In contrast, SORA-QAI addresses start with “sora1”. These address formats are compatible with each other.

Details of Compatibility

1. Address Compatibility:
   • Funds can be sent from traditional “S” addresses to “sora1” addresses.
   • Conversely, funds can also be sent from “sora1” addresses to traditional “S” addresses.
2. Usage of scriptPubKey:
   • Users can utilize “sora1” scriptPubKey without any special considerations.
   • Processing based on the scriptPubKey format is handled seamlessly.

Implementation Considerations

• Transaction Creation:
  • When creating transactions, the wallet software should be capable of recognizing both address formats and handle the necessary encoding and decoding.
• Verification:
  • During the verification process, the software should ensure that scriptSig and scriptPubKey are correctly interpreted according to their respective address formats.

By ensuring these compatibility features, SORA-QAI can seamlessly integrate with existing blockchain infrastructure while providing enhanced security through quantum & AI-resistance cryptographic mechanisms.