Tuesday, October 25, 2016

How the bots do code verification

Bots, in general, execute a standard verification exchange, peer to peer, between smart cards.  On the

AI web,here is how its works:
Some site has published,and installed graph operators for its betting array. You like he site, want to se up automatic trading.  The pe-installed graph operators are smippets, likely small python codes, more like programs w used for the old programmable calculators.  They arr a small, verifiable operator descending finite spanning graph.

Likely very safe operators, but you want  your card check anyway. It can grab the snippet from the site, it is read, not writeable.  But once your bot grabs a copy,send it to me, my code verification site, it will match that snippet against the site published rule book and generate a red or green flash.  I will charge you, but compared to the $100 per year you pay me for the card, its chicken feed.

But what is a Python snippet?
Nothing more than a compact graph, linear layout, nested blocks marked by tab counts, exactly what the plan is anyway. We are all arriving at the same spot on this. So consider code verification as a finite graph convolution between the site rules and th code snippet.  My graph operator uses a pseudo linear measuer locally,meaning it is forcing significance.  The linear measure is the  boundednes of the code descending the graph.  That boundedness, being pseudo linear, makes your light move from red to yellow to green and back.  But, you see, the most popular site will expose well bounded operators because your trade finishes quickly, you are not tuck in the graph, waiting for cycles on the graph.

The Redneck debugger seems critical to me. It is becoming a sophisticated tap machine, and that ultimately verifies the code verifier. The ability to efficiently detect near bound conditions in real timr, stop, on a separate thread, have your real time analyzed python code take a look.  But the graph operators are highly recursive, multi-threaded ultimately, and they are one last test of the trap machine.  I am stuck working both, so the graph work will be a simple test and simulate, mainly to test the debugger.

We need from Python

We need a secure setting for the traps, a mechanism by which a smart card can verify that no traps are being set. That will be the last open door. The interpreter will need to engage in a verification exchange, and bots can detect the smart card that activated the interpreter.
Ultimately we even want microprocessors to have a verification internal which can identify the appropriate smart card  in charge. Give it a pin on the chip, make it lead to an actual button a human has to push. tap with a smart card. The button enables code verification requests. The micro processor the  store a non-essentail encryption key which can be used t return check sums on code. Checksums to be compared against a published list.

No comments: