rishi_blockrand

7 ms·

1.
by rishi_blockrand 7mo ago
Thanks to everyone who poked at the site yesterday! It provided a great stress test for the architecture (Go + Firestore + Cloud Tasks). For those interested in how a "Time-Lock" UX performs with a technical audience, here are the
2.
by rishi_blockrand 7mo ago
The reason for having a deliberate delay (10 sec here in the demo) is that I think 'the next round' (of drand for example) is a security anti-pattern. If a server sees the Drand beacon just a few milliseconds before the user'
3.
by rishi_blockrand 7mo ago
I just checked the code and it was a small demo/front-end issue of assigning the player_id (in javascript)... have corrected it now : ) The logic of back end api (written in go, commitment stored in firestore), is intact, the 409 will
4.
by rishi_blockrand 7mo ago
Spot on. By using Drand, we move from Optional Reveal to Deterministic Resolution — the result exists publicly the moment the round closes. It turns the server from a "Judge" into a "Timestamped Vault" that can't ho
5.
by rishi_blockrand 7mo ago
Exactly. For a web app where you can't easily "slash" a server for disappearing, you need that "uncontrollable third source" to force the game to finish. I looked at VDFs and custom MPCs, but they felt like overkill
6.
by rishi_blockrand 7mo ago
Great point—Schneier’s two-party protocol is the foundation... However, it suffers from the 'Last-Actor/Last-Look' problem in a client-server environment. In a standard 2-party commit-reveal, one party always learns the resul
7.
by rishi_blockrand 7mo ago
The current time (in the demo) is fixed around 10 secs, but it can be anything, minimum being 6 secs (as the fastest) Drand pulse is 3 second, and some latency buffer...
8.
by rishi_blockrand 7mo ago
Oh ok... so then thats definitely a bug then... actually drand issues randomness every 3 seconds... so may be multiple on the same drand round has a bug... will correct that... Thanks
9.
by rishi_blockrand 7mo ago
Oh yes, its only one commitment per call... this is a UI handling issue, will resolve it... the backend by design only takes one commitment per player, till it is resolved/revealed... Thanks
10.
by rishi_blockrand 7mo ago
Hmm... I have not been able to replicate that... Can u screenshot it ? Thanks for trying it out : )
11.
Show HN: Double blind entropy using Drand for verifiably fair randomness(blockrand.net)
21 points by rishi_blockrand 7mo ago|16 comments
12.
by rishi_blockrand 7mo ago
Github of the JS SDK https://github.com/blockrand-api/blockrand-js
13.
by rishi_blockrand 7mo ago
One thing I didn't emphasize enough in the post: the 10-second delay isn't just a technical limitation of Drand. It's actually the security feature. If the delay was 1ms, a server could still potentially 'front-run'
14.
by rishi_blockrand 7mo ago
Most "provably fair" games today rely on a commit-reveal model that has a subtle flaw: the server chooses its seed hash privately. This allows for a "Seed Grinding" attack where the house pre-computes millions of outcome
15.
Show HN: Why 'provably fair' RNGs aren't trust-less, and how to fix them(medium.com)
2 points by rishi_blockrand 7mo ago|3 comments
16.
Ask HN: Are "provably fair" JavaScript games trustless?
2 points by rishi_blockrand 8mo ago|0 comments
17.
by rishi_blockrand 8mo ago
Nice puzzle mechanics! I noticed you mentioned randomness is only used for the initial config. For 'Daily' style puzzles, there's always a segment of the player base that gets skeptical about whether the 'Daily Seed&#x27
18.
by rishi_blockrand 8mo ago
The non-escalating envelope approach in Firecracker is a great way to handle agent drift. I noticed you’re using HMAC approval tokens for gated ops—how are you handling the entropy source for those secrets? One edge case in agent security i
19.
by rishi_blockrand 8mo ago
Interesting choice using a Feistel cipher for format-preserving encryption here. It’s a solid step up from Hashids for preventing sequential ID discovery. I’ve been looking into the 'Integrity Gap' in HMAC systems lately—specifica
20.
by rishi_blockrand 8mo ago
One thing we’re especially unsure about is whether our double-blind commit model still holds up if one party delays reveals strategically. We modeled this, but I’d love critique from cryptography folks here.
21.
Show HN: Blockrand – Verifiable randomness API with a double-blind threat model(github.com)
1 points by rishi_blockrand 8mo ago|1 comments
22.
by rishi_blockrand 8mo ago
Both node and html versions are there to test Blockrand API with. You just run a curl command to get an API Key (instant) and then you can fire the system. Would love to get feedback on it.
23.
by rishi_blockrand 8mo ago
Hi HN, I’m Rishi, the creator of Blockrand. I built this because I noticed a recurring trust issue in web3 gaming and raffles: users often don't trust the 'house' seed, and developers struggle to implement complex commitment
24.
Show HN: Blockrand – Verifiable entropy using local secrets and Drand beacons(github.com)
1 points by rishi_blockrand 8mo ago|2 comments