Author Topic: Need for a responsive RNG server  (Read 4090 times)

0 Members and 1 Guest are viewing this topic.

Offline bytemaster

With pipelining you can get a new random number every block. Assuming the bod has high up time as expected.


Sent from my iPhone using Tapatalk
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
Yes, 10 second interval is what I was thinking.  10-15 seconds as max time.  Even with modern internet gaming systems there are usually delays in action.  10-15 seconds is far better than 30 seconds +.
I think if you can get a RNG available within 10-15 seconds of request that meets all requirements you have a working solution given what I think to be needed.

I had read your paper before.  Section 8 is the part I am really interested in.  If you looking at which part to improve next, then go with # 8.

I'm still wrapping my head around everything in the lotto thread.  I don't quite understand all of it, but my early impression is that..

1) Do not rely heavily on which range of random numbers means a win.  This can vary hugely in any game.   If you put your lotto #s into your game-theory type calculations for possible exploits, it will hurt your solution for those who wish to use a more general case.
2) Relying on a singular trustee is no more or less centralized than my solution, but my solution can provide responsiveness by not having random number requests broadcast.

(I don't quite get who watches the trustee... If someone can explain that.. ??)

I like your responsiveness :) and willingness to exchange ideas.  I am not sure if this will attract any other devs, but the lotto case is a special case that avoids a lot of problems your typical gaming application might require.  I am just trying to push you guys into providing blockchain API type stuff that fits a more generalized gaming platform.
« Last Edit: April 13, 2014, 09:12:38 am by gamey »
I speak for myself and only myself.

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
no, the random # is not decided by any player of BOD, it is depend on all the secrets of the BOD, if at least one of them are honest, others can not hack on it.

来自我的 GT-N7100 上的 Tapatalk

BOD = board of directors. 

If this is the case then this might work, but I do not understand how 1 honest BOD member could keep away theft without being involved in every single RNG.

At some point the process becomes so complex that auditing also becomes complex and few will ever be able to follow the audit trail to their satisfaction.

Please refer this https://bitsharestalk.org/index.php?topic=3891.msg50047#msg50047
And I have a summary of this in the lotto design document, Section 5.0.
https://docs.google.com/document/d/1KkaAnuM0a_YU2yMaeDSDiyNUv96c9TrYrCjKadC01yA/edit?usp=sharing

I'm thinking your requirement of responsive...
Actually I think that it can be achieved if the random # demand is limited in some interval, for a 10s interval block chain, there could be thousands of random # genereated in one block, 10s is only the update time to provide more random #s, like a producer-consumer model, and maybe the RNG chain is smart enough to balance generation speed according to this.
« Last Edit: April 13, 2014, 03:27:52 am by HackFisher »
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
Where is lotto subforum ?
I speak for myself and only myself.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Look at the discussions in the lotto subforum, it's surprisingly simple

Sent from my SCH-I535 using Tapatalk

Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
no, the random # is not decided by any player of BOD, it is depend on all the secrets of the BOD, if at least one of them are honest, others can not hack on it.

来自我的 GT-N7100 上的 Tapatalk

BOD = board of directors. 

If this is the case then this might work, but I do not understand how 1 honest BOD member could keep away theft without being involved in every single RNG.

At some point the process becomes so complex that auditing also becomes complex and few will ever be able to follow the audit trail to their satisfaction.
I speak for myself and only myself.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
For the #2 requirement of various interval, RNG hosts could go on in a side chain, if the main chain's interval is too big.

来自我的 GT-N7100 上的 Tapatalk

You could perhaps make a blockchain that has 10 second confirms and have it fit in with a lot of interactive games.  The problem is that this opens up the attack if 2 people are using the same #.   Random numbers can not overlap between players.

Perhaps a player could opt-in to the process and thus on the new block be given their own random # as part of the block transaction.

So say player A is playing a game.  They make a request to have a random # for their address on the next blockchain.  THen whatever mines that block will put in a random # for that gaming address. 

The person who is mining the block can not be known ahead of time.  So depending on how the low latency blockchain works, this could be possible.  I'd be afraid of too much network traffic if every random # request is broadcast.
I speak for myself and only myself.

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
no, the random # is not decided by any player of BOD, it is depend on all the secrets of the BOD, if at least one of them are honest, others can not hack on it.

来自我的 GT-N7100 上的 Tapatalk

Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
With DPOS, how about BOD from 100 delegates as RNG hosts? this is not that centralized, and can provide quick responsive as you wish.

What we need is high quality employee/miners of the DAC to keep quick responsive and 99% uptime, that is what BOD have and DPOS want to solve.

