How to best the Bitcoin cryptocurrency lotto;

A hi-speed box is prerequisite; emphasis on read/write speeds on duel 4T SSDs. 32 GB Hi speed RAM; overclocked Core I5 12600 or Core I7 22700. I estimated 32 or 64 units…

An ASIC is a circuit that provides a hash value that (critically) BEGINS with &h0000. Time to calculate/randomly poll for these is the intractable problem.

Example: When you play TX lotto, EVERY entry has same probability. Buuut; if you play A SINGLE unique entry repeatedly, it has the same probability the FIRST time. However, thereafter, the winning solution becomes constrained to be x + (n) / total possible. Since the requirement to win BECOMES x2 AND ~x1. Else the entry would have won before. 

While this is statistically insignificant, we can capitalize within the cryptomining protocol.

After completing a bid, whether successful or unsuccessful instead of discarding the HASH, we can proceed to play the same number again. Starting with &h0000, and hashing once per round, as prescribed.

But to improve our strategy, we save 2 terabytes of old ASIC HASHES… per unit.

Now, when  the lotto begins, we prepend the first entry (from a write protected file) with one; perform the required hashing operation, and SAVE IT to a newly accumulating file.

As none succeed, we supply MANY more entries, not having to await our ASIC to develop them. 

Often enough, our datafile may be exhausted, or rules may require beginning again with the hashing operation executed TWICE. 

Here, we select our newly accumulated file, hash these ONCE, and submit them again, not failing to accumulate these twice hashed entries in a third datafile.

2GB data x three instances is 6GB, well within the capacity of dual 4T drives.

When needed, we delete our n-times hashed datafile, and use the disk space to build a new one, hashing once between efforts, as the lotto progresses.

This procedure needs to be right-sized by proper knowledge of the brute force probabilities, but it cannot fail to yield successful cryptocurrency coins.

Comments

Post a Comment

Popular posts from this blog

A "Secure" OS made PRACTICAL

I can remember suggesting a theoretical Operating System that requires object code to be compiled in such a way that a decryption key is required for a program object to execute. The program object itself would execute unencrypted in RAM.  I cannot find the entry at the moment, but I have also suggested an OS that uses an RSA key for program installation. Separately, I have contemplated a Linux user, organized such that the encrypted home folder appeared as an UNMOUNTED container over IP, while operating as a MOUNTED container locally, for the profile user. This would defeat some purposes of SSH, but would harden the installation against data theft over IP.  Now, with the development of an offline username/password for a program, I am asking myself if I cannot effectively suggest a practical (as opposed to theoretical) arrangement, whereby the program presents a credential (or two - username/password) to the OS, for permission to execute. Clearly, multiple program objects w...
Read more

DRM and Password Authorization

We log in online and are accustomed to being refused service if we supply an incorrect username/password combination.  We persecute "plain-text offenders" and rightly expect to benefit from comparing a hash fingerprint of the credential presented online to a list of hash fingerprints, each paired with a username. Even better if the username is hashed as well. The knowledge gained from online handshakes can benefit us in digital rights management.  It has long been the case that we could obfuscate a password literal in source code by compiling it into object code. However, decompilers provide assembler code that can reconstruct the source code without descriptive variable names and make string values stand out. Now, we can construct a creative solution. We can designate a username/password combination to COMPILE SOURCE UNIQUELY FOR EACH USER. To hide it in the object code, we hash the username and password with a published hash algorithm and use the hash-fingerprint literal in...
Read more

A Simple Open DRM

We love to hate DRM, because we associate it with degraded quality or loss of data control. Sometimes we associate it with loss of privacy when we register.  Here is a formative "Open DRM." The kernel of the system is going to be the idea that a salted hash is a member of a class of some kind. If I start with a MEMBER md5 hash and run 200,000 iterations of the correct salt, I hit a control value predictably.  The potential problem arises not from providing 199,999 different possible keys, but from providing a registered customer with his own valid replacement, on that rare occasion when he proves he has purchased it, and we must re-present his original key. Standing behind the warranty is what makes us reputable. To preserve his privacy AND the security of our system, we do not want to store the enumerated value on the server.  However, we can reasonably suppose that we can manage to keep a secret value secure. I propose that the DBM or LLC choose a passphrase of some kin...
Read more