Actually I do not think it is easy to solve, if at all. First of all before Parsec there was a need for decentralised RNG just to make protocol work. As far as I know, Parsec will not help with that.
There has to be some way to poll the network for things like getting a new wallet address. So, request 3 new addresses, XOR two together, append the third as a salt for a 512-bit hash. Mod the hash with your number range to get your random number.
That is not decentralised random number. decentralized random number generator generates random numbers that others can verify. So it needs Id of roll, and value for that roll. yes you can create random numbers easily, but for casino you need global trusted generator, where both users and casino operators don’t know and can’t manipulate next roll. Users will bet and than global RNG will generate roll. Everyone can verify whether that bet was winning or losing. Nobody can cheat.
Maybe creating a new (type of) mutable data ‘chunk’, with one or more ‘random data’-fields.
When storing this chunk, the section/group responsible for it, could write a random value to each of these fields.
This random values could be generated with similar techniques like the Parsec concrete coin.
If you (or other clients) then read this MD again, you have the random data. Of course you should not be able to overwrite these ‘random data’-fields as client. The versioning of the MD could help here.
You could use a commit/reveal scheme for randomness, similar to what’s used in FunFair’s fate channels. https://funfair.io/randomness-is-a-big-deal/
They are using blockchain + smart contracts. How you want to do that on safenetwork? Blockchain makes it sure that once data are written nobody can change them. That prevents later modifications and works like a ledger. Smartcontracts manage Random number creation from all the seeds. How you want to do that on Safenetwork?
Maybe the solution is simple, owner of casino can generate random numbers in front, calculate HASH of every single random number and store them into public imutable data. Everyone can check that hash before roll in casino. When there is a roll in casino, he will publish original RND number for that HASH. This way there is no need for decentralised generator, centralised generator can be trusted too. The problem are collisions in HASH function, since finding any collisions is much easier than finding collision for defined HASH. Also random numbers generated would have to be very big, to prevent brute force attack.
Commit could be done by both parties writing to a MD then removing their write permissions. I don’t know all the details of the fate channels actually, but I don’t think it is accurate to say that the on chain contact is generating the random numbers. The numbers are generated and revealed within the channel as I understand it, so by establishing a direct connection between the host and player, perhaps something similar could be accomplished. The part that I think would be missing is the escrowing of funds into the channel.
You were right that my solution was not decentralized, hence I initially withdrew my post because I realized you were asking specifically for that. However, my method, or any number of simple methods, could be pretty easily trusted if done in front of the customer/player. People already trust that many of the online poker games are sufficiently random, and they are all closed source. I’ve never really heard of anyone claim the big name ones were trying to cheat them. After all, the casino/gaming platform gets more money in the long run by being legitimate, because they just siphon money from the Joes ad nauseam. It is in their best interest to be trusted.
If you open source your randomization method, as well as your inputs such that anyone can verify, I don’t see a problem with that. Heck, assuming you trust the SAFE network itself, just have your method be to take each current players’ public wallet addresses, appended with the casino’s public wallet address, and continuously PUT that into chunks, use the encrypted data as your new “number”, mod it with your desired range max, and voila, you have your random number. Assuming the network has a sufficiently good method for generating IV’s, there is no way to cheat the system. Everyone can verify the wallet addresses of the current players + the casino is the data contained in the chunk, make sure everyone can see the encrypted form of the data, and you have a virtually infallible random number scheme.
A curious question.
Do you guys @drehb @wydileie @Antifragile @oetyng think it will be possible in the future to have database with random numbers and some sort of server side code being executed by nodes to deliver random numbers to clients. In my head I have a vision how a casino software would be constructed for todays internet, something like: put x numbers of pre-generated prng numbers in a database, when client push (deal) button get numbers from database by the current serial number, send correct outcome back to table table id and client id.
From what I understand database in some form will be possible. @oetyng your work with event store databases seems impressive, do you have an idea of what can be possible in the future of databases on the SAFE-network?
appropriate Pseudu random number generators (PRNG) seems to be something like, Fortuna, Java’s SecureRandom or similar.
Also a relevant comment to this discussion, from stack overflow.
" Using cryptographically secure random generators only becomes important when the actual output of the random generator can be viewed directly. For example, if you were monitoring each number actually generated by the number generator - after viewing many numbers in the sequence - with a non-cryptographic generator information about that sequence can lead to establishing information about all the internal state of the generator. At this point, if you know what the algorithm looks like, you would be able to predict future numbers and that would be bad. The cryptographic generator prevents that reverse engineering back to the internal state so that predicting future numbers becomes “impossible”.
However, in the case of a casino game, you would (or should) have no visibility to the actual numbers being generated under the hood. Each time a random number is generated - say a 32-bit number - that number will be used then, for example, mod 52 for a deck shuffling algorithm…no where in that process do you have any idea what numbers were being generated by the algorithm to shuffle that deck. That is, most of the bits of “randomness” is just being thrown out and even the ones being used you have no visibility to. Therefore, no way to reverse engineer the state."
My idea as I stated above is that both parties do a commit and reveal. I think it is standard these days that the consumer plays a role in the RNG, but if you can do it in another provably fair way that’d work too.
I can see how it maybe more suited for the SAFE-network to send hash of the random numbers to client. But I didn’t know it was common for casinos to use that model, any references?
Yeah a social app ecosystem. Decorum, some sexy persona management app and solid with interoperable data formats. Could just have persona trees with a seed persona owning the data, managing sharing and privacy preferences, switch personas based on context. This ecosystem of social applications is what I see coming about. Personally I would like to see decorum become the protocol for these types of social applications. Maybe @Seneca has a similar vision?
Rather than seeing a social network in the model of the old we need to imagine and envision the new.
Very good point, and Solid offers attractive one IMO, based on the interoperability you mention, using WebID and profiles, with access control in the hands of the user by individual or group WebID. So less of a social network app, more that all your data is both social and under your sole control, and you choose the ways to view and create, post, edit, share that data (the social apps - plural, rather than a social platform that tries to keep you prisoner and feed off your data and networks like a parasite).
I am very curious about the Decorum approach to this and hope the two will work together.
It’s not clear yet how and to what extent SAFE will support Solid/RDF in the APIs and standard data structures, so it must be hard for @seneca and @bzee to know how their work so far fits with or can work with that. I imagine there’s some duplication, to say the least! But also hope that they have some additional ideas on how to manage this, and how to help developers work together to provide standards that amplify the power of SAFE network.
This one is on the hardware side. Sturdy, solar powered farming modules, that you can put up on your roof, turn on, and forget about. It would work best with unlimited citywide wifi, or mixed with some sort of a high-speed mesh network.
I admit the idea is not very fleshed out but maybe someone will do it.
This would be amazing, along similar lines if any of these satellite networks take off then as we encrypt all traffic, they can be used to connect the smaller networks together and create a new internet architecture that is much flatter and either remove or radically alter what an ISP is today.
I noticed on Sparkfun’s site that they are sell a Pi Hat that is a battery unit that charges when the Pi is powered and then acts as a battery backup unit when power is removed. They demonstrated it with a flexible solar panel that can supply 200mA @ 5v (after solar controller) in the sun. They mentioned that it would only be good for the Pi to wake up do something then sleep again. But with a larger panel then it could make the Pi run 24/7.
I hope that someone makes a business out of it. Where I live we get a lot of Sunshine and would be a good place to do it.
Also it can use wifi for the home too. Just place the units in a suitable location and they just run. Or as David said connect them together in networks.
Solar-powered satellite networks do sound intriguing but upload throughput might be problematic since SAFE Network places such importance on it.
Agree with that today, in terms of latency, but…
Can you imagine when I started thinking about safe in the early 2000’s what disk space, cpu speeds, bandwidth and hard disk access times were? This was a mantra for me for a long time, “design for tomorrow”. The notion of being fast is not always best, a car goes faster with no bumpers etc.
Even for us right now, we can imagine a database server will query small databases much faster than safe for now. This all changes though over time, so bandwith etc. increase almost exponentially. So say even bw was slow here, maybe 50% of what we need, then we just wait 13 months and it’s as good as today’s landlines, if that makes sense.
What I mean is, I think it is wise to not care about things being slow when they are growing exponentially, in fact it can be enlightening to design that way as it allows a lot of freedom that would not be there if we only designed for what we have today. I hope that makes sense? (it’s not necessarily right, it is just how I think anyway)
Oh yes, very much makes sense. “Design for tomorrow” has never been more important than today, for most every pursuit. Does make for a moving target though. I can see how the network will continue to be tweaked almost constantly after launch.