We have completed operational verification with features enabling SORA to run on Ethereum-style addresses necessary for blockchain abstraction, as well as the integration of a SORA unified wallet. The latest version is v3.46.13. We will explain each feature, one by one, through X. Moreover, each function is operated through RPC, accessible from the debug window.
– createhdwallet
This constructs a SORA integrated wallet. Since it’s cryptographically impossible to make the traditional wallets compatible with the SORA integrated wallet, they can only be constructed from an initial state with a balance of zero and no redeemScript. Therefore, if there is a balance, it must be transferred to another wallet via transaction before constructing the SORA integrated wallet, after which SORA can be transferred back via transaction.
– restorehdwallet [16 passphrase]
To construct a SORA integrated wallet using a 16-seed, use restorehdwallet. This allows for the automatic restoration of the entire balance with just the 16 seeds.
– getqpubkey
Once a SORA integrated wallet is constructed, it gets equipped with a single quantum-resistant key for the entire wallet. This RPC is used to obtain its public key. This quantum-resistant key, along with V0Witness_P2WSH, is used when employing quantum-resistant multisig. In other words, using a bech32 format (SegWit) address in SORA automatically becomes a “quantum-resistant multisig”.
Note that the quantum-resistant multisig using the bech32 format (SegWit) is still in testing. Quantum resistance increases the size of the signatures, but we conceived the idea of quantum-resistant multisig through P2WSH, cleverly utilizing the SegWit property of separating signatures outside of the block. This way, we can enjoy the benefits of quantum resistance without burdening the block size.
– gethdwalletinfo
Returns the status of the SORA integrated wallet. From the top, in order, it shows validity, encryption status, and lock status.
– getnewethaddress [account name]
Returns an ETH-style address associated with a SORA address. It’s that address that starts with 0x.
– getkeyentangle [ETH-style address]
Returns the “hidden address, locality key” that links SORA and ETH-style addresses. Now, we have come to the locality key. Today’s explanation is about this. The concept of this “hidden address, locality key” comes from the quantum idea that, although two separate events are being observed independently, might we actually be observing just one hidden entity that links those two events? So, when getkeyentangle is called, it returns a SORA address that acts in the same way as if observing the ETH-style address. In other words, since it acts as the same address, if you send SORA to that SORA address, it will go into the ETH-style address. That’s the flow. You think you’re observing two separate addresses, but in reality, they are linked by a hidden address “locality key.” getkeyentangle calculates and provides this linked address. Then, by reflecting the same ETH address on SORA, it will be as if it is operating on SORA with the same key as ETH. More on this next time.
https://github.com/FromHDDtoSSD/SorachanCoin-qt/releases/tag/v3.46.13
