scrypt jane sucks (need a lot of ram - high power usage)
Groestl algo seems to be a good choice for me or Qubit for example
This seems to be a bit of consensus here, Thank You for your input. What do you suggest be done to deter ASIC/FPGA off the GPU channel other than large memory requirements?
So, I require the
[opinion] of the community.
Wrote a Hailstone Sequence Miner, [to calculate Collatz numbers in Series], it works, difficulty too.
A] Does anyone have any other ideas of a mathematical series that can be used?
B] Should we stay with Reicoin [or maybe implement Hailstone] for the CPU channel?
I would love some
[input]So I can produce more
[output] ~Videlicet
EDIT:
reorganized slightlyI like the idea and sounds very interesting (though I'm not a mathematician). Can you give us more details on the Hailstone Sequence miner? The difficulty would be the length (steps) of the sequence? The starting number will be based on the block hash?
Hailstone series is when number is even, divide by 2. When number is odd, multiply by 3 and add 1 [ex. 6, 3, 10, 5, 16, 8, 4, 2, 1]. This series will go on until it eventually reaches 1... the unproven part of it, is that it has not been proven that infinite Hailstone series exist. This was just a starting point to get a good idea of how hard it would be to implement new CPU POW, and it is actually easier than I expected.
I have been leaning towards Goldbach's Conjecture, which states that any integer greater than two is the sum of two primes, and that any integer greater than five is the sum of three primes. This leads me to question as to the existence of four primes/so on [this could open more doorways in the future]. The reason I am leaning towards this Conjecture, is it is the core of RSA encryption, and if proven either way will impact Cryptography significantly.
As for starting point, that is a better idea to use block hash [my plan was over complicated, of course]. I am also thinking of having a secondary requirement where miner has to submit X digits of transcendental number (Phi, Pi, or E) along with the block POW. This could add some depth to the network, as the block chain could store all digits of said number [very useful to number theorists].
EDIT: Difficulty is regulated by logarithm of root, added to the difficulty value [longer series become more common as digits increase]
What do you think?
~Videlicet
OK. I'm not sure if I understand how the difficulty will be adjusted.
What I understood from wikipedia the max number of steps in a sequence is related to the size (number of digits) of the starting number, and as you wrote when the digits increase the longer series also more common. What can be problematic is when we are searching for a longer series than it's possible to achieve with the starting number.
Quote from Wiki:
The longest progression for any initial starting number less than 100 million is 63,728,127, which has 949 steps. For starting numbers less than 1 billion it is 670,617,279, with 986 steps, and for numbers less than 10 billion it is 9,780,657,630, with 1132 steps.
I didn't read the full article yet but it's also important to know the relation between the size of the starting number and the probability to find a fixed number of steps.
(Again I want to mention here that I'm not a mathematician
)
When I wrote miner a day ago, I found the the formula (root^1/3 + difficulty) worked quite well [to get average chain length per root digits]. Difficulty could then be a number (700) for starters. I then had difficulty modulation based on average block time, and time between blocks [set to 15 second target] and it ran all night with a continuous average time of 15 seconds [of course increasing the root over this time]. It seemed to be stable, but was created more as a test to how difficult it would be to implement scientifically valid POW.
The second option is to have hash be at specific target [like normal], but nNonce values to produce hash have to fall into a specific pattern [hailstone, goldbach, etc]. This will keep scientific validity, but retain hashing security. This could even have two layers of difficulty [nNonce requirement, hash target requirement].
A very intriguing concept!
Just one flaw I can think of: if CoinShield takes off, the usual suspects will change their 'business model' to deliberately creating crapcoins to dump on Coinshield. Back in the days of J.D. Rockefeller, old J.D. had the idea of monopolizing the refinery sector by buying out Standard competitors at a premium. One joker saw that he could build refineries and make a quick profit by selling into Standard's open offer. Reportedly he built three before J.P found out.
Videlicet and I have discussed this very scenario and came up with a way to prevent this from happening. The systems trade algorithm will prevent shitcoins from purposely dumping on us. I'll have Videlicet explain the details behind his code when he takes a breather from his coding session.
Thank you
~KryptoKash
This could work - but the only way to "prevent" is not by eliminating possibility, but by making the profits of such a scheme minimized. The way this can be done, would be through the channels. Let us say that coin X is verified by Coinshield Community, and coin Y clones it. Coin Y will have an exchange channel opened, because coin X community noticed the forgery. Coin Y having been newly launched will not have much value in the Coinshield Channels [because it is a case of forgery, and has no longevity as a coin]. This will deter such acts, for in order for anyone to make any sort of money with such a scheme, they would need to make an innovative coin [in order to survive forgery scrutiny, build a value, then destroy with profits]. This is the expense for profits, for why would anyone spend time to innovate just to petition their own destruction? [let alone be able to convince the community that this innovation needs to die].
As a community we can work together to create an environment of decency, respect, and quality.
EDIT:
slight restructuring / rewording after last proofread~Videlicet