Stone will be the first DAG (direct acylic graph) data-structured digital currency with private transactions, allowing instant, fee-less anonymous transaction with high scaling (up to 7,000txs per second) Stone will be forked from the RaiBlocks codebase, whilst the chain is not near completion as it currently stands and it just myself who will be working on the project, i do not offer high quality illustrations & impressive marketing, what i do offer, however is highly scalable, private, instant a fee-less transactions, all on a decentralized network once the project is complete
What i can promise you
a finished product
a quality product delivered in a timely manner
What i cannot promise you
An unfinished product, i always complete a project in time.
This pre-announcement is merely just the beginning of a long path, the stepping stone for a great advance in an already amazing pre-existing technology. I cannot express enough respect Colin and his innovative idea which has solved the blockchain debacle, a incredible amount of work and dedication has gone it to his project and Stone will never discredit his efforts.
I’ve been experimenting with the idea of using zkSNARKs, similar to the tech used in the ZCash cryptocurrency, this will prove to be a challenge since we are no longer using a blockchain, we are using a DAG.
From my findings with drafts between the balanced-weighted vote & sk-SNARKs, unfortunately the implementation will not transact in-line in the manner i originally set out to achieve, therefor i have played with the idea of off-chain addresses, t-addresses (Stone) for standard transactions & z-addresses (zStone), with an exact exchange between paired wallets for a private untraceable transaction. My idea further extends to to have Stodes (Nodes), which act as a direct atomic swap 1:1 with Stone & zStone, anyone would be able to see the the swap 1:1 between the two, but no one would be able to see where you have received the zStone as it was transacted off-chain.
Bob -> Alice
(zStone) Transactions -> (zStone) Received
Alice -> Ted (Node) -> Alice
(zStone) Swap 1:1 -> Receive/Send -> (Stone) Received
Alice receives a private transaction from Bob via zStone, Alice now has 100 zStone, Alice now wants standard Stone, she swaps the 100 zStone for Stone 1:1 via a Stone node. The end result is Alice successfully has completed a private transaction with Bob, and swapped back into the base currency, all within the wallet, this method allows the DAG protocol to still function with its representative method.
Apologies in advance for the rough draft schematics, this is not anywhere near complete and is subject to change.
zStone would not be a separate currency and not tradable on an exchange, its simply the channel to achieve completely private transactions, with a swap 1:1 with Stone, they would not be worth anymore or any less.
Current splash screen
a very short summary, zkSNARKs have 4 main ingredients:
A) Encoding as a polynomial problem
The program that is to be checked is compiled into a quadratic equation of polynomials: t(x) h(x) = w(x) v(x), where the equality holds if and only if the program is computed correctly. The prover wants to convince the verifier that this equality holds.
B) Succinctness by random sampling
The verifier chooses a secret evaluation point s to reduce the problem from multiplying polynomials and verifying polynomial function equality to simple multiplication and equality check on numbers: t(s)h(s) = w(s)v(s)
This reduces both the proof size and the verification time tremendously.
C) Homomorphic encoding / encryption
An encoding/encryption function E is used that has some homomorphic properties (but is not fully homomorphic, something that is not yet practical). This allows the prover to compute E(t(s)), E(h(s)), E(w(s)), E(v(s)) without knowing s, she only knows E(s) and some other helpful encrypted values.
D) Zero Knowledge
The prover permutes the values E(t(s)), E(h(s)), E(w(s)), E(v(s)) by multiplying with a number so that the verifier can still check their correct structure without knowing the actual encoded values.
The very rough idea is that checking t(s)h(s) = w(s)v(s) is identical to checking t(s)h(s) k = w(s)v(s) k for a random secret number k (which is not zero), with the difference that if you are sent only the numbers (t(s)h(s) k) and (w(s)v(s) k), it is impossible to derive t(s)h(s) or w(s)v(s).
(Christian Reitwiessner 2016)
Current wallet design
This is how the distribution will be done:
40% Donators (with a cap of 500k, see below)
40% Airdrop to Nano holders
3% Development fund