Bitcoin Forum
March 28, 2024, 11:43:23 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Random Number On Blockchain  (Read 741 times)
truedeckTeam (OP)
Jr. Member
*
Offline Offline

Activity: 42
Merit: 1


View Profile WWW
March 08, 2018, 01:35:02 AM
 #21

All your ideas are good, but I think only nature is true random , so if we build something that will use device temperature cpu usage at that instant, and some noise from microphone, then hash them all , then this will be a random number. And again we can choose a system that will announce some perimeters to accept a random number, and all people submit their numbers to him, he then choose the right number and announce, then people will see and verify that if he chosen right number or not.
I HATE TABLES I HATE TABLES I HA(╯°□°)╯︵ ┻━┻ TABLES I HATE TABLES I HATE TABLES
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711626203
Hero Member
*
Offline Offline

Posts: 1711626203

View Profile Personal Message (Offline)

Ignore
1711626203
Reply with quote  #2

1711626203
Report to moderator
1711626203
Hero Member
*
Offline Offline

Posts: 1711626203

View Profile Personal Message (Offline)

Ignore
1711626203
Reply with quote  #2

1711626203
Report to moderator
1711626203
Hero Member
*
Offline Offline

Posts: 1711626203

View Profile Personal Message (Offline)

Ignore
1711626203
Reply with quote  #2

1711626203
Report to moderator
nullius
Copper Member
Hero Member
*****
Offline Offline

Activity: 630
Merit: 2610


If you don’t do PGP, you don’t do crypto!


View Profile WWW
March 08, 2018, 02:32:39 AM
Merited by ABCbits (2), Foxpup (1), achow101 (1)
 #22

All your ideas are good, but I think only nature is true random , so if we build something that will use device temperature cpu usage at that instant, and some noise from microphone, then hash them all , then this will be a random number. And again we can choose a system that will announce some perimeters to accept a random number, and all people submit their numbers to him, he then choose the right number and announce, then people will see and verify that if he chosen right number or not.

Please do not try to cook up such an ad hoc scheme for gathering randomness.  The scheme you describe is on its face both inadequate for gathering entropy, and easily influenced by local (physical) or perhaps even network attackers.  (A network attacker who can persuade you to visit his website can use Javascript to trivially influence your CPU usage, and thus CPU temperature.)

Worst of all, the scheme you describe requires trust not only in a central party (“he then choose the right number and announce”), but in all parties (how do you remotely verify CPU usage and soundcard input?).  I see no means whatsoever that “people will see and verify” the result here.  What is this thread about?  Why not just have your site pick bits off your server’s /dev/random, which nobody else can verify to be fairly obtained?  The scheme you describe would provide strictly less practical security than that, insofar as it is not even a good local entropy gathering scheme.

If you want a secure network randomness protocol for use on what I presume to be a provably fair gambling site, then implement a commit-and-reveal protocol as I described upthread, with enhancement of the ideas outlined by gmaxwell for preventing holdup by dishonest participants.  This protocol will be cryptographically secure.

Off-topic:  If you be interested in gathering entropy from physical sources, I suggest that you read the paper for Turbid, a high-entropy symbol generator which uses thermodynamic (not acoustic) noise from the analogue circuits in an ordinary computer soundcard.  Proper design of such a thing requires extensive knowledge of both maths and physics.  The Turbid author (Dr. John Denker) has both.

truedeckTeam (OP)
Jr. Member
*
Offline Offline

Activity: 42
Merit: 1


View Profile WWW
March 08, 2018, 12:05:38 PM
 #23

Thanks nullius,
My thinking was that like bitshares has a community that produces blocks , we can ask users to generate a random number using their device’s cpu usage and noise, and then submit the hash of that number, .... Now the user who is going to produce block will submit his random number hash and produce a block , now each one who submitted their random number hash asked to submit their random numbers, then these all random number get mixed and a new final random number get generated, now each user can verify it using algorithm(that generate the final number using all numbers) and also if user submit their random number was correct or not , because they already submitted the hash in previous block.
truedeckTeam (OP)
Jr. Member
*
Offline Offline

Activity: 42
Merit: 1


View Profile WWW
March 09, 2018, 12:57:28 PM
 #24

@nullius , sir you agreed?
GregoryPorter
Jr. Member
*
Offline Offline

Activity: 54
Merit: 3


View Profile
March 10, 2018, 01:54:20 PM
 #25

Ye it's all run through a hashing algorithm that makes think appear random when in fact they are not random. If you type in the same input the out output will always be the same making the key generated not actually random
truedeckTeam (OP)
Jr. Member
*
Offline Offline

Activity: 42
Merit: 1


View Profile WWW
March 14, 2018, 01:34:28 PM
 #26

You are right , that’s what we are trying to do, a true random number on blockchain, and some good ideas from nullius and gmaxwell
truedeckTeam (OP)
Jr. Member
*
Offline Offline

Activity: 42
Merit: 1


View Profile WWW
March 30, 2018, 03:36:49 AM
 #27

Ye it's all run through a hashing algorithm that makes think appear random when in fact they are not random. If you type in the same input the out output will always be the same making the key generated not actually random

It maybe, but if we supply something called nonce , then it is just close to random, however it is still not random
Slava79
Member
**
Offline Offline

Activity: 182
Merit: 17

¯\_(ツ)_/¯


View Profile
March 30, 2018, 03:31:59 PM
 #28

Take the first bit of Hash(blockhash) of the last 64 blocks.

Make a 64 bit number. Hash That.

It's random.

Everyone can calculate it independently.

Right, but everyone will know what's the next number, of block 65. You add 0 or 1 to the previous 63 bits and get 2 possible results, which can't be called random, correct?

Building a JavaScript Smart Contracts Engine
Github | Site | Chat
truedeckTeam (OP)
Jr. Member
*
Offline Offline

Activity: 42
Merit: 1


View Profile WWW
March 31, 2018, 02:41:59 AM
 #29

Please read the scheme described by @nullius ,and gmaxwell , it has something important
spartacusrex
Hero Member
*****
Offline Offline

Activity: 718
Merit: 545



View Profile
March 31, 2018, 08:15:11 PM
 #30

Take the first bit of Hash(blockhash) of the last 64 blocks.

Make a 64 bit number. Hash That.

It's random.

Everyone can calculate it independently.

Right, but everyone will know what's the next number, of block 65. You add 0 or 1 to the previous 63 bits and get 2 possible results, which can't be called random, correct?

True..

Hash( next block hash ) better..

Life is Code.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!