[SERVICE] Blockrand: Double-Blind Randomness (Show HN #1) for Dice/Crash/Games

[dewez]

The high-trust toggle is probably the way to go...

that makes the alternative (aka the normal mode) "lower" trust in anyones mind..

[rishib]

Hi @ralle14, thanks for the candid feedback.

You're 100% right on UX—speed is king for casuals. But for the "Big Fish," the psychology shifts.

Think of it like Bitcoin confirmations. No one waits for 3-conf to buy a coffee, but you’d never accept a $50k deposit on 0-conf. Our goal isn't to replace the instant "standard" mode, but to provide a High-Trust Toggle for whales who prioritize adversarial certainty over a 10s wait.

It’s not about scrapping the system; it’s about offering an "Institutional Grade" option for the 1% of players who drive the most volume.

Dropping by as well as a form of response to the PM I got from OP.

After checking it out, i'm not sold on the solution becoming the new standard because the added time might not be a welcoming change for most users. The high-trust toggle is probably the way to go when casinos might not be willing to scrap their current system, and better to meet them in the middle instead of trying to scrap everything. Don't get me wrong, I still like it, but for the casinos, it's just that the solution feels like a sidegrade because it's aimed at specific users instead of the majority. The external verifier badge should help, though I doubt it'll be significant enough for whales to stay when other casinos used to have something similar, with the help of their communities.

[rishib]

Is Lightning 'less' than Bitcoin? In terms of finality, yes. But we use it every day because it's fast. I view current PF as the Lightning of gambling—optimized for speed. Blockrand is the Mainnet settlement for the bets that actually matter.

The high-trust toggle is probably the way to go...

that makes the alternative (aka the normal mode) "lower" trust in anyones mind..

[NotATether]

So, I've only had a cursory look at the codebase for now. When my schedule allows me, I will have a more thorough look later. But one thing I want to comment on right now is that I like the idea of calculating an external hash from network data. As long as the network is large and decentralized enough, this will usually result in a fair system if the result is used correctly, and is actually how some people conduct giveaways on Bitcointalk.

[dewez]

So, I've only had a cursory look at the codebase for now. When my schedule allows me, I will have a more thorough look later. But one thing I want to comment on right now is that I like the idea of calculating an external hash from network data. As long as the network is large and decentralized enough, this will usually result in a fair system if the result is used correctly, and is actually how some people conduct giveaways on Bitcointalk.

of course- we all do... but there are issues:

1. it’s harder to understand, and it expands the trust circle.
2. it's harder to give users an offline verification tool.
3. no "commitment ceremony" exists like the hashed server seed they hold in their hands.
4. no lever of control like the client seed, which has direct impact on system.
5. its not without doubt.. "miners can control the outcome".
6. decentralized is great but its NOT local and not 100%-- blocks get fucked up all the time.
7. surface area for attack increases.
8. some casino will give it a bad name by not using the hashes correctly and effectivly cheat.
9. MOST important: the casino operator now has to TRUST SOMEONE ELSE, when before they knew their system was 100% legit.
** i know most people are used to this feeling, they have their trust spread out all over town in third party tools. but i'm a builder and L0TT0 is 100% inhouse code which allows us to TRUST our system and the tools we give our users to verify it.

any IOU loses its power if its not written down before it's paid- it doesnt matter who is backing it.

there is something very powerful in PF systems with the server seed hash promise and the tool to reset it with the client seed.

[NotATether]

@dewez, those are all valid points. I should mention that using blockchain data for creating commitments has applications beyond casinos. For example, a few weeks ago, I finished creating a hash system for a raffle website. It collects thousands of block hashes within a given time frame and hashes them sequentially with SHA256, for winner selection purposes.

If you use thousands of sequential hashes, you eliminate the malicious actor problem because nobody can collide to mine so many blocks in a row.

If you think about it, all probably fair games and events come from a hash. They just process it differently. Like some take it mod 2, mod 10, mod 100, etc.

[dewez]

@dewez, those are all valid points. I should mention that using blockchain data for creating commitments has applications beyond casinos. For example, a few weeks ago, I finished creating a hash system for a raffle website. It collects thousands of block hashes within a given time frame and hashes them sequentially with SHA256, for winner selection purposes.

If you use thousands of sequential hashes, you eliminate the malicious actor problem because nobody can collide to mine so many blocks in a row.

If you think about it, all probably fair games and events come from a hash. They just process it differently. Like some take it mod 2, mod 10, mod 100, etc.

yeah, but having a ‘legit’ hash at the start doesn’t automatically mean the final RNG output is legit. a lot of implementations ruin it in the last step — they turn the hash into an integer, then just take the first/last digits or do a quick modulo and call it random. that throws away most of the entropy and can introduce bias. if you want the cryptography benefits, you need a proper extraction method (rejection sampling / chunking bytes) so every outcome is uniformly reachable — not ‘eat a few digits off the front’ and hope for the best... IE mod 2, mod 10, mod 100 could lead to this.

example:

one byte = 0–255 (256 values)

256 % 10 ≠ 0

so byte % 10 makes some numbers appear 26 times and others 25 times

that’s bias.