His mining algorithm has a flaw he does not see. When time permits, I may post on his altcoin’s development thread with advice for miners who want to exploit it. The discussion is off-topic on this thread; I will delete further posts about it.
2) A miner could "game the system" by generating a specific char for last position along with the required PoW, though this would require an extra bit of work over non-bad actors.
If you are not generating whatever "random" item publicly, the miners will not know that changing the block header will create any advantage.What he is actually doing is arguably even worse than that.
Since you don't wish further posts on this.
The dreadful result of someone exploiting this obvious flaw you mention is that the Nfactor for the block is going to be 18 instead of, let's say 20.
No, the dreadful result is that your chain tip will be unstable. You are giving miners an incentive to build only on blocks that require the next block to use an Nfactor of 18; but you are also giving miners an incentive to broadcast any block they find. You are also giving miners with significant % of hashrate an incentive to withhold any blocks they find that require the next block to use an Nfactor of 18, build on that in secret, and then broadcast the result.
The ultimate result will be many orphans and reorgs, and a chain that messily converges on having mostly or only blocks that require the next block to use an Nfactor of 18. If your coin ever has enough value to attract an ASIC designer, then the ASIC will probably do Nfactor = 18 only, and still dominate the network; so I guess that this has the benefit of being ASIC-friendly.
- Give up, and use urandom. Not from laziness, but from sufficient wisdom not to shoot myself in the foot.
This is what i would do (even as regular user). But what if your software is browser-based or available on multiple platform? Do you just say it's user risks for not using Linux?
Thanks for the link; I had not seen that thread. Some of the posts there invited a Nullian rant which is yet unfinished...
Summary: We went to sleep, and dreamt of a universal platform. We awoke in a nightmare where the universal platform is the web browser, the universal language is Javascript, the universal ISA is Webasm—and the morals of youths have been corrupted so that they promiscuously run network-loaded executable code from random strangers as a lifestyle. I want to kill myself, or at least take up a hobby of severe alcoholism.
There are no good ways of dealing with this. How can one mitigate the horrors? If I were developing a web app that needed to generate secrets inside the browser, then I would start by reviewing the major browsers’ implementations of crypto.getRandomValues(). Then, I would hope that the “move fast and break things” browser developers don’t change it, accidentally or on purpose. —Then, I would take a strong drink and/or shoot myself in the head.
As for other platforms: Every major OS offers an API for obtaining randomness. Use it. If it is bad, use a different OS.
A much bigger problem nowadays is an OS running inside of a VM. A hypervisor must offer a hypercall for obtaining randomness from code that runs “on the metal”, and a guest OS must use it. Otherwise, the guest OS kernel has the same problem as any application running in userland: It lacks sufficient hardware access to measure nondeterministic inputs. Another big problem is, of course, embedded devices... sigh.
The good news is that you only need to obtain a 256-bit random seed. If you have a 256-bit secure seed, then you can expand it to as much “randomness” as you may desire. That is what BIP 32 does! It is cryptographically secure; and there are good ways of doing this for any application, including applications that require forward secrecy. The focus of my OP here was about extracting randomness into a secure seed, not about what to do after that.
As long as the purpose of generating random numbers is to use them as seeds to electronic signature algorithms like RSA, ECDSA, Schnorr, etc., what matters is not pure mathematical/philosophical concept of security, because the ESA itself is not purely and information theoretically secure! Comparing the two APIs provided by unix like kernels, the myth gives more credit to /dev/random because of its inherent more guaranteed entropy.
This reflects the beginning of OP here, and also an essay that I have been intending to write for the Ivory Tower... We do not live in the physical world. The real world, the crypto world, is a world of numbers and computations, where all attackers are computationally bounded.
You behave accordingly, when you generate a Hierarchical Deterministic wallet with BIP 32: It is computationally pseudorandom, and thus secure against a computationally bounded attacker.
In this context, people who obsess about “information-theoretic security” have no idea what they are talking about.
(N.b. that the whole Linuxland argument looks very foolish to me. On my BSD systems, /dev/urandom is a symlink to /dev/random; and /dev/random behaves more or less similarly to urandom on a Linux system, except for some extra safety features at boot time when the system hasn’t yet been able to seed the random generator. In my opinion, Linux should do the same thing.)
The dreadful result of someone exploiting this obvious flaw you mention is that the Nfactor for the block is going to be 18 instead of, let's say 20. But thanks for your educated and truly useful response. 
