4 ms·
The one problem with this approach is that it gives one guy with a big GPU (or even an ASIC) a huge advantage over "casual" users (e.g. mobile web). You could p
by Retr0id 3y ago
The one problem with this approach is that it gives one guy with a big GPU (or even an ASIC) a huge advantage over "casual" users (e.g. mobile web). You could perhaps make the gap smaller by using one of the "ASIC-resistant" mining algorithms?
By the way, for making more efficient mining algorithms, it would be nicer if the nonce is on the end of the message, aligned to a sha256 block. As is, it encourages someone to set the real nonce to a fixed value, and append their own garbage (for the text message version at least, I suppose for the other formats it doesn't matter).
Edit: it would appear that your current mining algorithm is pretty inefficient. I seemingly managed to out-hash everyone with just 32 leading zeroes, taking a few Python-CPU-minutes to find. To cement my place further, I spent a few GPU-minutes to find 40 leading zeroes.
The current "best hash in grid" has 28 leading zeroes. If we pessimistically take that as the average, and there are 2^10 pixels, it would take 2^38 work to flood the whole grid right now. If I spent my GPU-minutes on grid pixels rather than the text, I could have flooded the grid 4 times over.
- quickthrower2 3y agoMake each pixel a millennium prize solution.
- bingogarden 3y agoIt doesn't help to use a fixed nonce and append garbage. The data never exceeds 512 bits (SHA256 block size), because the text has a max length.
- alwayslikethis 3y agoMonero imo has the best solution for that. Their hashing algorithm RandomX requires a ton of memory access which significantly hampers the possibility of using GPUs or ASICs for mining, favoring CPUs accessible to the common person.
- ericbarrett 3y agoAgreed. I have another suggestion, which would require continuous investment of compute and (hopefully) not make things too much more complex: Every N seconds, publish a "generation" string, randomly generated. This string must be prefixed to the nonce of the winner of the contest for [marquee, color, grid square]. When performing the "winner test" for new submissions, before the comparison to find out which is less, both the challenger and incumbent hashes are subject to the operation H << M where H is the hash and M is the age of their generation string (current = 0, previous = 1, second-previous = 2, etc.). This means incumbents weaken over time unless the incumbent's submitter continues to defend them by brute-forcing with newer published generation strings. Since the hash (SHA256) is 256 bits, you'd need to keep 256 previous generation strings, and this could get a bit expensive for testing new submissions. But computers are pretty fast nowadays!
- Retr0id 3y agoYou can do it statelessly by just adding a timestamp, i.e. msg||timestamp||nonce Clients can reject timestamps from the future outright, and for the rest, apply a decay function based on age, prior to comparison.
- ericbarrett 3y agoTrue, it’s nicely stateless, but it does allow precomputation. E.g. you could spend a few weeks doing PoW for a future date and submit when you reach it. Whether that’s a problem is a matter of taste!
- deleted 3y ago[deleted]
- pyinstallwoes 3y agoSomething like that or quadratic voting scheme and incentivize curators.
- mrb 3y agoSorry Retr0id I took your spot ;) It's a fun little game, turbidimeter! Request: it would be nice if the page showed the history for the best winning texts and their hashes. I don't know what the hash or string was before Retr0id overwrote it with his winning entry. For the curious: 0000000000f2b100124723856e7b19f92db367453f8939b3b3aace655a81d488 was the hash of the winning text "Retr0id was here" as of ~30 minutes ago 0000000000d98482cd72551c39c0233243a4878672039348417aaf69143d8d65 is now mine for "m at zorinaq dot com wins" this took about 2**40 SHA256 operations to find. I used to have a GPU farm for Bitcoin mining back in the day... which would have been perfect compute hardware for this game, but I am ashamed to admit I do not have any GPUs anymore. So I had to fall back to writing a quick multithreaded Python script and ran it on 3 machines (22 CPU cores total) while I was having dinner.