for "asic" resistance,
I have been toying with the idea of being able to use some of the undocumented registers in the processors that date back to the early 90's, and were present in everything from intel to cyrix processors...
Some of them have finally had documentation in past years revealed, to which they were encryption functions (AES?) built-into the die. My guess would most likely be government in origin. I would not be surprised that if one of them is for decoding GPS encryption (military accuracy). You can load the memory with your data, call the register, then read out the change and use for your algo.
Now; the downside is they were created, so they were documented somewhere... which gives an insiders edge.
But requiring the mining device to basically have a complex PC built in (remember, x86, not ARM, etc)... it would kill the product cost of an ASIC to be able to hash more advanced functions like this.
Using the timer and clock of the x86 CPU, as a part of the algo running outside the x86 CPU (see where this is going?) You can now add a fixed time clock based on overall ticks or based on increments of ticks and memory values, etc. to the algo.
Ive been trying to find a reasonable way to lock time to the mining algo in a way that you can't simply implement a fixed or known time variable. It would need to have something to do with the network, such as how many TX in mempool, size of mempool, time since last block(s), last valid high (but not 100%) value share to the network, a consensus reply from the network, etc etc etc. You could build in better block controls that will take out the randomness of nethash spikes, nethash decreases, etc. Built in countermeasures that aren't related on the speed of a calculation are key to leveling the playing field.
Make it reward effort, not greed.
I wonder if these registers could be used with wallet addresses, locally generated OTP from a hardware based device (like a yubikey), and a token from the pool such that a new token was generated that is time or share count limited (i.e.: valid for a specific amount of time OR a fixed number shares)? When submitting a share, the miner would need to pass the share's hash plus the token through the register, and then submit that hash to the pool.
If the share submitted in that way exceeds either the time-limit or share count limit of the token, then the share is rejected.
When the time or share count of the current token is reached it triggers a "renegotiation" to obtain a new token. The new token would have potentially new limits that have been adjusted to the performance characteristics of the mining hardware.
...... to Answer > YES !!!!!!
