We are moving, quickly, into an age of Digital, Cryptographically secured funds.

First there was Bitcoin. Simple payments from one PGP key to another.

Now there's Ethereum executing open source code in a turing complete virtual machine with a synchronized and global shared state.

This new technology, naturally, attracted participants from all walks of life--notably criminals.

Recently, Wannacry ransomware made headlines. People's valuable data encrypted; a king's ransom demanded--your data's weight in (almost) untraceable crypto currency.

That's because along with the age of Digital, Cryptographically secured funds came the age of Cyberwarefare.

What was once the weapon of a powerful Nation State with the capability to effect its ends through conventional warfare became the play thing of any malicious engineer or tinkerer with a greedy lust for quick anonymous wealth.

Canada, known world wide not as an aggressor or enemy, but instead as a peace keeper that embodies the notion of tolerance is perfectly suited for the task of keeping the peace in an age of digital warfare.

Montreal, billed as "The Silicone Valley of AI" is filled with honest, trustworthy engineers who prefer to pay as much as 40% income tax to ensure all fellow Quebecers are afforded every necessity of life than to flee to the United States of America and look out only for themselves. Truly, Montreal engineers embody the sprit of the open source movement.

When a nation or corporation's malfeasance has the capability of crippling data systems--the very same data systems Ethereum is run on--the security of our Cryptographically Secured Funds comes in to question.

In the past 2 weeks, there have been a number of long-standing linux exploits reported and patched. As was the case with Windows.

Regularly we hear about embeded systems including backdoor "testing" or "debugging" accounts that "wern't meant to make it into the released product". Imagine your bank saying "we left the vault door open with a sign saying don't close this or the door to the bank tonight, as a test, and didn't mean for all your money to be taken." Certainly, its customers would not be amused. And yet, this is the foundation our digital economy is to be based on.

Bank profits and fees are a reality. They help keep things like vault doors closed and secure when they need to be.

The digital economy needs a similar investment.

Kaspersky set out to build a secure OS for for industrial systems -- https://it.slashdot.org/story/12/10/16/1711222/kaspersky-to-build-secure-os-for-scada-systems .

For everyone else, we seek an auditably secure linux.

We're talking about developing software to convert code--be that programmer friendly source code or sneaky compiled bytecode--into logic tables. Really, really big logic tables. With "compression" where possible (if all output values between 1-65,535 follow the same codepath, have "1-65, 535" as an output).

We want to include sensitivity for language and hardware word sizes. Pass/fail for 32 bit system, for those using only two's complement signed integers, etc.

We want to train neural networks as we manually review the logic tables. We want them to have perfect F1 scores, but only so that they can constantly double check our work--not so we can randomly double check theirs.

We want these tools to be open source. We want everyone to use them. We want to have our software secure, so that eventually our economy and hardware can be too.

Do you believe in a future where a person can't be targeted by a hostile political faction with intolerant views? Where one powerful entity can't cripple the public services of and destabalize another?

As Canadians, we like to believe all engineers resident in Montreal do.

Adopters of the digital future, help us help you.

There are a great many considerations with respect to the security of the Crypto Currency ecosystem.

For instance, Canada's tax agency has stated they intent to tax Crypto Currencies aggressively.

If there are some countries which tax newly minted coins as though they have been manufactured, and others that treat mined coins as a payment, there will be definite national lines with respect to crypto centralization.

The price floor is essentially Cost Of Electricity + Cost Of Hardware modified by Expected Difficulty Curve.

When one miner can afford to sell BTC at 5% above cost (their profit), but another country's citizens needs to pay 15% tax on the BTC they mined plus collect 15% tax on top of the 5% desired profit, miners in the heavily taxed region will be at an economic disincentive. It may very well cost them more to mine than they will get back when they sell the Crypto.

That sounds very much like centralization to me!

But enough about the non-code issues!

How does our proposed solution work?

    if( isset( $_GET['id'] ) ) {
        if( $_GET['id'] == true ) {
            echo "Hello World";
        } else {
            echo "Ohh no!";
    } else {
        echo "Worst case!";

Consider the above very simple code snippet.

Converted to the logic table, you would first see an input " isset( $_GET['id'] ) " that then branches into two paths.

Down one, it leads to a NOR gate with many inputs, down the other there is a NOT gate that leads to: output "Worst case!"

The NOT gate is simple, the NOR gate is counter intuitive.

The NOT gate is testing the following:

The output from that NOR gate then branches the same way the first input in the circuit did. Straight to an answer, or to a NOT gate then an answer.

Through the NOT gate you have: output "Oh no!"

The other pass has: output "Hello World"

But the magic comes in the next step!

You would get a "plain english" explanation of the circuit.

Because of an understanding of PHP, we can eliminate the following possibilities: 0 ($_GET will not cast it as a numeric variable), false (same reason, no casting), not being set (we already tested that in the circuit), NULL (can't assign it through a query string and the variable is already assigned), and Simple XML element (again, can't cast / initialize it).

There would, of course, be a disclaimer that if you allow any code to edit the $_GET variables, then these assertions no longer hold true (so it is important to rescan the entire project before each deployment).

Boiled down to English, it would say "If the server's doesn't get an id parameter (which would be specified by the person accessing the site regardless of any restrictions you impost), "Worst case!" is output, if they specified 0, false, or said they were sending an id and sent nothing, it will output "Ohh no!", otherwise it will output "Hello World".

But how would that translate to something that replaces unit tests?

You see, the problem with unit tests is the person making them. A Unit test that tries "true" and "false" as parameters has partial coverage.

What if they pass "no"? That gets treated as true. You could end up looking at a report about "Do you like cookies?", see that the user responded "No", but the system counted them as someone who indeed likes cookies. Terrible! The horror! The humanity!

It doesn't stop there!

The same way you can see that the smart contract has different child smart contracts, with different interfaces, and variables, and make sense of them, we can make sense of compiled code too!

At first, it might say "keyboard input right key increases variable by 3". Later, it can learn that the variable means world position and update "moves character in the virtual world by 3 units". Eventually, after a few passes, you have a better commented version of the source code than the company that wouldn't release it!

Don't concede to technology because you watched Lie to Me and fear its debugging capabilities.

Make technology fear yours!