Step one is a symmetrical cardID verification between the pit boss and the trader request parameters, from you and your card. If the verification passes, the two parties are considered honest and the python interpreter is secure, so the selected trader bot is activated. The bot has exactly the money in whatever units that came with the request, no need verify betting limits, the pit boss is happy. Once end to end verified, and he intermediate secure; just assume every part is honest and verified.
Then the bots execute the pit code:
select stock in the_pit(where_my_algorithm_looks,<argTuple>)
and your algorithm is what your select, maybe a standard trading bot. Then the bot can do bid/ask up to the limit, as often as it is willing to wait inline.
Trading pit is done, but it has issued a shit load of contract fulfillments to ethereum, and that is where the bottlenecks and security will arise. Outside of the pit, there is going to be a registration between the card holder and the ethereum contracts enforcer, gobs of blockchaining.
Stock certificates need registering to a real human, truck loads of pipes need to be sent properly. These contract enforcers got great code, but they do a lot more. They go to court, they synchronize time and space, they carry the known, but significant, human error. But they can do this knowing the artificial bottlenecks are gone.
Back to the simplest model
The pit is a spreadsheet function that fits all the fulfillments into the delivery process. It is the stock boy with quantization power. But it really is just a spreadsheet function, say given two arbitrary sequences, co-compress them, find their mutual entropy.
No comments:
Post a Comment