Proof isn't always possible

I speculated in my last article that using cryptocurrency in gaming would improve the gaming experience by making allocation of computer resources strategic. By application, each unit of crypto would be "backed," by the plane or tank purchased with it. It is worth speculating about the following complicating factors:  As you mine, and (for example) pay soldiers, you accumulate more currency than materiel. An available decision to add, is whether or not, or possibly at what time to " fork " the cryptocurrency, and stop accepting new coins. Soldier's pay might be lost to the game, if there is no economy for the soldiers to expend it on. If they buy food, it is perishable, but some currency might be preserved by building restaurants, or having service industry staff buy televisions, phones, and stereos. Meanwhile, Soldiers might pay for uniforms, and boots, if they are not provided by their "government."  If I were designing this, I could contrive Rock co...

I have written the University of Michigan with an idea to improve the experience of computer gaming, because they were hosting a Convention on "Meaningful Play." Simply put, replace chopping wood, mining for gold, or turn based/time based monetary accumulation with an Etherium Cryptocurrency Blockchain, and Ether mining. This could introduce market forces into Wargames, and other worlds/universes. Further, since allocation of resources influences strategy in a game,  splitting the resources of the CPU and/or GPU over more activities could make gaming more fun.   Ether is better than Bitcoin, because it has a convenient computational complexity per unit.

Students of Mathematics are familiar with Erasthmus' Sieve. 2     x 3          x                4       x 5               x 6     x     x 7 8     x 9          x 10       x          x 11 12     x     x 13 14     x 15          x     x 16     x 17 18     x     x 19 20     x          x 21          x 22     x 23 First, we strike all multiples of 2 up to the square root (5.) Then all multiples of 3, then all multiples of 5, etc. I wrote a digital implementation of the Sieve, and used the index cr...

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 ...

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...

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...

I previously wrote that I was unable to reproduce the lossy Vigenere that I learned from a book by a forgotten German author. I have now been able to recapture the lossy version, and a way to salt the grid, which the German author called a "seed." To build the unsalted grid, write the alphabet across the top without the "Z," so as to build a 25 x 25 grid. To fill the grid, start with "A," and increment through "Y," and begin the next line with a "Z," such that it displaces the line to the right. I chose the message, "THE QUICK RED FOX JUMPS OVER THE LAZY BROWN DOG." Underneath it, I repeated the password: PASSWORD. To encrypt, I chose the row with the plaintext character, and chose the column of the key character, or plainchar DOWN, keychar ACROSS. For a "Z" I merely insert a "Z." This yields the ciphertext:  THE QUICK RED FOX JUMPS OVER PAS SWORD PAS SWO RDPAS SWOR WTO CCGPT YWP NIR IJDLA EBKA THE LAZY BRO...