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

Hi HN,

This is a site where users can submit content and the shortest SHA256 value of nonce+content among them will make the site display the content. Very basic, without a blockchain. It's a static site with WebRTC and peer-to-peer.

Why? I wanted r/place (Reddit canvas where users collaborate on a pixel grid), but with proof of work. This is my progress so far. It's a WebRTC app with peer to peer connectivity that forwards the best hashed values to other users, which verify them, display them and pass them on.

There are many many improvements to be done (especially I should probably use something like libp2p-gossipsub, otherwise scale is probably an issue) and more ideas to be implemented, and I'm sure there are bugs. But I didn't find any similar projects yet (except blockchains of course).

Hope you like it!

Show HN: Peer-to-peer mini r/place with Proof of Work
tropical.pages.dev

Cloudflare now uses PoW (among other things) for their captchas[0]

[0] https://blog.cloudflare.com/turnstile-ga

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.

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, both the challenger and incumbent hashes are subject to the operation H 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!

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.