SORA-QAI Blockchain

SORA official X:
>> Click here

Technical official news:
>> Click here

SORA Blockchain Security [SORA testnet]

The development of SORA L1 has completed the implementation of quantum resistance, Schnorr signatures, and Schnorr aggregated signatures in addition to traditional ECDSA.

As a result, we are now focusing on blockchain security research, specifically examining the structure of the Bitcoin mainnet blockchain. We aim to apply the insights gained from this research to SORA.

The most critical security measures for blockchains include the prevention of side-channel attacks, the prevention of double-spending, and hash integrity. These areas represent structural vulnerabilities for blockchains. The details of why these are vulnerable, along with the findings of our research, are summarized and will be continuously updated at the following URL.

We are conducting research while demonstrating actual transactions using a bitcoin - mainnet block explorer. In fact, there were many bots targeting Bitcoin when it was exposed to vulnerable conditions. By tracing those addresses, we have uncovered some intriguing insights, which we are also sharing.

https://www.data-crash.com/

About SorachanCoin SORA L1 Blockchain - Core

In addition to traditional ECDSA, the implementation of quantum resistance, Schnorr signatures, and Schnorr aggregated signatures has been completed.

https://github.com/FromHDDtoSSD/SorachanCoin-qt
  • Well, development is continuing during the New Year holidays.

    1, Add script for prediction processing to the basic functions (P2PKH, P2SH, P2WPKH, P2WSH).
    2, We will add a transaction for quantum resistance.
    The size of the keys(CLPubKey, CLKey) will increase.

    SorachanCoin intends to support the keys below:
    CPubKey, CKey:
    wallet of old core.(only supported random)
    CPubKey, CFirmKey:
    wallet of latest core.(both supported random and HD)
    CLPubKey, CLKey:
    wallet of quantum resistance.(only supported HD)

    We have implemented a latest log function.
    Then, the String processing has also been adapted to the latest core.
    SORA is gradually becoming a latest core. thank you so much!
    src/util/logging.cpp
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/develop/src/util/logging.cpp
    src/util/logging.h
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/develop/src/util/logging.h
    The system part had been also become the latest core.
    In addition, the code of the old core coexists, and no problem occurs with any version of the core.
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/commit/fdedac56647f2dbc3198b60d9a49e090ce211589

    We have been reviewed the CKey code in the latest core and we implemented the enhanced CFirmKey. (class CFirmKey)

    We have added enhanced random numbers(GetStrongRandBytes) for erasing used key containers, strengthening confirmation of infinite values, separating the ctx, and generating keys.

    src/key/privkey.h:
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/develop/src/key/privkey.h

    src/key/privkey.cpp:
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/develop/src/key/privkey.cpp

    improvement example, SorachanCoin PrivateKey CTX build:
    bool CFirmKey::ecmult::secp256k1_gen_context::build() noexcept
    before code:
    return secp256k1_ecmult_gen_blind(NULL);
    after code:
    unsigned char seed[32] = {0};
    latest_crypto::random::GetStrongRandBytes(seed, 32);
    bool ret = secp256k1_ecmult_gen_blind(seed);
    cleanse::OPENSSL_cleanse(seed, 32);
    return ret;
    

    CKey: for old logic private key (base58).
    CFirmKey: for latest logic private key (bech32).

    SorachanCoin CFirmKey Transaction:
    CKey(base58) => CKey(base58): OK
    CKey(base58) => CFirmKey(bech32): OK
    CFirmKey(bech32) => CKey(base58): OK
    CFirmKey(bech32) => CFirmKey(bech32): OK

    We are implementing BIP32 and BIP66.
    Therefore, we will implement to use OpenSSL for random wallet
    and secp256k1 (libsecp256k1) for HD wallet.

    At first, The develop branch now supports BIP66.
    In addition, since the DER signature has been became strict,
    on effect that with the conventional OpenSSL verification became result in "hybrid",

    these will work without problems in a wide range of circumstance.
    In addition, we had been enabled ENDOMORPHISM. thanks.

    By the way, we implemented secp256k1 in CPubKey,
    and there was something that was worried about.
    When secp256k1_ge is infinity,
    error checking is no opetrate and that bytes array is accepted as a public key as it is.

    So we put in some error handling and put in the code to disable.

    key/pubkey.h
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/develop/src/key/pubkey.h

    key/pubkey.cpp
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/develop/src/key/pubkey.cpp

    Also (pubkey.h: template void Unserialize(Stream &s)),
    in the environment of optimization -O3,
    we decided that the following code does not come out correctly.

    // invalid pubkey, skip available data
    char dummy;
    while(len--) {
       s.read(&dummy, sizeof(char));
    }
    Invalidate();
    

    If we affect in "another side effect" when is "Unserialize",
    we think that will come out correctly,
    but since it is an important place, it is as follows just in case.

    // invalid pubkey, skip available data
    char dummy;
    while(len--) {
       s.read(&dummy, sizeof(char));
       ::OPENSSL_cleanse(&dummy, sizeof(char)); // Even if -O3, Unserialize operate exactly.
    }
    Invalidate();
    
    We will soon complete the verification of new features. (e.g. getblockqhash)
    We would like to go with the release .....
    But before that, we found one problem that have been from before SORA released.
    In the process of the SecureString,
    we found a problem that the passphrase remains in "plain text" in the object before passing.
    Therefore, we have improved the SecureString so that the "plain text" passphrase is cleaned by "::OpenSSL_cleanse" in the functor method.
    We will also make these corrections together and release Ver2.2.9.
    1, allocator.h (class SecureString)
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/master/src/allocators.h
    2, rpcwallet.cpp SecureString functor.
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/master/src/rpcwallet.cpp
    3, qt/askpassphrasedialog.cpp
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/master/src/qt/askpassphrasedialog.cpp

    We have been updated the source code as the development version.
    Moreover we have been completed the verification the code and will generate a Windows version from here and update the master branch.

    The each factors that makes up the Blockchain was brought to the smallest unit.
    This is reason, we have developed a system that allows easy implement of “new features”. thanks!

    https://github.com/FromHDDtoSSD/SorachanCoin-qt/tree/develop/src

    e.g. improvement blockchain

    [old code] main.h, main.cpp
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/master/src/main.h
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/master/src/main.cpp
    [new code] block, main.h, main.cpp
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/tree/develop/src/block
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/develop/src/main.h
    https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/develop/src/main.cpp

    We are under development at the same time as drive failure prediction to implement both current hash and new hash to wallet.

    1, Reference of new hash
    This new hash is an experiment for a quantum computers.
    Therefore, we will always support current the hash until the birth of a quantum computers.
    By the way, there is NOT change in current mining’s hash (PoW).
    Please be assured.

    2, Automatic Checkpoints
    In order to improve the quality of the blockchain,
    we have been developed a function that can automatically add checkpoints.

    A Checkpoints are automatically added in SORA Network.
    Of course, we maintain decentralization.
    The longest chain is the "mainstream".
    At first, we will adopt a method similar to hard coding.
    By the end of the year,
    we will set up another "short blockchain" and operate exclusively for a Checkpoints.
    thanks.

    We are under development at the same time as drive failure prediction to implement both current hash and new hash to wallet.
    A new logo has been created with the image of quantum fluctuations.
    Of course, our developer are also going to prospect to implement the drive failure prediction.
    Then, we will also firmly develop the blockchain core!
    We have completed the operating test of below hash.
    Currently, we are developing the code that separate from class CBlock into a template
    (template <typename T> class CBlock_impl).
    Because, old blocks (because the hash of Genesis is required for the this Blockchain), are required and new blocks are after forked. thanks.
    We are translating the development history in English until porting from recovery to Blockchain. thanks!
    [Click here: https://www.iuec.co.jp/recovery/estimate/]
    We released the white paper part II that about a "drive inspection and prediction" by Blockchain. This is the reason why we have been launched up developing "failure prediction" using with Blockchain.
    [Click here: https://www.iuec.co.jp/recovery/algo.html]
    We translated the development history in English until porting to Blockchain.
    Server maintenance has been completed. thanks!
    Also it seems that the device of the server has been renewed,
    and it has become comfortable. greatful!
    We have released the 2.1.9 Windows version wallet. [>> download]
    (Supported: Windows 10, 8.1, 8, 7, Vista, XP)
    After Ver2, which introduces a plenty of functions, has begun. Thank you so much.
    First of all, it begins good effect from the improved "prevector" by SorachanCoin.

    About SorachanCoin-Core blockchain-benchmark:
    Due to the data structure and threads optimisation, we removed all Qt and rewrote everything with Windows API. First, after supporting Windows version, Linux version (ubuntu) will also be rewritten from Windows API code.

    The following detailed explorer-like Block explorer will be built into the wallet.
    We are confident in this implementation. thanks.
    ※ Click Sendcoin, Transaction, SORA Network, QKey Recvcoin, or DB Information to start up.

    under development [SorachanCoin-Core blockchain-benchmark]
    The Benchmark and a drive scan in blockchain.

    We will implement a balance function to monitor the health condition of a drive by the blockchain.
    This type of concept had been before for eight years.
    By the blockchain is finally ready for operation. [Random access: 8192KB => 512KB => 4KB]

    NEW! We have released the 1.1.8 Linux(Ubuntu) version wallet. [>> download]

By the way ... How do you exactly confirm the data on database?

In addition to the hash, the metadata (eg, A below) that manage confirmation is attached.

simple eg, about coefficient (similar to Zero-knowledge proof)
true: 2.0, false: 0.5

strict: (large data)
ACCEPT:A(true)A(true)A(true)A(true)A(true)A(true)=> 64 : accept
DENY:A(true)A(true)A(true)A(false)A(true)A(true)=> 16 : deny

permissive: (small data)
ACCEPT:A(true)A(true)A(true)A(false)A(true)A(true)=> 16 : accept
DENY:A(true)A(false)A(true)A(false)A(false)A(true)=> 1 : deny

Utilizing the experience of developing data recovery software, we are also considering a mechanism to build a pseudo file-system, include a signature into it, and guarantee access to each data according to the signature with a blockchain.