Great questions, happy to answer them and others.
1) Of course, we understand that it may seem magical, so let us explain the process of transaction signing in more (yet simple) detail.
Every device that participates in the signing of a transaction (minimum of two, up to as many as you want: more devices = more secure) has its own secret. A secret is not a private key nor part of a private key. However, you could get a one-time equivalent of a private key by performing certain mathematical manipulations with all of the secrets that participate in a transaction.
A secret participates in the signing of a transaction and in the generation of a public key, but the secret itself never ever leaves its device. A hacker cannot figure out the secret by interfering with the transaction or compromising one of the devices. It is just impossible.
So, since a hacker cannot gather all the secrets in one place (unless somehow he/she is able to compromise every single participating device at once — which is practically impossible and why we recommend using more than two devices), therefore neither can the hacker perform all of the mathematical manipulations with all of the secrets. This, of course, means that the hacker will not be able to access the equivalent of a private key. This impossibility to get a key from hacking user devices (except all of them at once, which we tested to be practically impossible) means that we do not have a key to steal.
So moving onto the actual process of signing transactions. Usually, the signing of transactions consists of certain mathematical manipulations performed with the private key. The secrets, as you already know, are not a private key, but can help generate a key. As a result, we have the following:
The data (i.e. transaction) is signed (via certain mathematical manipulations) using the first secret. Then, signed data is sent to the next device where they are also signed using a certain mathematical manipulation. On and on until the last participating device signs it and Round 1 is complete.
Then Round 2 begins again with the first device all the way to the last one. When every round is completed, we get the data with the kinds of manipulations that a private key gathered from all the secrets would perform. I.e., this back and forth between all of the participating devices is that magical algorithm that generates a signed transaction. A public key is generated in the same manner.
Here is a very simplified analogy. Imagine that there are two secrets:
First one is 13
Second one is 11
A private key formed from these two secrets would be 11*13=143
Let’s say that we need to sign a transaction represented by the number 2 (for simplicity’s sake).
As such, we need to get a result of 143*2 = 286 for the signature to be accurate and successful (again, simplified)
To get there, the first secret/device generates a random number 3 and then performs the following mathematical manipulation: 3*2*3=78.
It then sends the result (78) to the second device/secret.
The second secret/device generates a random number 5 and performs 78*11*5=4290, sending it back to the first secret/device.
This is the end of Round 1 (we’re using only two devices here for simplicity).
In Round 2, the first secret/device performs 4290/3=1430 and sends it to the second secret/device, which performs 1430/5=286 and send the result back to the first secret/device.
As a result, we get that same 286 that we would get if we multiplied the random numbers originally generated by each secret by each other and then by the transaction number.
But we did it without sending the actual secrets anywhere — i.e. without exposing the secrets to a possible attack. So we are performing the same functions a private key would without the need for one.
Please note that this sample is obviously flawed because we simplified it so much. Specifically, dividing the signed transaction 286 by the transaction’s number of 2 gives us the “private key” of 143. Plus, either of the devices can figure out the secret of the other device in this example. Again, this is just because of the simplification.
To be clear: this simplified example does not reflect what is really going on under the hood. It’s just a small part of what we can use to sign transactions without storing data. Yet, this example is a simple explanation of how we sign a transaction without exposing the secrets and without a private key.
Of course, the actually tech behind the Spatium Protocol is much more complex and eliminates all the flaws of the above example. We will at a later time write a technical post as well to discuss the complex technical details of how the Spatium Protocol works.
2) We are an open source project and are all about providing a decentralized, open source solution. So, of course, we publish all of our software wallet code publicly in our GitHub:
https://github.com/CaspianTechnologies
