Live data from Hacker News

Show HN: Peer-to-peer mini r/place with Proof of Work

tropical.pages.dev

11–20 of 50 posts

Re: Show HN: Peer-to-peer mini r/place with Proof of Work

#11
post #5

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…

Something like that or quadratic voting scheme and incentivize curators.

Re: Show HN: Peer-to-peer mini r/place with Proof of Work

#12
Well this site got me to write my first ever C program to generate low hashes, and by the time I get it working, I go back to the site to learn that the lowest hash now starts with 10 zeros. (!)

I don't think my lowly little Mac CPU will ever compete with that.

But hey. First C program.

Re: Show HN: Peer-to-peer mini r/place with Proof of Work

#13

Well this site got me to write my first ever C program to generate low hashes, and by the time I get it working, I go back to the site to learn that the lowest hash now starts with 10 zeros. (!) I don't think my lowly little Mac CPU will ever compete with that. But hey. First C program.

If you repurpose your program for finding grid pixels, you can still beat just about everyone else ;)

Re: Show HN: Peer-to-peer mini r/place with Proof of Work

#14
post #9

Earlier quoted context omitted.

Agreed. 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,…

You 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.

True, 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!
Post reply on HN