Posts

Showing posts from February, 2022

An Improvement To The Three Second Hold Rule

The rule that a broker has to hold a share for three (3) seconds, or one hundred shares for three hundred (300) seconds, can be improved. Brokers wishing to game the system will simply proliferate buy orders, and hold multiple buys of consolidated numbers of shares for three (3) seconds. To limit this, each broker could be limited to one buy per second. In this way, if he wishes to invest in 60 companies, he will have to use 60 seconds to put the buy orders in. If he wished to buy 1,000,000 shares, but only wishes to hold them for 1000 seconds ( 16.6 minutes,) he would be forced to put in 1000 buys of 1000 shares each. This process would force him to use 16.6 minutes in the buy process, after which each individual buy would be ready to sell in 50 minutes.  Computer programs written to optimize time to hold v time to buy would be forced to keep track of all the buy orders.  An alternative would be to attempt to consolidate all buy orders, but this is game-able by a round robin process o

Linux can lead in reviving competition

Operating Systems can benefit from encryption even without encrypted computing. Encrypted computing has been described. Hollywood is aware that bootlegging can be minimized by encrypting separately for every digital projector.  This could work for MP3's as well. CD rippers would have to be modified to accept a user account encryption key with a distinct rip for every instance of an installed OS. Legacy CD's themselves would not be affected. Later, each CD might have it's own decryption key, but that leads to users needing extensive key-rings, with a unique key for any of 50 or more CD's. MP3's purchased online could be encrypted by the vendor. We also theorize that computer OS's can be made harder to steal, if each copy of the OS has it's own unique key. Microsoft already has an authentication key, but it does not encrypt the distributed copy with it.  Business solves a problem when it encrypts separately for every user, but the problem of bootlegging is onl

Casino Game (Update 02/02/2022)

Driving foot traffic at a Casino requires activity and intensity. For a number to be a lot of fun to factor, it can take up to 12 hrs to run 6000 ECM curves on a 6 core computer running at 4.5 GHz.   Main problem: Casino Games run 15 minutes - 6000 curves can take up to 12 hrs on 6 cores at 4.5 GHz. 12 hrs is 43200 seconds * 6 cores is 259,200 core seconds. Divided by 6 computers * 6 cores each = 259,200 / 48 cores = 5400 seconds, or 90 minutes. Big improvement, but still not gambling. It is mathematically trivial to distribute the processing among the computer cores, but as a programming problem, this would be a project in itself. The game cannot be played as I first envisioned - a majority of numbers go to SIQS for a guaranteed solution. In experimentation, I have been able to observe the following. It takes time to roll 5 (ten sided dice) 20 times and enter the number. I compensate by rolling 5 dice again at substituting them at the end... how can this accommodate competitors gam