来自我的 GT-N7100 上的 Tapatalk

100 delegates would not work if any 1 delegate decides the random number.  It would make gaming DACs susceptible to hacks by 100 people.  A single person controlling the the RNG host would be preferable over 100.

Although there might be something here in that you could use the seed from a random number of delegates.  It has to be designed in such a way that the # of malicious actors required to rig the RNG is large.  Basically there needs to be an incentive for all trustees to try and be part of the RNG.  They need to be paid for every random number introduction.  Unfortunately this doesn't necessarily scale that well, but thats a problem down the road.

So I could see the 100 delegate system actually being able to create a consensus.  There is already this "inner-circle" level of trust to an extent so the more complex problems of finding a consensus might actually be considerably easier.

Unfortunately this isn't understood as well as a blockchain and works against making it auditable in a way reasonably intelligent people can understand.   Having a bunch of guys come up with the random # isn't quite as inspiring as seeing it created by the blockchain.

A lot can be mitigated by betting limits being kept reasonable.
I speak for myself and only myself.

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
For the #2 requirement of various interval, RNG hosts could go on in a side chain, if the main chain's interval is too big.

来自我的 GT-N7100 上的 Tapatalk
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
With DPOS, how about BOD from 100 delegates as RNG hosts? this is not that centralized, and can provide quick responsive as you wish.

What we need is high quality employee/miners of the DAC to keep quick responsive and 99% uptime, that is what BOD have and DPOS want to solve.

来自我的 GT-N7100 上的 Tapatalk
« Last Edit: April 13, 2014, 01:46:35 am by HackFisher »
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
All gaming requires RNGs if there is any form of incomplete information.   All wagering games require incomplete information.  (Otherwise there is nothing to wager on).  If anyone is curious why you can't just use a block hash as RNG the problem is timing.  While the first random # can be used off the hash, you can't get a 2nd unknown RNG until a new hash is found.  Furthermore all player decisions must be finalized before the random number is selected.  These constraints really screw with the experience.   

So what we need is a RNG generator that can give us actionable random numbers at the requested rate. 

This can be done, but has to be done in a centralized controlled manner.

The reason is that in gaming, you simply can not let a player have any way of knowing the future random #s.  If the RNG generator is distributed, then all bets are off.   So it has to be generated in a centralized service.  The other option is to create random numbers in a distributed manner, but that requires some sort of complicated consensus protocol.  Consensus and responsive are 2 things that go against each other.  So I decided that you need a centralized RNG generator in order to move things along.

This RNG DAC does a few things.

1) Creates an auditable log of the stream of random numbers and can prove that they are indeed random.
2) Allows the request of random numbers at various intervals.
3) Is not distributed, so that players can not peak under the hood.

#2 is critical.  A lotto game that does not have as much of a timing requirement can grab a random number from the next block.  This won't work with interactive games.  And you can't send a seed # and read from it sequentially as the player would be able to then predict future numbers.  Each random number has to come from a host in an atomic manner.

I would prefer some sort of distributed RNG generator that is auditable, demonstrably random, and can service number requests with little latency.  I suspect that is a very hard problem to solve and needs some serious thought.

So until we have this cloud based RNG, this is what I am proposing and wish someone would implement. 

So here are the actors in this.
RNGHost
Gaming block chain
Client

RNGHost publishes a hash of a random number (secret key) and which block it goes with.  This has to be a valid transaction recorded on the blockchain.  When this block occurs, we use the blockhash + secret key for the seed value of the RNG.  After this every gaming random number will be requested from this server. These will be placed in a blockchain transaction for auditing/confirmation.  After a new block is chosen, the secret key is then published and a different previous secret key is chosen.

There is one attack that I am aware of and that is that the person hosting the the random number service could use it to rob the gaming services.  In that regard centralization is better because it lowers the number of actors who can steal.  In addition with 1 RNG host, it can be easily DOS'd.  Forks are also a big issue.  Even by confirming the random number genesis, it still leaves the RNG creations to be lost in a fork.  I am not sure how that is handled.  I guess the player just deals with the timewarp of their fortunes. ;)

Thoughts?  Are there plans for anything like this ?  Is my idea not going to fit into the bitshares world ?  It isn't anything brilliant, but it addresses an issue that is sorely lacking if Bitshares wants to attract a gaming market.

I'd like to see gaming blossom under Bitshares.  Due to the RNG problem I just don't see it happening.  I am not that familiar with the architecture behind Bitshares so maybe this whole idea is unworkable.

Regardless, please comment on this.
« Last Edit: April 13, 2014, 06:21:14 am by gamey »
I speak for myself and only myself.