tetaeridanus
Member
 Offline
Activity: 168
Merit: 33
Peace without Borders
|
 |
September 29, 2023, 03:07:39 PM |
|
that email was sent. it was not fabricated mate.
Mmm...hhmmm... so you accept the fact there is something to bury for the, , hence you sre quoting this point to me , bringing in guilt. CG lied to me about provablyfair. CG lied about the lawsuit of 580 $ by cristopher freeman on stake.com so basically they were trying to coverup for stake.com.
Where exactly did I say what you said I said? Kindly re-read. The post is about showing proof [as that's how this board operates] of you asking for a sum of money the first time they granted your wish to talk with their supervisor, while, on CG and many other occasions, you insisted that you were just asking to either bring the manager or pay you. So, yeah, not a rumor. the problem with some people and CG they dont investigate they just specualte.
and when talked abut basics, they go in loops . in point 3 iteration 2 there were 2 iteration for the archives mines game.
the first ine had 2 mines and game ended when i clicked the bomb.
in second iteration it shiws 2 mines and i opened more than 11 bombs, hows that even possible on a mines game of 2 bombs.
clearly its manipualting hence they archive the bets. but still clearly some people and CG fail the basic common sense just to compare the iteration.
holydarkness. i welcome all your question, but it should be only post releated and infact the topiccof concern should be stake.com registering the bets in backend with manipulated odds , a part from that concern you will bring all the stupidest concern , then you should be thinking of qualitative reasoning skill adpat this in your life style.
FYI , those two iterations were picked up CG and stake.com when i send them the archive file. i am just explaning how two iteration of same odds of a mine game are different. if you cant compare the difference between the two iteration let me know
No, the problem here is you being too stubborn to see that you made mistake and misunderstand things. Many, way too many people tried to help contributing to this case, allocating their time to inform you what exactly happened, how to verify bets, etc. and yet you still insist to stick to what you believe, despite all of the facts. My friend the problem is not the OP's topic, it's his narrative. No one came out and said no this this this you are wrong. Stake and CG are father and child companies. I have and had every proof and stake didn't even bother to give an answer because they don't need to. They have a fan base of spastic people who don't even know how to earn a living, won from crypto; childs. I hate that no one blames stake but only players; this is how payroll works i believe.(I'm not talking about you.) |
Haram'da huzur arayana, Huzur haram olur.
|
|
|
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
cryptogeniusdice (OP)
Newbie
Offline
Activity: 130
Merit: 0
|
|
September 29, 2023, 03:17:18 PM |
|
that email was sent. it was not fabricated mate.
Mmm...hhmmm... so you accept the fact there is something to bury for the, , hence you sre quoting this point to me , bringing in guilt. CG lied to me about provablyfair. CG lied about the lawsuit of 580 $ by cristopher freeman on stake.com so basically they were trying to coverup for stake.com.
Where exactly did I say what you said I said? Kindly re-read. The post is about showing proof [as that's how this board operates] of you asking for a sum of money the first time they granted your wish to talk with their supervisor, while, on CG and many other occasions, you insisted that you were just asking to either bring the manager or pay you. So, yeah, not a rumor. the problem with some people and CG they dont investigate they just specualte.
and when talked abut basics, they go in loops . in point 3 iteration 2 there were 2 iteration for the archives mines game.
the first ine had 2 mines and game ended when i clicked the bomb.
in second iteration it shiws 2 mines and i opened more than 11 bombs, hows that even possible on a mines game of 2 bombs.
clearly its manipualting hence they archive the bets. but still clearly some people and CG fail the basic common sense just to compare the iteration.
holydarkness. i welcome all your question, but it should be only post releated and infact the topiccof concern should be stake.com registering the bets in backend with manipulated odds , a part from that concern you will bring all the stupidest concern , then you should be thinking of qualitative reasoning skill adpat this in your life style.
FYI , those two iterations were picked up CG and stake.com when i send them the archive file. i am just explaning how two iteration of same odds of a mine game are different. if you cant compare the difference between the two iteration let me know
No, the problem here is you being too stubborn to see that you made mistake and misunderstand things. Many, way too many people tried to help contributing to this case, allocating their time to inform you what exactly happened, how to verify bets, etc. and yet you still insist to stick to what you believe, despite all of the facts. My friend the problem is not the OP's topic, it's his narrative. No one came out and said no this this this you are wrong. Stake and CG are father and child companies. I have and had every proof and stake didn't even bother to give an answer because they don't need to. They have a fan base of spastic people who don't even know how to earn a living, won from crypto; childs. I hate that no one blames stake but only players; this is how payroll works i believe.(I'm not talking about you.) ok i am just putting my point. no hard love mate |
|
|
|
|
dvdx1995
Newbie
Offline
Activity: 9
Merit: 4
|
|
September 29, 2023, 03:17:39 PM |
|
dvdx i am at certainity that hiw the games of mines work. but can you proof read the difference between the first and the ssecond iteration also explain me why is it two iterations are so much having difference. and also how come second iteration has 2 mines , in it . so how come so many tiles opened for bombs it clearly specifies over there. also https://onlinephp.io/ can you migrate the program here ans give us a link , so that i can verify if its working or not Will try to explain this to you one more time like to 5 year old. Let's assume i go to mines and wanted to play mine game with 3 minesAt the beggining i known HASHED SERVER SEED , MY SECRET AND NONCE Lets say it's HASHED SERVER SEED = 'e7f3006651ac9fa2252cb6db7de2cfa50e8fb9ff479fd16afd45e9f5fa52c24b'; MY SECRET = 'J8ziLyE0L5'; NONCE = 1; I Started to open mines at position 1st Click "field" : 0, 2nd Click "field" : 6, 3rd Click "field": 12, 4th Click "field": 18, 5th Click "field": 24, 6th Click "field": 21, 7th Click "field": 17, On the 7th Click i busted as mine was uncovered/clicked. Now i want to verify if actually MINE WAS AT THAT POSITION at that game with NONCE 1. So i have rotated the seed to get the output for SERVER SEED , stake output for that string in SERVER SEED UNHASHED = '8935bff6600c9ebb504505757ca881131e5f4a2766e8b0debd687100be6e17c4'; Okay move on now to verify the outcome of the mines for that particular game For that instance I've used the code which i wrote yesterday to verify the mine bet Output of my code (link for you to verify https://onlinephp.io/c/b9616 ) lets verify if my unhashedServerSeed is actually sha256 hashedServerSeed , Result: => bool(true)
Mines postions
Game Nonce:1
0 = 13
1 = 17
2 = 5
3 = 8
4 = 10
5 = 24
6 = 15
7 = 7
8 = 6
9 = 22
10 = 19
11 = 0
12 = 21
13 = 1
14 = 3
15 = 20
16 = 4
17 = 16
18 = 2
19 = 23
20 = 11
21 = 12
22 = 18
23 = 14 Okay so i know that i have played with 3 mines that particular game It means in my game mines positions are 0 = 13 (1st mine position field) 1 = 17 (2nd mine position field) 2 = 5 (3rd mine position field) Okay it clearly shows a mine at position field 17 which i uncovered and busted (as explained above) NOW ASSUME BY SOME REASON STAKE PUT THAT BET TO THE ARCHIVE WITH THE REST OF THE FIELD WHICH I DID NOT OPENED/CLICKED SO IN MY LOGS I SEE "state": {
"mines": [
13,
17,
5
],
"minesCount": 3,
"rounds": [
{
"field": 0,
"payoutMultiplier": 1.125
},
{
"field": 6,
"payoutMultiplier": 1.2857142857142856
},
{
"field": 12,
"payoutMultiplier": 1.4785714285714282
},
{
"field": 18,
"payoutMultiplier": 1.7120300751879696
},
{
"field": 24,
"payoutMultiplier": 1.9973684210526312
},
{
"field": 21,
"payoutMultiplier": 2.3498452012383897
},
{
"field": 17,
"payoutMultiplier": 0
},
{
"field": 1,
"payoutMultiplier": 0
},
{
"field": 2,
"payoutMultiplier": 0
},
{
"field": 3,
"payoutMultiplier": 0
},
{
"field": 4,
"payoutMultiplier": 0
},
{
"field": 5,
"payoutMultiplier": 0
},
{
"field": 7,
"payoutMultiplier": 0
},
{
"field": 8,
"payoutMultiplier": 0
},
{
"field": 9,
"payoutMultiplier": 0
},
{
"field": 10,
"payoutMultiplier": 0
},
{
"field": 11,
"payoutMultiplier": 0
},
{
"field": 13,
"payoutMultiplier": 0
},
{
"field": 14,
"payoutMultiplier": 0
},
{
"field": 15,
"payoutMultiplier": 0
},
{
"field": 16,
"payoutMultiplier": 0
}
{
"field": 19,
"payoutMultiplier": 0
}
]
}Does that log format affect anyhow the result of the game ? NO IT DID NOT 1st . 1. Mines position -> IN THE LOG MINES ARE IN THE SAME ORDER AS IN MY CODE OUTPUT (AFTER VERIFICATION OF BET) 2. ORDER OF FIELDS OPENED IS EXACTLY THE SAME AS MY MANUALL CLICKS TILL I BUSTED ON FIELD 17 the EXTRA DATA FOR OPENED FIELDS DOEST NOT AFFECT ANYTHING AS AT THAT POINT I ALREADY LOST THAT GAME ( WHEN CLICKED MINE AT FIELD 17) So it means even if for some reason the output for fields opened have some EXTRA additional fields which were not clicked, BUT the ORDER OF that which we clicked is OK, it means there is no any manipulation. I don't know how STAKE store the logs for best, but if the ORDER OF THE FIELDS OPENED TILL BUST IS EQUAL TO ACTUALLY CLICKED FIELDS IN GAME AND MINES POSITIONS IS IN THE SAME ORDER IT MEAN THE RESULT IS FAIR. |
|
|
|
|
cryptogeniusdice (OP)
Newbie
Offline
Activity: 130
Merit: 0
|
|
September 29, 2023, 05:34:27 PM |
|
dvdx i am at certainity that hiw the games of mines work. but can you proof read the difference between the first and the ssecond iteration also explain me why is it two iterations are so much having difference. and also how come second iteration has 2 mines , in it . so how come so many tiles opened for bombs it clearly specifies over there. also https://onlinephp.io/ can you migrate the program here ans give us a link , so that i can verify if its working or not Will try to explain this to you one more time like to 5 year old. Let's assume i go to mines and wanted to play mine game with 3 minesAt the beggining i known HASHED SERVER SEED , MY SECRET AND NONCE Lets say it's HASHED SERVER SEED = 'e7f3006651ac9fa2252cb6db7de2cfa50e8fb9ff479fd16afd45e9f5fa52c24b'; MY SECRET = 'J8ziLyE0L5'; NONCE = 1; I Started to open mines at position 1st Click "field" : 0, 2nd Click "field" : 6, 3rd Click "field": 12, 4th Click "field": 18, 5th Click "field": 24, 6th Click "field": 21, 7th Click "field": 17, On the 7th Click i busted as mine was uncovered/clicked. Now i want to verify if actually MINE WAS AT THAT POSITION at that game with NONCE 1. So i have rotated the seed to get the output for SERVER SEED , stake output for that string in SERVER SEED UNHASHED = '8935bff6600c9ebb504505757ca881131e5f4a2766e8b0debd687100be6e17c4'; Okay move on now to verify the outcome of the mines for that particular game For that instance I've used the code which i wrote yesterday to verify the mine bet Output of my code (link for you to verify https://onlinephp.io/c/b9616 ) lets verify if my unhashedServerSeed is actually sha256 hashedServerSeed , Result: => bool(true)
Mines postions
Game Nonce:1
0 = 13
1 = 17
2 = 5
3 = 8
4 = 10
5 = 24
6 = 15
7 = 7
8 = 6
9 = 22
10 = 19
11 = 0
12 = 21
13 = 1
14 = 3
15 = 20
16 = 4
17 = 16
18 = 2
19 = 23
20 = 11
21 = 12
22 = 18
23 = 14 Okay so i know that i have played with 3 mines that particular game It means in my game mines positions are 0 = 13 (1st mine position field) 1 = 17 (2nd mine position field) 2 = 5 (3rd mine position field) Okay it clearly shows a mine at position field 17 which i uncovered and busted (as explained above) NOW ASSUME BY SOME REASON STAKE PUT THAT BET TO THE ARCHIVE WITH THE REST OF THE FIELD WHICH I DID NOT OPENED/CLICKED SO IN MY LOGS I SEE "state": {
"mines": [
13,
17,
5
],
"minesCount": 3,
"rounds": [
{
"field": 0,
"payoutMultiplier": 1.125
},
{
"field": 6,
"payoutMultiplier": 1.2857142857142856
},
{
"field": 12,
"payoutMultiplier": 1.4785714285714282
},
{
"field": 18,
"payoutMultiplier": 1.7120300751879696
},
{
"field": 24,
"payoutMultiplier": 1.9973684210526312
},
{
"field": 21,
"payoutMultiplier": 2.3498452012383897
},
{
"field": 17,
"payoutMultiplier": 0
},
{
"field": 1,
"payoutMultiplier": 0
},
{
"field": 2,
"payoutMultiplier": 0
},
{
"field": 3,
"payoutMultiplier": 0
},
{
"field": 4,
"payoutMultiplier": 0
},
{
"field": 5,
"payoutMultiplier": 0
},
{
"field": 7,
"payoutMultiplier": 0
},
{
"field": 8,
"payoutMultiplier": 0
},
{
"field": 9,
"payoutMultiplier": 0
},
{
"field": 10,
"payoutMultiplier": 0
},
{
"field": 11,
"payoutMultiplier": 0
},
{
"field": 13,
"payoutMultiplier": 0
},
{
"field": 14,
"payoutMultiplier": 0
},
{
"field": 15,
"payoutMultiplier": 0
},
{
"field": 16,
"payoutMultiplier": 0
}
{
"field": 19,
"payoutMultiplier": 0
}
]
}Does that log format affect anyhow the result of the game ? NO IT DID NOT 1st . 1. Mines position -> IN THE LOG MINES ARE IN THE SAME ORDER AS IN MY CODE OUTPUT (AFTER VERIFICATION OF BET) 2. ORDER OF FIELDS OPENED IS EXACTLY THE SAME AS MY MANUALL CLICKS TILL I BUSTED ON FIELD 17 the EXTRA DATA FOR OPENED FIELDS DOEST NOT AFFECT ANYTHING AS AT THAT POINT I ALREADY LOST THAT GAME ( WHEN CLICKED MINE AT FIELD 17) So it means even if for some reason the output for fields opened have some EXTRA additional fields which were not clicked, BUT the ORDER OF that which we clicked is OK, it means there is no any manipulation. I don't know how STAKE store the logs for best, but if the ORDER OF THE FIELDS OPENED TILL BUST IS EQUAL TO ACTUALLY CLICKED FIELDS IN GAME AND MINES POSITIONS IS IN THE SAME ORDER IT MEAN THE RESULT IS FAIR. the one which stake has not archived the bet , its showing the correct mines. you still did not understand the question. the problem is the iteration. the point 3 . iteration 1 : iteration 1: {"id":"4199e11e-8861-4b8f-9b43-97ad560cd766","iid":"house:167247337064","type":"casino","scope":"house","userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","betCasino":{"id":"4199e11e-8861-4b8f-9b43-97ad560cd766","active":false,"userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","gameId":"f65ec3b7-705d-42e1-9050 d9ea6fd032b3","currency":"trx","value":0.0000165150794972,"expectedAmount":0.0000020809,"amount":0.00020809,"payoutMultiplier":0,"payout":0,"mobile":false,"serverSeedId":"c7ae0581-091f-4b85-ac5a-9e8e15c5f7b1","clientSeedId":"fc7c4338-e91f-4c13-9cdf-e4475593d7c9","nonce":544,"stateMines":{"_mines":[11,0],"rounds":[{"field":24,"payoutMultiplier":1.076086956521739},{"field":3,"payoutMultiplier":1.1739130434782608},{"field":10,"payoutMultiplier":1.2857142857142859},{"field":9,"payoutMultiplier":1.4142857142857147},{"field":11,"payoutMultiplier":0}],"minesCount":2},"updatedAt":1688820636227,"createdAt":1688820636227}} for this betid the mines and reveal tile is correct. as soon as i clicked the bomb at 11 , the game is over and it’s archived in the system.[/u] whereas for iteration 2 , which was registered in the system .. id":"827819c9-5d9b-4579-a88c-befc0fa54e99","ip":"XXX.YYY.ZZZ.AAA","iid":"house:167250384449","type":"casino","nonce":602,"value":0.0000132,"active":false,"amount":0.0000132,"gameId":"f65ec3b7-705d-42e1-9050-d9ea6fd032b3","mobile":false,"payout":0,"userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","currency":"usdc","gameName":"mines","createdAt":1688821605532,"updatedAt":1688821605532,"clientSeed":"O1zKuEp8081boobs","stateMines":{"_mines":[3,7],"rounds":[{"field":23,"payoutMultiplier":1.076086956521739},{"field":18,"payoutMultiplier":1.1739130434782608},{"field":13,"payoutMultiplier":1.2857142857142858},{"field":5,"payoutMultiplier":1.4142857142857146},{"field":6,"payoutMultiplier":1.5631578947368425},{"field":0,"payoutMultiplier":1.7368421052631584},{"field":1,"payoutMultiplier":1.941176470588236},{"field":2,"payoutMultiplier":2.1838235294117654},{"field":3,"payoutMultiplier":0},{"field":4,"payoutMultiplier":0},{"field":9,"payoutMultiplier":0},{"field":7,"payoutMultiplier":0},{"field":11,"payoutMultiplier":0},{"field":12,"payoutMultiplier":0},{"field":14,"payoutMultiplier":0},{"field":24,"payoutMultiplier":0},{"field":17,"payoutMultiplier":0},{"field":16,"payoutMultiplier":0},{"field":15,"payoutMultiplier":0},{"field":21,"payoutMultiplier":0},{"field":22,"payoutMultiplier":0},{"field":20,"payoutMultiplier":0}],"minesCount":2},"clientSeedId":"fc7c4338-e91f-4c13-9cdf-e4475593d7c9","serverSeedId":"c7ae0581-091f-4b85-ac5a-9e8e15c5f7b1","expectedAmount":1.3200000000000002e-7,"serverSeedHash":"aff867a8be94f30f5bd66c7bbf0fa7a85e1c10b187c22fddb93b5efe807cc4e7","payoutMultiplier":0}, mines for this bet id was 3, and 7 . as soon as i clicked on 3. the game should be over . but its not the game shows that i clicked on tiles 4,9,7,1,12,14,24,17,16,15,21,22,20 and 2 . how is this possible . and its not a. autobet which has been placed. this iteration shows that apart from mines on tiles 3,7 the bombs were on rest of the tiles as well. [\b][\u]
stake controls the iteration , later on the bets are deleted citing as archive and the mines field array is filled. [\b][\u]
hence the bet is manipulated. [\b][\u]
when you play mines on 2 mines you will find bomb on the first click this is one of the reasons[\b][\u]
in this game i have got 7 first bomb for mines of 2. what are the chances for that. [\b][\u] |
|
|
|
|
cryptogeniusdice (OP)
Newbie
Offline
Activity: 130
Merit: 0
|
|
September 29, 2023, 05:35:45 PM |
|
dvdx i am at certainity that hiw the games of mines work. but can you proof read the difference between the first and the ssecond iteration also explain me why is it two iterations are so much having difference. and also how come second iteration has 2 mines , in it . so how come so many tiles opened for bombs it clearly specifies over there. also https://onlinephp.io/ can you migrate the program here ans give us a link , so that i can verify if its working or not Will try to explain this to you one more time like to 5 year old. Let's assume i go to mines and wanted to play mine game with 3 minesAt the beggining i known HASHED SERVER SEED , MY SECRET AND NONCE Lets say it's HASHED SERVER SEED = 'e7f3006651ac9fa2252cb6db7de2cfa50e8fb9ff479fd16afd45e9f5fa52c24b'; MY SECRET = 'J8ziLyE0L5'; NONCE = 1; I Started to open mines at position 1st Click "field" : 0, 2nd Click "field" : 6, 3rd Click "field": 12, 4th Click "field": 18, 5th Click "field": 24, 6th Click "field": 21, 7th Click "field": 17, On the 7th Click i busted as mine was uncovered/clicked. Now i want to verify if actually MINE WAS AT THAT POSITION at that game with NONCE 1. So i have rotated the seed to get the output for SERVER SEED , stake output for that string in SERVER SEED UNHASHED = '8935bff6600c9ebb504505757ca881131e5f4a2766e8b0debd687100be6e17c4'; Okay move on now to verify the outcome of the mines for that particular game For that instance I've used the code which i wrote yesterday to verify the mine bet Output of my code (link for you to verify https://onlinephp.io/c/b9616 ) lets verify if my unhashedServerSeed is actually sha256 hashedServerSeed , Result: => bool(true)
Mines postions
Game Nonce:1
0 = 13
1 = 17
2 = 5
3 = 8
4 = 10
5 = 24
6 = 15
7 = 7
8 = 6
9 = 22
10 = 19
11 = 0
12 = 21
13 = 1
14 = 3
15 = 20
16 = 4
17 = 16
18 = 2
19 = 23
20 = 11
21 = 12
22 = 18
23 = 14 Okay so i know that i have played with 3 mines that particular game It means in my game mines positions are 0 = 13 (1st mine position field) 1 = 17 (2nd mine position field) 2 = 5 (3rd mine position field) Okay it clearly shows a mine at position field 17 which i uncovered and busted (as explained above) NOW ASSUME BY SOME REASON STAKE PUT THAT BET TO THE ARCHIVE WITH THE REST OF THE FIELD WHICH I DID NOT OPENED/CLICKED SO IN MY LOGS I SEE "state": {
"mines": [
13,
17,
5
],
"minesCount": 3,
"rounds": [
{
"field": 0,
"payoutMultiplier": 1.125
},
{
"field": 6,
"payoutMultiplier": 1.2857142857142856
},
{
"field": 12,
"payoutMultiplier": 1.4785714285714282
},
{
"field": 18,
"payoutMultiplier": 1.7120300751879696
},
{
"field": 24,
"payoutMultiplier": 1.9973684210526312
},
{
"field": 21,
"payoutMultiplier": 2.3498452012383897
},
{
"field": 17,
"payoutMultiplier": 0
},
{
"field": 1,
"payoutMultiplier": 0
},
{
"field": 2,
"payoutMultiplier": 0
},
{
"field": 3,
"payoutMultiplier": 0
},
{
"field": 4,
"payoutMultiplier": 0
},
{
"field": 5,
"payoutMultiplier": 0
},
{
"field": 7,
"payoutMultiplier": 0
},
{
"field": 8,
"payoutMultiplier": 0
},
{
"field": 9,
"payoutMultiplier": 0
},
{
"field": 10,
"payoutMultiplier": 0
},
{
"field": 11,
"payoutMultiplier": 0
},
{
"field": 13,
"payoutMultiplier": 0
},
{
"field": 14,
"payoutMultiplier": 0
},
{
"field": 15,
"payoutMultiplier": 0
},
{
"field": 16,
"payoutMultiplier": 0
}
{
"field": 19,
"payoutMultiplier": 0
}
]
}Does that log format affect anyhow the result of the game ? NO IT DID NOT 1st . 1. Mines position -> IN THE LOG MINES ARE IN THE SAME ORDER AS IN MY CODE OUTPUT (AFTER VERIFICATION OF BET) 2. ORDER OF FIELDS OPENED IS EXACTLY THE SAME AS MY MANUALL CLICKS TILL I BUSTED ON FIELD 17 the EXTRA DATA FOR OPENED FIELDS DOEST NOT AFFECT ANYTHING AS AT THAT POINT I ALREADY LOST THAT GAME ( WHEN CLICKED MINE AT FIELD 17) So it means even if for some reason the output for fields opened have some EXTRA additional fields which were not clicked, BUT the ORDER OF that which we clicked is OK, it means there is no any manipulation. I don't know how STAKE store the logs for best, but if the ORDER OF THE FIELDS OPENED TILL BUST IS EQUAL TO ACTUALLY CLICKED FIELDS IN GAME AND MINES POSITIONS IS IN THE SAME ORDER IT MEAN THE RESULT IS FAIR. thanks for the php format to verify . i will do due dilligence of my old bets with recordings. you are a saviour. |
|
|
|
|
dvdx1995
Newbie
Offline
Activity: 9
Merit: 4
|
|
September 29, 2023, 05:58:18 PM |
|
dvdx i am at certainity that hiw the games of mines work. but can you proof read the difference between the first and the ssecond iteration also explain me why is it two iterations are so much having difference. and also how come second iteration has 2 mines , in it . so how come so many tiles opened for bombs it clearly specifies over there. also https://onlinephp.io/ can you migrate the program here ans give us a link , so that i can verify if its working or not Will try to explain this to you one more time like to 5 year old. Let's assume i go to mines and wanted to play mine game with 3 minesAt the beggining i known HASHED SERVER SEED , MY SECRET AND NONCE Lets say it's HASHED SERVER SEED = 'e7f3006651ac9fa2252cb6db7de2cfa50e8fb9ff479fd16afd45e9f5fa52c24b'; MY SECRET = 'J8ziLyE0L5'; NONCE = 1; I Started to open mines at position 1st Click "field" : 0, 2nd Click "field" : 6, 3rd Click "field": 12, 4th Click "field": 18, 5th Click "field": 24, 6th Click "field": 21, 7th Click "field": 17, On the 7th Click i busted as mine was uncovered/clicked. Now i want to verify if actually MINE WAS AT THAT POSITION at that game with NONCE 1. So i have rotated the seed to get the output for SERVER SEED , stake output for that string in SERVER SEED UNHASHED = '8935bff6600c9ebb504505757ca881131e5f4a2766e8b0debd687100be6e17c4'; Okay move on now to verify the outcome of the mines for that particular game For that instance I've used the code which i wrote yesterday to verify the mine bet Output of my code (link for you to verify https://onlinephp.io/c/b9616 ) lets verify if my unhashedServerSeed is actually sha256 hashedServerSeed , Result: => bool(true)
Mines postions
Game Nonce:1
0 = 13
1 = 17
2 = 5
3 = 8
4 = 10
5 = 24
6 = 15
7 = 7
8 = 6
9 = 22
10 = 19
11 = 0
12 = 21
13 = 1
14 = 3
15 = 20
16 = 4
17 = 16
18 = 2
19 = 23
20 = 11
21 = 12
22 = 18
23 = 14 Okay so i know that i have played with 3 mines that particular game It means in my game mines positions are 0 = 13 (1st mine position field) 1 = 17 (2nd mine position field) 2 = 5 (3rd mine position field) Okay it clearly shows a mine at position field 17 which i uncovered and busted (as explained above) NOW ASSUME BY SOME REASON STAKE PUT THAT BET TO THE ARCHIVE WITH THE REST OF THE FIELD WHICH I DID NOT OPENED/CLICKED SO IN MY LOGS I SEE "state": {
"mines": [
13,
17,
5
],
"minesCount": 3,
"rounds": [
{
"field": 0,
"payoutMultiplier": 1.125
},
{
"field": 6,
"payoutMultiplier": 1.2857142857142856
},
{
"field": 12,
"payoutMultiplier": 1.4785714285714282
},
{
"field": 18,
"payoutMultiplier": 1.7120300751879696
},
{
"field": 24,
"payoutMultiplier": 1.9973684210526312
},
{
"field": 21,
"payoutMultiplier": 2.3498452012383897
},
{
"field": 17,
"payoutMultiplier": 0
},
{
"field": 1,
"payoutMultiplier": 0
},
{
"field": 2,
"payoutMultiplier": 0
},
{
"field": 3,
"payoutMultiplier": 0
},
{
"field": 4,
"payoutMultiplier": 0
},
{
"field": 5,
"payoutMultiplier": 0
},
{
"field": 7,
"payoutMultiplier": 0
},
{
"field": 8,
"payoutMultiplier": 0
},
{
"field": 9,
"payoutMultiplier": 0
},
{
"field": 10,
"payoutMultiplier": 0
},
{
"field": 11,
"payoutMultiplier": 0
},
{
"field": 13,
"payoutMultiplier": 0
},
{
"field": 14,
"payoutMultiplier": 0
},
{
"field": 15,
"payoutMultiplier": 0
},
{
"field": 16,
"payoutMultiplier": 0
}
{
"field": 19,
"payoutMultiplier": 0
}
]
}Does that log format affect anyhow the result of the game ? NO IT DID NOT 1st . 1. Mines position -> IN THE LOG MINES ARE IN THE SAME ORDER AS IN MY CODE OUTPUT (AFTER VERIFICATION OF BET) 2. ORDER OF FIELDS OPENED IS EXACTLY THE SAME AS MY MANUALL CLICKS TILL I BUSTED ON FIELD 17 the EXTRA DATA FOR OPENED FIELDS DOEST NOT AFFECT ANYTHING AS AT THAT POINT I ALREADY LOST THAT GAME ( WHEN CLICKED MINE AT FIELD 17) So it means even if for some reason the output for fields opened have some EXTRA additional fields which were not clicked, BUT the ORDER OF that which we clicked is OK, it means there is no any manipulation. I don't know how STAKE store the logs for best, but if the ORDER OF THE FIELDS OPENED TILL BUST IS EQUAL TO ACTUALLY CLICKED FIELDS IN GAME AND MINES POSITIONS IS IN THE SAME ORDER IT MEAN THE RESULT IS FAIR. the one which stake has not archived the bet , its showing the correct mines. you still did not understand the question. the problem is the iteration. the point 3 . iteration 1 : iteration 1: {"id":"4199e11e-8861-4b8f-9b43-97ad560cd766","iid":"house:167247337064","type":"casino","scope":"house","userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","betCasino":{"id":"4199e11e-8861-4b8f-9b43-97ad560cd766","active":false,"userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","gameId":"f65ec3b7-705d-42e1-9050 d9ea6fd032b3","currency":"trx","value":0.0000165150794972,"expectedAmount":0.0000020809,"amount":0.00020809,"payoutMultiplier":0,"payout":0,"mobile":false,"serverSeedId":"c7ae0581-091f-4b85-ac5a-9e8e15c5f7b1","clientSeedId":"fc7c4338-e91f-4c13-9cdf-e4475593d7c9","nonce":544,"stateMines":{"_mines":[11,0],"rounds":[{"field":24,"payoutMultiplier":1.076086956521739},{"field":3,"payoutMultiplier":1.1739130434782608},{"field":10,"payoutMultiplier":1.2857142857142859},{"field":9,"payoutMultiplier":1.4142857142857147},{"field":11,"payoutMultiplier":0}],"minesCount":2},"updatedAt":1688820636227,"createdAt":1688820636227}} for this betid the mines and reveal tile is correct. as soon as i clicked the bomb at 11 , the game is over and it’s archived in the system.[/u] whereas for iteration 2 , which was registered in the system .. id":"827819c9-5d9b-4579-a88c-befc0fa54e99","ip":"XXX.YYY.ZZZ.AAA","iid":"house:167250384449","type":"casino","nonce":602,"value":0.0000132,"active":false,"amount":0.0000132,"gameId":"f65ec3b7-705d-42e1-9050-d9ea6fd032b3","mobile":false,"payout":0,"userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","currency":"usdc","gameName":"mines","createdAt":1688821605532,"updatedAt":1688821605532,"clientSeed":"O1zKuEp8081boobs","stateMines":{"_mines":[3,7],"rounds":[{"field":23,"payoutMultiplier":1.076086956521739},{"field":18,"payoutMultiplier":1.1739130434782608},{"field":13,"payoutMultiplier":1.2857142857142858},{"field":5,"payoutMultiplier":1.4142857142857146},{"field":6,"payoutMultiplier":1.5631578947368425},{"field":0,"payoutMultiplier":1.7368421052631584},{"field":1,"payoutMultiplier":1.941176470588236},{"field":2,"payoutMultiplier":2.1838235294117654},{"field":3,"payoutMultiplier":0},{"field":4,"payoutMultiplier":0},{"field":9,"payoutMultiplier":0},{"field":7,"payoutMultiplier":0},{"field":11,"payoutMultiplier":0},{"field":12,"payoutMultiplier":0},{"field":14,"payoutMultiplier":0},{"field":24,"payoutMultiplier":0},{"field":17,"payoutMultiplier":0},{"field":16,"payoutMultiplier":0},{"field":15,"payoutMultiplier":0},{"field":21,"payoutMultiplier":0},{"field":22,"payoutMultiplier":0},{"field":20,"payoutMultiplier":0}],"minesCount":2},"clientSeedId":"fc7c4338-e91f-4c13-9cdf-e4475593d7c9","serverSeedId":"c7ae0581-091f-4b85-ac5a-9e8e15c5f7b1","expectedAmount":1.3200000000000002e-7,"serverSeedHash":"aff867a8be94f30f5bd66c7bbf0fa7a85e1c10b187c22fddb93b5efe807cc4e7","payoutMultiplier":0}, mines for this bet id was 3, and 7 . as soon as i clicked on 3. the game should be over . but its not the game shows that i clicked on tiles 4,9,7,1,12,14,24,17,16,15,21,22,20 and 2 . how is this possible . and its not a. autobet which has been placed. this iteration shows that apart from mines on tiles 3,7 the bombs were on rest of the tiles as well. [\b][\u]
stake controls the iteration , later on the bets are deleted citing as archive and the mines field array is filled. [\b][\u]
hence the bet is manipulated. [\b][\u]
when you play mines on 2 mines you will find bomb on the first click this is one of the reasons[\b][\u]
in this game i have got 7 first bomb for mines of 2. what are the chances for that. [\b][\u]
I think you missunderstood the concept of stake bet archive ... That they provide for the customers some service like bet archiver where you can download and check out your bets it's actually nothing which can prove the bet was fair or not. To verify if bet was fair you must have 1. record of the tiles (ordered, per click id) which you opened till busted on mine ( after that game is over) or you won/payed out the game at current nonce. 2. fields where mines were placed on your bet (before unhashed server seed is unrevealed) - you can see it in graphic view of the bet, as well if you more advanced you can check that in your browser network tab as stake actually provide this infrmation on the response request when you bust/cashout/win the round. 3. amount of mines played in specific game (per nonce) 4. unhashed server seed , hashed server seed , client seed , and nonce. And now you can verify the fairness of the specific BET NONCE. As i already wrote, i don't know why that iteration was shown/stored in their Archive bet system, but once again as you have the all data which i listed above you don't even need to have such like bet archive provided by Stake to proof the fairness of the bet or bets. |
|
|
|
|
cryptogeniusdice (OP)
Newbie
Offline
Activity: 130
Merit: 0
|
|
September 29, 2023, 07:42:53 PM |
|
dvdx i am at certainity that hiw the games of mines work. but can you proof read the difference between the first and the ssecond iteration also explain me why is it two iterations are so much having difference. and also how come second iteration has 2 mines , in it . so how come so many tiles opened for bombs it clearly specifies over there. also https://onlinephp.io/ can you migrate the program here ans give us a link , so that i can verify if its working or not Will try to explain this to you one more time like to 5 year old. Let's assume i go to mines and wanted to play mine game with 3 minesAt the beggining i known HASHED SERVER SEED , MY SECRET AND NONCE Lets say it's HASHED SERVER SEED = 'e7f3006651ac9fa2252cb6db7de2cfa50e8fb9ff479fd16afd45e9f5fa52c24b'; MY SECRET = 'J8ziLyE0L5'; NONCE = 1; I Started to open mines at position 1st Click "field" : 0, 2nd Click "field" : 6, 3rd Click "field": 12, 4th Click "field": 18, 5th Click "field": 24, 6th Click "field": 21, 7th Click "field": 17, On the 7th Click i busted as mine was uncovered/clicked. Now i want to verify if actually MINE WAS AT THAT POSITION at that game with NONCE 1. So i have rotated the seed to get the output for SERVER SEED , stake output for that string in SERVER SEED UNHASHED = '8935bff6600c9ebb504505757ca881131e5f4a2766e8b0debd687100be6e17c4'; Okay move on now to verify the outcome of the mines for that particular game For that instance I've used the code which i wrote yesterday to verify the mine bet Output of my code (link for you to verify https://onlinephp.io/c/b9616 ) lets verify if my unhashedServerSeed is actually sha256 hashedServerSeed , Result: => bool(true)
Mines postions
Game Nonce:1
0 = 13
1 = 17
2 = 5
3 = 8
4 = 10
5 = 24
6 = 15
7 = 7
8 = 6
9 = 22
10 = 19
11 = 0
12 = 21
13 = 1
14 = 3
15 = 20
16 = 4
17 = 16
18 = 2
19 = 23
20 = 11
21 = 12
22 = 18
23 = 14 Okay so i know that i have played with 3 mines that particular game It means in my game mines positions are 0 = 13 (1st mine position field) 1 = 17 (2nd mine position field) 2 = 5 (3rd mine position field) Okay it clearly shows a mine at position field 17 which i uncovered and busted (as explained above) NOW ASSUME BY SOME REASON STAKE PUT THAT BET TO THE ARCHIVE WITH THE REST OF THE FIELD WHICH I DID NOT OPENED/CLICKED SO IN MY LOGS I SEE "state": {
"mines": [
13,
17,
5
],
"minesCount": 3,
"rounds": [
{
"field": 0,
"payoutMultiplier": 1.125
},
{
"field": 6,
"payoutMultiplier": 1.2857142857142856
},
{
"field": 12,
"payoutMultiplier": 1.4785714285714282
},
{
"field": 18,
"payoutMultiplier": 1.7120300751879696
},
{
"field": 24,
"payoutMultiplier": 1.9973684210526312
},
{
"field": 21,
"payoutMultiplier": 2.3498452012383897
},
{
"field": 17,
"payoutMultiplier": 0
},
{
"field": 1,
"payoutMultiplier": 0
},
{
"field": 2,
"payoutMultiplier": 0
},
{
"field": 3,
"payoutMultiplier": 0
},
{
"field": 4,
"payoutMultiplier": 0
},
{
"field": 5,
"payoutMultiplier": 0
},
{
"field": 7,
"payoutMultiplier": 0
},
{
"field": 8,
"payoutMultiplier": 0
},
{
"field": 9,
"payoutMultiplier": 0
},
{
"field": 10,
"payoutMultiplier": 0
},
{
"field": 11,
"payoutMultiplier": 0
},
{
"field": 13,
"payoutMultiplier": 0
},
{
"field": 14,
"payoutMultiplier": 0
},
{
"field": 15,
"payoutMultiplier": 0
},
{
"field": 16,
"payoutMultiplier": 0
}
{
"field": 19,
"payoutMultiplier": 0
}
]
}Does that log format affect anyhow the result of the game ? NO IT DID NOT 1st . 1. Mines position -> IN THE LOG MINES ARE IN THE SAME ORDER AS IN MY CODE OUTPUT (AFTER VERIFICATION OF BET) 2. ORDER OF FIELDS OPENED IS EXACTLY THE SAME AS MY MANUALL CLICKS TILL I BUSTED ON FIELD 17 the EXTRA DATA FOR OPENED FIELDS DOEST NOT AFFECT ANYTHING AS AT THAT POINT I ALREADY LOST THAT GAME ( WHEN CLICKED MINE AT FIELD 17) So it means even if for some reason the output for fields opened have some EXTRA additional fields which were not clicked, BUT the ORDER OF that which we clicked is OK, it means there is no any manipulation. I don't know how STAKE store the logs for best, but if the ORDER OF THE FIELDS OPENED TILL BUST IS EQUAL TO ACTUALLY CLICKED FIELDS IN GAME AND MINES POSITIONS IS IN THE SAME ORDER IT MEAN THE RESULT IS FAIR. the one which stake has not archived the bet , its showing the correct mines. you still did not understand the question. the problem is the iteration. the point 3 . iteration 1 : iteration 1: {"id":"4199e11e-8861-4b8f-9b43-97ad560cd766","iid":"house:167247337064","type":"casino","scope":"house","userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","betCasino":{"id":"4199e11e-8861-4b8f-9b43-97ad560cd766","active":false,"userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","gameId":"f65ec3b7-705d-42e1-9050 d9ea6fd032b3","currency":"trx","value":0.0000165150794972,"expectedAmount":0.0000020809,"amount":0.00020809,"payoutMultiplier":0,"payout":0,"mobile":false,"serverSeedId":"c7ae0581-091f-4b85-ac5a-9e8e15c5f7b1","clientSeedId":"fc7c4338-e91f-4c13-9cdf-e4475593d7c9","nonce":544,"stateMines":{"_mines":[11,0],"rounds":[{"field":24,"payoutMultiplier":1.076086956521739},{"field":3,"payoutMultiplier":1.1739130434782608},{"field":10,"payoutMultiplier":1.2857142857142859},{"field":9,"payoutMultiplier":1.4142857142857147},{"field":11,"payoutMultiplier":0}],"minesCount":2},"updatedAt":1688820636227,"createdAt":1688820636227}} for this betid the mines and reveal tile is correct. as soon as i clicked the bomb at 11 , the game is over and it’s archived in the system.[/u] whereas for iteration 2 , which was registered in the system .. id":"827819c9-5d9b-4579-a88c-befc0fa54e99","ip":"XXX.YYY.ZZZ.AAA","iid":"house:167250384449","type":"casino","nonce":602,"value":0.0000132,"active":false,"amount":0.0000132,"gameId":"f65ec3b7-705d-42e1-9050-d9ea6fd032b3","mobile":false,"payout":0,"userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","currency":"usdc","gameName":"mines","createdAt":1688821605532,"updatedAt":1688821605532,"clientSeed":"O1zKuEp8081boobs","stateMines":{"_mines":[3,7],"rounds":[{"field":23,"payoutMultiplier":1.076086956521739},{"field":18,"payoutMultiplier":1.1739130434782608},{"field":13,"payoutMultiplier":1.2857142857142858},{"field":5,"payoutMultiplier":1.4142857142857146},{"field":6,"payoutMultiplier":1.5631578947368425},{"field":0,"payoutMultiplier":1.7368421052631584},{"field":1,"payoutMultiplier":1.941176470588236},{"field":2,"payoutMultiplier":2.1838235294117654},{"field":3,"payoutMultiplier":0},{"field":4,"payoutMultiplier":0},{"field":9,"payoutMultiplier":0},{"field":7,"payoutMultiplier":0},{"field":11,"payoutMultiplier":0},{"field":12,"payoutMultiplier":0},{"field":14,"payoutMultiplier":0},{"field":24,"payoutMultiplier":0},{"field":17,"payoutMultiplier":0},{"field":16,"payoutMultiplier":0},{"field":15,"payoutMultiplier":0},{"field":21,"payoutMultiplier":0},{"field":22,"payoutMultiplier":0},{"field":20,"payoutMultiplier":0}],"minesCount":2},"clientSeedId":"fc7c4338-e91f-4c13-9cdf-e4475593d7c9","serverSeedId":"c7ae0581-091f-4b85-ac5a-9e8e15c5f7b1","expectedAmount":1.3200000000000002e-7,"serverSeedHash":"aff867a8be94f30f5bd66c7bbf0fa7a85e1c10b187c22fddb93b5efe807cc4e7","payoutMultiplier":0}, mines for this bet id was 3, and 7 . as soon as i clicked on 3. the game should be over . but its not the game shows that i clicked on tiles 4,9,7,1,12,14,24,17,16,15,21,22,20 and 2 . how is this possible . and its not a. autobet which has been placed. this iteration shows that apart from mines on tiles 3,7 the bombs were on rest of the tiles as well. [\b][\u]
stake controls the iteration , later on the bets are deleted citing as archive and the mines field array is filled. [\b][\u]
hence the bet is manipulated. [\b][\u]
when you play mines on 2 mines you will find bomb on the first click this is one of the reasons[\b][\u]
in this game i have got 7 first bomb for mines of 2. what are the chances for that. [\b][\u]
I think you missunderstood the concept of stake bet archive ... That they provide for the customers some service like bet archiver where you can download and check out your bets it's actually nothing which can prove the bet was fair or not. To verify if bet was fair you must have 1. record of the tiles (ordered, per click id) which you opened till busted on mine ( after that game is over) or you won/payed out the game at current nonce. 2. fields where mines were placed on your bet (before unhashed server seed is unrevealed) - you can see it in graphic view of the bet, as well if you more advanced you can check that in your browser network tab as stake actually provide this infrmation on the response request when you bust/cashout/win the round. 3. amount of mines played in specific game (per nonce) 4. unhashed server seed , hashed server seed , client seed , and nonce. And now you can verify the fairness of the specific BET NONCE. As i already wrote, i don't know why that iteration was shown/stored in their Archive bet system, but once again as you have the all data which i listed above you don't even need to have such like bet archive provided by Stake to proof the fairness of the bet or bets. this is the issue with stake archiving the data within 3 -5 days and we revealing the seeds after big nonces . the archive doesn’t show the real esscense of gameplay. the iteration on the back end is clearly something else. also stake.com registered a mines games in two different iteration for same odds. which clearly specify that in the back end there is something wrong. are you aware about hash value hash highway. merkle root verifcation using Benfords laws using merkle trees. |
|
|
|
|
dvdx1995
Newbie
Offline
Activity: 9
Merit: 4
|
|
September 29, 2023, 08:11:10 PM |
|
dvdx i am at certainity that hiw the games of mines work. but can you proof read the difference between the first and the ssecond iteration also explain me why is it two iterations are so much having difference. and also how come second iteration has 2 mines , in it . so how come so many tiles opened for bombs it clearly specifies over there. also https://onlinephp.io/ can you migrate the program here ans give us a link , so that i can verify if its working or not Will try to explain this to you one more time like to 5 year old. Let's assume i go to mines and wanted to play mine game with 3 minesAt the beggining i known HASHED SERVER SEED , MY SECRET AND NONCE Lets say it's HASHED SERVER SEED = 'e7f3006651ac9fa2252cb6db7de2cfa50e8fb9ff479fd16afd45e9f5fa52c24b'; MY SECRET = 'J8ziLyE0L5'; NONCE = 1; I Started to open mines at position 1st Click "field" : 0, 2nd Click "field" : 6, 3rd Click "field": 12, 4th Click "field": 18, 5th Click "field": 24, 6th Click "field": 21, 7th Click "field": 17, On the 7th Click i busted as mine was uncovered/clicked. Now i want to verify if actually MINE WAS AT THAT POSITION at that game with NONCE 1. So i have rotated the seed to get the output for SERVER SEED , stake output for that string in SERVER SEED UNHASHED = '8935bff6600c9ebb504505757ca881131e5f4a2766e8b0debd687100be6e17c4'; Okay move on now to verify the outcome of the mines for that particular game For that instance I've used the code which i wrote yesterday to verify the mine bet Output of my code (link for you to verify https://onlinephp.io/c/b9616 ) lets verify if my unhashedServerSeed is actually sha256 hashedServerSeed , Result: => bool(true)
Mines postions
Game Nonce:1
0 = 13
1 = 17
2 = 5
3 = 8
4 = 10
5 = 24
6 = 15
7 = 7
8 = 6
9 = 22
10 = 19
11 = 0
12 = 21
13 = 1
14 = 3
15 = 20
16 = 4
17 = 16
18 = 2
19 = 23
20 = 11
21 = 12
22 = 18
23 = 14 Okay so i know that i have played with 3 mines that particular game It means in my game mines positions are 0 = 13 (1st mine position field) 1 = 17 (2nd mine position field) 2 = 5 (3rd mine position field) Okay it clearly shows a mine at position field 17 which i uncovered and busted (as explained above) NOW ASSUME BY SOME REASON STAKE PUT THAT BET TO THE ARCHIVE WITH THE REST OF THE FIELD WHICH I DID NOT OPENED/CLICKED SO IN MY LOGS I SEE "state": {
"mines": [
13,
17,
5
],
"minesCount": 3,
"rounds": [
{
"field": 0,
"payoutMultiplier": 1.125
},
{
"field": 6,
"payoutMultiplier": 1.2857142857142856
},
{
"field": 12,
"payoutMultiplier": 1.4785714285714282
},
{
"field": 18,
"payoutMultiplier": 1.7120300751879696
},
{
"field": 24,
"payoutMultiplier": 1.9973684210526312
},
{
"field": 21,
"payoutMultiplier": 2.3498452012383897
},
{
"field": 17,
"payoutMultiplier": 0
},
{
"field": 1,
"payoutMultiplier": 0
},
{
"field": 2,
"payoutMultiplier": 0
},
{
"field": 3,
"payoutMultiplier": 0
},
{
"field": 4,
"payoutMultiplier": 0
},
{
"field": 5,
"payoutMultiplier": 0
},
{
"field": 7,
"payoutMultiplier": 0
},
{
"field": 8,
"payoutMultiplier": 0
},
{
"field": 9,
"payoutMultiplier": 0
},
{
"field": 10,
"payoutMultiplier": 0
},
{
"field": 11,
"payoutMultiplier": 0
},
{
"field": 13,
"payoutMultiplier": 0
},
{
"field": 14,
"payoutMultiplier": 0
},
{
"field": 15,
"payoutMultiplier": 0
},
{
"field": 16,
"payoutMultiplier": 0
}
{
"field": 19,
"payoutMultiplier": 0
}
]
}Does that log format affect anyhow the result of the game ? NO IT DID NOT 1st . 1. Mines position -> IN THE LOG MINES ARE IN THE SAME ORDER AS IN MY CODE OUTPUT (AFTER VERIFICATION OF BET) 2. ORDER OF FIELDS OPENED IS EXACTLY THE SAME AS MY MANUALL CLICKS TILL I BUSTED ON FIELD 17 the EXTRA DATA FOR OPENED FIELDS DOEST NOT AFFECT ANYTHING AS AT THAT POINT I ALREADY LOST THAT GAME ( WHEN CLICKED MINE AT FIELD 17) So it means even if for some reason the output for fields opened have some EXTRA additional fields which were not clicked, BUT the ORDER OF that which we clicked is OK, it means there is no any manipulation. I don't know how STAKE store the logs for best, but if the ORDER OF THE FIELDS OPENED TILL BUST IS EQUAL TO ACTUALLY CLICKED FIELDS IN GAME AND MINES POSITIONS IS IN THE SAME ORDER IT MEAN THE RESULT IS FAIR. the one which stake has not archived the bet , its showing the correct mines. you still did not understand the question. the problem is the iteration. the point 3 . iteration 1 : iteration 1: {"id":"4199e11e-8861-4b8f-9b43-97ad560cd766","iid":"house:167247337064","type":"casino","scope":"house","userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","betCasino":{"id":"4199e11e-8861-4b8f-9b43-97ad560cd766","active":false,"userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","gameId":"f65ec3b7-705d-42e1-9050 d9ea6fd032b3","currency":"trx","value":0.0000165150794972,"expectedAmount":0.0000020809,"amount":0.00020809,"payoutMultiplier":0,"payout":0,"mobile":false,"serverSeedId":"c7ae0581-091f-4b85-ac5a-9e8e15c5f7b1","clientSeedId":"fc7c4338-e91f-4c13-9cdf-e4475593d7c9","nonce":544,"stateMines":{"_mines":[11,0],"rounds":[{"field":24,"payoutMultiplier":1.076086956521739},{"field":3,"payoutMultiplier":1.1739130434782608},{"field":10,"payoutMultiplier":1.2857142857142859},{"field":9,"payoutMultiplier":1.4142857142857147},{"field":11,"payoutMultiplier":0}],"minesCount":2},"updatedAt":1688820636227,"createdAt":1688820636227}} for this betid the mines and reveal tile is correct. as soon as i clicked the bomb at 11 , the game is over and it’s archived in the system.[/u] whereas for iteration 2 , which was registered in the system .. id":"827819c9-5d9b-4579-a88c-befc0fa54e99","ip":"XXX.YYY.ZZZ.AAA","iid":"house:167250384449","type":"casino","nonce":602,"value":0.0000132,"active":false,"amount":0.0000132,"gameId":"f65ec3b7-705d-42e1-9050-d9ea6fd032b3","mobile":false,"payout":0,"userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","currency":"usdc","gameName":"mines","createdAt":1688821605532,"updatedAt":1688821605532,"clientSeed":"O1zKuEp8081boobs","stateMines":{"_mines":[3,7],"rounds":[{"field":23,"payoutMultiplier":1.076086956521739},{"field":18,"payoutMultiplier":1.1739130434782608},{"field":13,"payoutMultiplier":1.2857142857142858},{"field":5,"payoutMultiplier":1.4142857142857146},{"field":6,"payoutMultiplier":1.5631578947368425},{"field":0,"payoutMultiplier":1.7368421052631584},{"field":1,"payoutMultiplier":1.941176470588236},{"field":2,"payoutMultiplier":2.1838235294117654},{"field":3,"payoutMultiplier":0},{"field":4,"payoutMultiplier":0},{"field":9,"payoutMultiplier":0},{"field":7,"payoutMultiplier":0},{"field":11,"payoutMultiplier":0},{"field":12,"payoutMultiplier":0},{"field":14,"payoutMultiplier":0},{"field":24,"payoutMultiplier":0},{"field":17,"payoutMultiplier":0},{"field":16,"payoutMultiplier":0},{"field":15,"payoutMultiplier":0},{"field":21,"payoutMultiplier":0},{"field":22,"payoutMultiplier":0},{"field":20,"payoutMultiplier":0}],"minesCount":2},"clientSeedId":"fc7c4338-e91f-4c13-9cdf-e4475593d7c9","serverSeedId":"c7ae0581-091f-4b85-ac5a-9e8e15c5f7b1","expectedAmount":1.3200000000000002e-7,"serverSeedHash":"aff867a8be94f30f5bd66c7bbf0fa7a85e1c10b187c22fddb93b5efe807cc4e7","payoutMultiplier":0}, mines for this bet id was 3, and 7 . as soon as i clicked on 3. the game should be over . but its not the game shows that i clicked on tiles 4,9,7,1,12,14,24,17,16,15,21,22,20 and 2 . how is this possible . and its not a. autobet which has been placed. this iteration shows that apart from mines on tiles 3,7 the bombs were on rest of the tiles as well. [\b][\u]
stake controls the iteration , later on the bets are deleted citing as archive and the mines field array is filled. [\b][\u]
hence the bet is manipulated. [\b][\u]
when you play mines on 2 mines you will find bomb on the first click this is one of the reasons[\b][\u]
in this game i have got 7 first bomb for mines of 2. what are the chances for that. [\b][\u]
I think you missunderstood the concept of stake bet archive ... That they provide for the customers some service like bet archiver where you can download and check out your bets it's actually nothing which can prove the bet was fair or not. To verify if bet was fair you must have 1. record of the tiles (ordered, per click id) which you opened till busted on mine ( after that game is over) or you won/payed out the game at current nonce. 2. fields where mines were placed on your bet (before unhashed server seed is unrevealed) - you can see it in graphic view of the bet, as well if you more advanced you can check that in your browser network tab as stake actually provide this infrmation on the response request when you bust/cashout/win the round. 3. amount of mines played in specific game (per nonce) 4. unhashed server seed , hashed server seed , client seed , and nonce. And now you can verify the fairness of the specific BET NONCE. As i already wrote, i don't know why that iteration was shown/stored in their Archive bet system, but once again as you have the all data which i listed above you don't even need to have such like bet archive provided by Stake to proof the fairness of the bet or bets. this is the issue with stake archiving the data within 3 -5 days and we revealing the seeds after big nonces . the archive doesn’t show the real esscense of gameplay. the iteration on the back end is clearly something else. also stake.com registered a mines games in two different iteration for same odds. which clearly specify that in the back end there is something wrong. are you aware about hash value hash highway. merkle root verifcation using Benfords laws using merkle trees. Will repear myself for x time.. To verify if bet was fair or not you don't need to have stake archivng... telling you that archiving file which you can download DOES NOT PROOF FAIRNESS OF THE BET... also the iteration which they store there does not prove anything... That what prove the fairness of the bet is that what i mentioned in my previous comment, and you can verify any nonce you played on specific seed from nonce 0 to nonce X after you rotate the seed to get from stake unhashed server seed. merkle root verifcation using Benfords laws using merkle trees. in this case does not have any sense as for stake the base of the calculation is binary outcome of keyed hash value using the HMAC method If you check on stake at provably-fair/implementation they provided the function which they use to generate that binary value and the numbers out of that binary value // Random number generation based on following inputs: serverSeed, clientSeed, nonce and cursor
function byteGenerator({ serverSeed, clientSeed, nonce, cursor }) {
// Setup curser variables
let currentRound = Math.floor(cursor / 32);
let currentRoundCursor = cursor;
currentRoundCursor -= currentRound * 32;
// Generate outputs until cursor requirement fullfilled
while (true) {
// HMAC function used to output provided inputs into bytes
const hmac = createHmac('sha256', serverSeed);
hmac.update(`${clientSeed}:${nonce}:${currentRound}`);
const buffer = hmac.digest();
// Update curser for next iteration of loop
while (currentRoundCursor < 32) {
yield Number(buffer[currentRoundCursor]);
currentRoundCursor += 1;
}
currentRoundCursor = 0;
currentRound += 1;
}
} And i used exactly the same functionality in my code to output that binary value out of the HMAC method.. function byteGenerator(string $serverSeed, string $clientSeed, int $nonce, int $cursor): \Generator
{
// Setup cursor variables
$currentRound = floor($cursor / 32);
$currentRoundCursor = $cursor - ($currentRound * 32);
// Generate outputs until cursor requirement is fulfilled
while (true) {
// Calculate the HMAC
// Initialize the HMAC context
$msg = $clientSeed . ":" . $nonce . ":" . $currentRound;
$hmac = hash_hmac('sha256', $msg, $serverSeed, true);
$hmacBytes = str_split($hmac);
// Update cursor for the next iteration of the loop
while ($currentRoundCursor < 32) {
yield ord($hmacBytes[$currentRoundCursor]); // Yield the number
$currentRoundCursor += 1;
}
$currentRoundCursor = 0;
$currentRound += 1;
}
} |
|
|
|
|
cryptogeniusdice (OP)
Newbie
Offline
Activity: 130
Merit: 0
|
|
September 29, 2023, 09:01:33 PM |
|
dvdx i am at certainity that hiw the games of mines work. but can you proof read the difference between the first and the ssecond iteration also explain me why is it two iterations are so much having difference. and also how come second iteration has 2 mines , in it . so how come so many tiles opened for bombs it clearly specifies over there. also https://onlinephp.io/ can you migrate the program here ans give us a link , so that i can verify if its working or not Will try to explain this to you one more time like to 5 year old. Let's assume i go to mines and wanted to play mine game with 3 minesAt the beggining i known HASHED SERVER SEED , MY SECRET AND NONCE Lets say it's HASHED SERVER SEED = 'e7f3006651ac9fa2252cb6db7de2cfa50e8fb9ff479fd16afd45e9f5fa52c24b'; MY SECRET = 'J8ziLyE0L5'; NONCE = 1; I Started to open mines at position 1st Click "field" : 0, 2nd Click "field" : 6, 3rd Click "field": 12, 4th Click "field": 18, 5th Click "field": 24, 6th Click "field": 21, 7th Click "field": 17, On the 7th Click i busted as mine was uncovered/clicked. Now i want to verify if actually MINE WAS AT THAT POSITION at that game with NONCE 1. So i have rotated the seed to get the output for SERVER SEED , stake output for that string in SERVER SEED UNHASHED = '8935bff6600c9ebb504505757ca881131e5f4a2766e8b0debd687100be6e17c4'; Okay move on now to verify the outcome of the mines for that particular game For that instance I've used the code which i wrote yesterday to verify the mine bet Output of my code (link for you to verify https://onlinephp.io/c/b9616 ) lets verify if my unhashedServerSeed is actually sha256 hashedServerSeed , Result: => bool(true)
Mines postions
Game Nonce:1
0 = 13
1 = 17
2 = 5
3 = 8
4 = 10
5 = 24
6 = 15
7 = 7
8 = 6
9 = 22
10 = 19
11 = 0
12 = 21
13 = 1
14 = 3
15 = 20
16 = 4
17 = 16
18 = 2
19 = 23
20 = 11
21 = 12
22 = 18
23 = 14 Okay so i know that i have played with 3 mines that particular game It means in my game mines positions are 0 = 13 (1st mine position field) 1 = 17 (2nd mine position field) 2 = 5 (3rd mine position field) Okay it clearly shows a mine at position field 17 which i uncovered and busted (as explained above) NOW ASSUME BY SOME REASON STAKE PUT THAT BET TO THE ARCHIVE WITH THE REST OF THE FIELD WHICH I DID NOT OPENED/CLICKED SO IN MY LOGS I SEE "state": {
"mines": [
13,
17,
5
],
"minesCount": 3,
"rounds": [
{
"field": 0,
"payoutMultiplier": 1.125
},
{
"field": 6,
"payoutMultiplier": 1.2857142857142856
},
{
"field": 12,
"payoutMultiplier": 1.4785714285714282
},
{
"field": 18,
"payoutMultiplier": 1.7120300751879696
},
{
"field": 24,
"payoutMultiplier": 1.9973684210526312
},
{
"field": 21,
"payoutMultiplier": 2.3498452012383897
},
{
"field": 17,
"payoutMultiplier": 0
},
{
"field": 1,
"payoutMultiplier": 0
},
{
"field": 2,
"payoutMultiplier": 0
},
{
"field": 3,
"payoutMultiplier": 0
},
{
"field": 4,
"payoutMultiplier": 0
},
{
"field": 5,
"payoutMultiplier": 0
},
{
"field": 7,
"payoutMultiplier": 0
},
{
"field": 8,
"payoutMultiplier": 0
},
{
"field": 9,
"payoutMultiplier": 0
},
{
"field": 10,
"payoutMultiplier": 0
},
{
"field": 11,
"payoutMultiplier": 0
},
{
"field": 13,
"payoutMultiplier": 0
},
{
"field": 14,
"payoutMultiplier": 0
},
{
"field": 15,
"payoutMultiplier": 0
},
{
"field": 16,
"payoutMultiplier": 0
}
{
"field": 19,
"payoutMultiplier": 0
}
]
}Does that log format affect anyhow the result of the game ? NO IT DID NOT 1st . 1. Mines position -> IN THE LOG MINES ARE IN THE SAME ORDER AS IN MY CODE OUTPUT (AFTER VERIFICATION OF BET) 2. ORDER OF FIELDS OPENED IS EXACTLY THE SAME AS MY MANUALL CLICKS TILL I BUSTED ON FIELD 17 the EXTRA DATA FOR OPENED FIELDS DOEST NOT AFFECT ANYTHING AS AT THAT POINT I ALREADY LOST THAT GAME ( WHEN CLICKED MINE AT FIELD 17) So it means even if for some reason the output for fields opened have some EXTRA additional fields which were not clicked, BUT the ORDER OF that which we clicked is OK, it means there is no any manipulation. I don't know how STAKE store the logs for best, but if the ORDER OF THE FIELDS OPENED TILL BUST IS EQUAL TO ACTUALLY CLICKED FIELDS IN GAME AND MINES POSITIONS IS IN THE SAME ORDER IT MEAN THE RESULT IS FAIR. the one which stake has not archived the bet , its showing the correct mines. you still did not understand the question. the problem is the iteration. the point 3 . iteration 1 : iteration 1: {"id":"4199e11e-8861-4b8f-9b43-97ad560cd766","iid":"house:167247337064","type":"casino","scope":"house","userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","betCasino":{"id":"4199e11e-8861-4b8f-9b43-97ad560cd766","active":false,"userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","gameId":"f65ec3b7-705d-42e1-9050 d9ea6fd032b3","currency":"trx","value":0.0000165150794972,"expectedAmount":0.0000020809,"amount":0.00020809,"payoutMultiplier":0,"payout":0,"mobile":false,"serverSeedId":"c7ae0581-091f-4b85-ac5a-9e8e15c5f7b1","clientSeedId":"fc7c4338-e91f-4c13-9cdf-e4475593d7c9","nonce":544,"stateMines":{"_mines":[11,0],"rounds":[{"field":24,"payoutMultiplier":1.076086956521739},{"field":3,"payoutMultiplier":1.1739130434782608},{"field":10,"payoutMultiplier":1.2857142857142859},{"field":9,"payoutMultiplier":1.4142857142857147},{"field":11,"payoutMultiplier":0}],"minesCount":2},"updatedAt":1688820636227,"createdAt":1688820636227}} for this betid the mines and reveal tile is correct. as soon as i clicked the bomb at 11 , the game is over and it’s archived in the system.[/u] whereas for iteration 2 , which was registered in the system .. id":"827819c9-5d9b-4579-a88c-befc0fa54e99","ip":"XXX.YYY.ZZZ.AAA","iid":"house:167250384449","type":"casino","nonce":602,"value":0.0000132,"active":false,"amount":0.0000132,"gameId":"f65ec3b7-705d-42e1-9050-d9ea6fd032b3","mobile":false,"payout":0,"userId":"c3299987-21b5-49ef-bb2b-92a8512912b1","currency":"usdc","gameName":"mines","createdAt":1688821605532,"updatedAt":1688821605532,"clientSeed":"O1zKuEp8081boobs","stateMines":{"_mines":[3,7],"rounds":[{"field":23,"payoutMultiplier":1.076086956521739},{"field":18,"payoutMultiplier":1.1739130434782608},{"field":13,"payoutMultiplier":1.2857142857142858},{"field":5,"payoutMultiplier":1.4142857142857146},{"field":6,"payoutMultiplier":1.5631578947368425},{"field":0,"payoutMultiplier":1.7368421052631584},{"field":1,"payoutMultiplier":1.941176470588236},{"field":2,"payoutMultiplier":2.1838235294117654},{"field":3,"payoutMultiplier":0},{"field":4,"payoutMultiplier":0},{"field":9,"payoutMultiplier":0},{"field":7,"payoutMultiplier":0},{"field":11,"payoutMultiplier":0},{"field":12,"payoutMultiplier":0},{"field":14,"payoutMultiplier":0},{"field":24,"payoutMultiplier":0},{"field":17,"payoutMultiplier":0},{"field":16,"payoutMultiplier":0},{"field":15,"payoutMultiplier":0},{"field":21,"payoutMultiplier":0},{"field":22,"payoutMultiplier":0},{"field":20,"payoutMultiplier":0}],"minesCount":2},"clientSeedId":"fc7c4338-e91f-4c13-9cdf-e4475593d7c9","serverSeedId":"c7ae0581-091f-4b85-ac5a-9e8e15c5f7b1","expectedAmount":1.3200000000000002e-7,"serverSeedHash":"aff867a8be94f30f5bd66c7bbf0fa7a85e1c10b187c22fddb93b5efe807cc4e7","payoutMultiplier":0}, mines for this bet id was 3, and 7 . as soon as i clicked on 3. the game should be over . but its not the game shows that i clicked on tiles 4,9,7,1,12,14,24,17,16,15,21,22,20 and 2 . how is this possible . and its not a. autobet which has been placed. this iteration shows that apart from mines on tiles 3,7 the bombs were on rest of the tiles as well. [\b][\u]
stake controls the iteration , later on the bets are deleted citing as archive and the mines field array is filled. [\b][\u]
hence the bet is manipulated. [\b][\u]
when you play mines on 2 mines you will find bomb on the first click this is one of the reasons[\b][\u]
in this game i have got 7 first bomb for mines of 2. what are the chances for that. [\b][\u]
I think you missunderstood the concept of stake bet archive ... That they provide for the customers some service like bet archiver where you can download and check out your bets it's actually nothing which can prove the bet was fair or not. To verify if bet was fair you must have 1. record of the tiles (ordered, per click id) which you opened till busted on mine ( after that game is over) or you won/payed out the game at current nonce. 2. fields where mines were placed on your bet (before unhashed server seed is unrevealed) - you can see it in graphic view of the bet, as well if you more advanced you can check that in your browser network tab as stake actually provide this infrmation on the response request when you bust/cashout/win the round. 3. amount of mines played in specific game (per nonce) 4. unhashed server seed , hashed server seed , client seed , and nonce. And now you can verify the fairness of the specific BET NONCE. As i already wrote, i don't know why that iteration was shown/stored in their Archive bet system, but once again as you have the all data which i listed above you don't even need to have such like bet archive provided by Stake to proof the fairness of the bet or bets. this is the issue with stake archiving the data within 3 -5 days and we revealing the seeds after big nonces . the archive doesn’t show the real esscense of gameplay. the iteration on the back end is clearly something else. also stake.com registered a mines games in two different iteration for same odds. which clearly specify that in the back end there is something wrong. are you aware about hash value hash highway. merkle root verifcation using Benfords laws using merkle trees. Will repear myself for x time.. To verify if bet was fair or not you don't need to have stake archivng... telling you that archiving file which you can download DOES NOT PROOF FAIRNESS OF THE BET... also the iteration which they store there does not prove anything... That what prove the fairness of the bet is that what i mentioned in my previous comment, and you can verify any nonce you played on specific seed from nonce 0 to nonce X after you rotate the seed to get from stake unhashed server seed. merkle root verifcation using Benfords laws using merkle trees. in this case does not have any sense as for stake the base of the calculation is binary outcome of keyed hash value using the HMAC method If you check on stake at provably-fair/implementation they provided the function which they use to generate that binary value and the numbers out of that binary value // Random number generation based on following inputs: serverSeed, clientSeed, nonce and cursor
function byteGenerator({ serverSeed, clientSeed, nonce, cursor }) {
// Setup curser variables
let currentRound = Math.floor(cursor / 32);
let currentRoundCursor = cursor;
currentRoundCursor -= currentRound * 32;
// Generate outputs until cursor requirement fullfilled
while (true) {
// HMAC function used to output provided inputs into bytes
const hmac = createHmac('sha256', serverSeed);
hmac.update(`${clientSeed}:${nonce}:${currentRound}`);
const buffer = hmac.digest();
// Update curser for next iteration of loop
while (currentRoundCursor < 32) {
yield Number(buffer[currentRoundCursor]);
currentRoundCursor += 1;
}
currentRoundCursor = 0;
currentRound += 1;
}
} And i used exactly the same functionality in my code to output that binary value out of the HMAC method.. function byteGenerator(string $serverSeed, string $clientSeed, int $nonce, int $cursor): \Generator
{
// Setup cursor variables
$currentRound = floor($cursor / 32);
$currentRoundCursor = $cursor - ($currentRound * 32);
// Generate outputs until cursor requirement is fulfilled
while (true) {
// Calculate the HMAC
// Initialize the HMAC context
$msg = $clientSeed . ":" . $nonce . ":" . $currentRound;
$hmac = hash_hmac('sha256', $msg, $serverSeed, true);
$hmacBytes = str_split($hmac);
// Update cursor for the next iteration of the loop
while ($currentRoundCursor < 32) {
yield ord($hmacBytes[$currentRoundCursor]); // Yield the number
$currentRoundCursor += 1;
}
$currentRoundCursor = 0;
$currentRound += 1;
}
} if you are saying that archive filing does not prove fairness of the bet. so why within 2days they archive the bet . and when we search bet it’s shows betid not found. i revolve seeds after a months of play. they archive only few bets which is manipulated or giving you loss on the first tile. this is also a illegal practice by stake.com your php program is good . i didn’t find any issue with the bet which is showing the system. the problem is with the archive bet. they are archiving the bets which they have manipulated and i am 100000percent sure… |
|
|
|
|
cryptogeniusdice (OP)
Newbie
Offline
Activity: 130
Merit: 0
|
|
September 29, 2023, 09:06:21 PM |
|
dvdx
again Benford law can be applied and is much effective with binary data.
you have pulled the program i appreciate it.
but your claims about archive data is absolutely wrong.
archive data you must know how to read.
there is manipualation in the back end of stake.com
hence the automated data which is archive in the back end won’t have such different iteration.
|
|
|
|
|
dvdx1995
Newbie
Offline
Activity: 9
Merit: 4
|
|
September 29, 2023, 09:35:23 PM |
|
dvdx
again Benford law can be applied and is much effective with binary data.
you have pulled the program i appreciate it.
but your claims about archive data is absolutely wrong.
archive data you must know how to read.
The byteGenerator function generates a sequence of numbers based on the given inputs: serverSeed, clientSeed, nonce, and cursor. This function is based on the HMAC-SHA256 algorithm, which is widely used to generate cryptographically secure hashes. There is no obvious connection to Benford's law here, since this law deals with the distribution of the first digits of numeric data, while this function generates a sequence of bytes based on inputs. there is manipualation in the back end of stake.com
hence the automated data which is archive in the back end won’t have such different iteration. Stake give you the results of each of the round played as the game is ended (win or lose) Told you that you can either verify the results by the graphic image of the bet, or inspecting your network tab in the browser to see the outcomes... there is no any time for manipulation in the back end, also if they would manipulate the result you would clearly see it while verifying the bets with the function i provided to you. if you are saying that archive filing does not prove fairness of the bet. so why within 2days they archive the bet . and when we search bet it’s shows betid not found. i revolve seeds after a months of play. they archive only few bets which is manipulated or giving you loss on the first tile.
this is also a illegal practice by stake.com
your php program is good . i didn’t find any issue with the bet which is showing the system.
the problem is with the archive bet.
they are archiving the bets which they have manipulated and i am 100000percent sure… I assume as the amount of bets which they handle every day it may be some delays to generate the file for each of the user and it's unique bets ... Im not behind the stake so i don't know how this process work in their backend to generate this file, but I i'm 101% sure that the file which they genereting to "provide" your bets does not prove the bet fairness.... It is just only to show you the bets which you can't see in your bet history as they limit the history to maximum of 40 last bets... You can create this archive of your bets by your self registering each of your bet places and the outcome by yourself... then rotate your seed to verify the outcome and if you will find any game that have differend results with your own archive then we may assume something is mainpulated.. but since that point you have not proved that they manipulated anything. Your acusation to them is that the iteration is different and some bets are missing in the bet archive file which you can download, but i will repeat this for x time, IT DOES NOT MATTER , as the FAIRNESS OF EACH BET is not based of that what you have in their "archive" but by the factors that i already mentioned to you at least 3 times. |
|
|
|
|
cryptogeniusdice (OP)
Newbie
Offline
Activity: 130
Merit: 0
|
|
September 29, 2023, 10:10:55 PM |
|
dvdx
again Benford law can be applied and is much effective with binary data.
you have pulled the program i appreciate it.
but your claims about archive data is absolutely wrong.
archive data you must know how to read.
The byteGenerator function generates a sequence of numbers based on the given inputs: serverSeed, clientSeed, nonce, and cursor. This function is based on the HMAC-SHA256 algorithm, which is widely used to generate cryptographically secure hashes. There is no obvious connection to Benford's law here, since this law deals with the distribution of the first digits of numeric data, while this function generates a sequence of bytes based on inputs. there is manipualation in the back end of stake.com
hence the automated data which is archive in the back end won’t have such different iteration. Stake give you the results of each of the round played as the game is ended (win or lose) Told you that you can either verify the results by the graphic image of the bet, or inspecting your network tab in the browser to see the outcomes... there is no any time for manipulation in the back end, also if they would manipulate the result you would clearly see it while verifying the bets with the function i provided to you. if you are saying that archive filing does not prove fairness of the bet. so why within 2days they archive the bet . and when we search bet it’s shows betid not found. i revolve seeds after a months of play. they archive only few bets which is manipulated or giving you loss on the first tile.
this is also a illegal practice by stake.com
your php program is good . i didn’t find any issue with the bet which is showing the system.
the problem is with the archive bet.
they are archiving the bets which they have manipulated and i am 100000percent sure… I assume as the amount of bets which they handle every day it may be some delays to generate the file for each of the user and it's unique bets ... Im not behind the stake so i don't know how this process work in their backend to generate this file, but I i'm 101% sure that the file which they genereting to "provide" your bets does not prove the bet fairness.... It is just only to show you the bets which you can't see in your bet history as they limit the history to maximum of 40 last bets... You can create this archive of your bets by your self registering each of your bet places and the outcome by yourself... then rotate your seed to verify the outcome and if you will find any game that have differend results with your own archive then we may assume something is mainpulated.. but since that point you have not proved that they manipulated anything. Your acusation to them is that the iteration is different and some bets are missing in the bet archive file which you can download, but i will repeat this for x time, IT DOES NOT MATTER , as the FAIRNESS OF EACH BET is not based of that what you have in their "archive" but by the factors that i already mentioned to you at least 3 times. looks like you sign up on bitcointalk.org only this post. just kidding. see the fairness can be manioulated by stake it’s happening . hence the archive results are different. if they can manioulate the archive results which means they are purposely deleting the bets . anyways your php script was helpful , but stake.com is manipulating the bets that’s for sure and casino.guru is covering them by spreading all lies about the website. |
|
|
|
|
dvdx1995
Newbie
Offline
Activity: 9
Merit: 4
|
|
September 29, 2023, 10:24:24 PM |
|
dvdx
again Benford law can be applied and is much effective with binary data.
you have pulled the program i appreciate it.
but your claims about archive data is absolutely wrong.
archive data you must know how to read.
The byteGenerator function generates a sequence of numbers based on the given inputs: serverSeed, clientSeed, nonce, and cursor. This function is based on the HMAC-SHA256 algorithm, which is widely used to generate cryptographically secure hashes. There is no obvious connection to Benford's law here, since this law deals with the distribution of the first digits of numeric data, while this function generates a sequence of bytes based on inputs. there is manipualation in the back end of stake.com
hence the automated data which is archive in the back end won’t have such different iteration. Stake give you the results of each of the round played as the game is ended (win or lose) Told you that you can either verify the results by the graphic image of the bet, or inspecting your network tab in the browser to see the outcomes... there is no any time for manipulation in the back end, also if they would manipulate the result you would clearly see it while verifying the bets with the function i provided to you. if you are saying that archive filing does not prove fairness of the bet. so why within 2days they archive the bet . and when we search bet it’s shows betid not found. i revolve seeds after a months of play. they archive only few bets which is manipulated or giving you loss on the first tile.
this is also a illegal practice by stake.com
your php program is good . i didn’t find any issue with the bet which is showing the system.
the problem is with the archive bet.
they are archiving the bets which they have manipulated and i am 100000percent sure… I assume as the amount of bets which they handle every day it may be some delays to generate the file for each of the user and it's unique bets ... Im not behind the stake so i don't know how this process work in their backend to generate this file, but I i'm 101% sure that the file which they genereting to "provide" your bets does not prove the bet fairness.... It is just only to show you the bets which you can't see in your bet history as they limit the history to maximum of 40 last bets... You can create this archive of your bets by your self registering each of your bet places and the outcome by yourself... then rotate your seed to verify the outcome and if you will find any game that have differend results with your own archive then we may assume something is mainpulated.. but since that point you have not proved that they manipulated anything. Your acusation to them is that the iteration is different and some bets are missing in the bet archive file which you can download, but i will repeat this for x time, IT DOES NOT MATTER , as the FAIRNESS OF EACH BET is not based of that what you have in their "archive" but by the factors that i already mentioned to you at least 3 times. looks like you sign up on bitcointalk.org only this post. just kidding. see the fairness can be manioulated by stake it’s happening . hence the archive results are different. if they can manioulate the archive results which means they are purposely deleting the bets . anyways your php script was helpful , but stake.com is manipulating the bets that’s for sure and casino.guru is covering them by spreading all lies about the website. Alright, so even though the facts and arguments presented to you, as well as the solutions on how you can verify each game fairness, don't seem to convince you, you still remain stubborn and believe you know best. Despite zero evidence of any manipulation, you insist that black is white.. I provided you with all the possibilities and data you need to verify each bet, also those which you have in your archive of bets and compare it with what the function calculating the occurrence of mines (sorted from 1 to 24 mines) returns... and you haven't provided any specific bet where manipulation is evident... Nevertheless, I wish you a good day and good luck. As I mentioned before, and as other users have confirmed in your previous topics, there doesn't appear to be any manipulation of bets here. From my side, that's all. |
|
|
|
|
cryptogeniusdice (OP)
Newbie
Offline
Activity: 130
Merit: 0
|
|
September 29, 2023, 10:46:17 PM |
|
dvdx
again Benford law can be applied and is much effective with binary data.
you have pulled the program i appreciate it.
but your claims about archive data is absolutely wrong.
archive data you must know how to read.
The byteGenerator function generates a sequence of numbers based on the given inputs: serverSeed, clientSeed, nonce, and cursor. This function is based on the HMAC-SHA256 algorithm, which is widely used to generate cryptographically secure hashes. There is no obvious connection to Benford's law here, since this law deals with the distribution of the first digits of numeric data, while this function generates a sequence of bytes based on inputs. there is manipualation in the back end of stake.com
hence the automated data which is archive in the back end won’t have such different iteration. Stake give you the results of each of the round played as the game is ended (win or lose) Told you that you can either verify the results by the graphic image of the bet, or inspecting your network tab in the browser to see the outcomes... there is no any time for manipulation in the back end, also if they would manipulate the result you would clearly see it while verifying the bets with the function i provided to you. if you are saying that archive filing does not prove fairness of the bet. so why within 2days they archive the bet . and when we search bet it’s shows betid not found. i revolve seeds after a months of play. they archive only few bets which is manipulated or giving you loss on the first tile.
this is also a illegal practice by stake.com
your php program is good . i didn’t find any issue with the bet which is showing the system.
the problem is with the archive bet.
they are archiving the bets which they have manipulated and i am 100000percent sure… I assume as the amount of bets which they handle every day it may be some delays to generate the file for each of the user and it's unique bets ... Im not behind the stake so i don't know how this process work in their backend to generate this file, but I i'm 101% sure that the file which they genereting to "provide" your bets does not prove the bet fairness.... It is just only to show you the bets which you can't see in your bet history as they limit the history to maximum of 40 last bets... You can create this archive of your bets by your self registering each of your bet places and the outcome by yourself... then rotate your seed to verify the outcome and if you will find any game that have differend results with your own archive then we may assume something is mainpulated.. but since that point you have not proved that they manipulated anything. Your acusation to them is that the iteration is different and some bets are missing in the bet archive file which you can download, but i will repeat this for x time, IT DOES NOT MATTER , as the FAIRNESS OF EACH BET is not based of that what you have in their "archive" but by the factors that i already mentioned to you at least 3 times. looks like you sign up on bitcointalk.org only this post. just kidding. see the fairness can be manioulated by stake it’s happening . hence the archive results are different. if they can manioulate the archive results which means they are purposely deleting the bets . anyways your php script was helpful , but stake.com is manipulating the bets that’s for sure and casino.guru is covering them by spreading all lies about the website. Alright, so even though the facts and arguments presented to you, as well as the solutions on how you can verify each game fairness, don't seem to convince you, you still remain stubborn and believe you know best. Despite zero evidence of any manipulation, you insist that black is white.. I provided you with all the possibilities and data you need to verify each bet, also those which you have in your archive of bets and compare it with what the function calculating the occurrence of mines (sorted from 1 to 24 mines) returns... and you haven't provided any specific bet where manipulation is evident... Nevertheless, I wish you a good day and good luck. As I mentioned before, and as other users have confirmed in your previous topics, there doesn't appear to be any manipulation of bets here. From my side, that's all. looks like your profile was created only to comment on this bet,post 28th sept. go ahead and compare iteration in point 3 of the post. how can i open 13 bombs on mines games of 2 bombs. |
|
|
|
|
cryptogeniusdice (OP)
Newbie
Offline
Activity: 130
Merit: 0
|
|
September 29, 2023, 10:47:47 PM |
|
and moreover you are saying the archive bets data is not usually provably fair.
what bullshit you are saying man.
|
|
|
|
|
dvdx1995
Newbie
Offline
Activity: 9
Merit: 4
|
|
September 29, 2023, 10:58:40 PM |
|
dvdx
again Benford law can be applied and is much effective with binary data.
you have pulled the program i appreciate it.
but your claims about archive data is absolutely wrong.
archive data you must know how to read.
The byteGenerator function generates a sequence of numbers based on the given inputs: serverSeed, clientSeed, nonce, and cursor. This function is based on the HMAC-SHA256 algorithm, which is widely used to generate cryptographically secure hashes. There is no obvious connection to Benford's law here, since this law deals with the distribution of the first digits of numeric data, while this function generates a sequence of bytes based on inputs. there is manipualation in the back end of stake.com
hence the automated data which is archive in the back end won’t have such different iteration. Stake give you the results of each of the round played as the game is ended (win or lose) Told you that you can either verify the results by the graphic image of the bet, or inspecting your network tab in the browser to see the outcomes... there is no any time for manipulation in the back end, also if they would manipulate the result you would clearly see it while verifying the bets with the function i provided to you. if you are saying that archive filing does not prove fairness of the bet. so why within 2days they archive the bet . and when we search bet it’s shows betid not found. i revolve seeds after a months of play. they archive only few bets which is manipulated or giving you loss on the first tile.
this is also a illegal practice by stake.com
your php program is good . i didn’t find any issue with the bet which is showing the system.
the problem is with the archive bet.
they are archiving the bets which they have manipulated and i am 100000percent sure… I assume as the amount of bets which they handle every day it may be some delays to generate the file for each of the user and it's unique bets ... Im not behind the stake so i don't know how this process work in their backend to generate this file, but I i'm 101% sure that the file which they genereting to "provide" your bets does not prove the bet fairness.... It is just only to show you the bets which you can't see in your bet history as they limit the history to maximum of 40 last bets... You can create this archive of your bets by your self registering each of your bet places and the outcome by yourself... then rotate your seed to verify the outcome and if you will find any game that have differend results with your own archive then we may assume something is mainpulated.. but since that point you have not proved that they manipulated anything. Your acusation to them is that the iteration is different and some bets are missing in the bet archive file which you can download, but i will repeat this for x time, IT DOES NOT MATTER , as the FAIRNESS OF EACH BET is not based of that what you have in their "archive" but by the factors that i already mentioned to you at least 3 times. looks like you sign up on bitcointalk.org only this post. just kidding. see the fairness can be manioulated by stake it’s happening . hence the archive results are different. if they can manioulate the archive results which means they are purposely deleting the bets . anyways your php script was helpful , but stake.com is manipulating the bets that’s for sure and casino.guru is covering them by spreading all lies about the website. Alright, so even though the facts and arguments presented to you, as well as the solutions on how you can verify each game fairness, don't seem to convince you, you still remain stubborn and believe you know best. Despite zero evidence of any manipulation, you insist that black is white.. I provided you with all the possibilities and data you need to verify each bet, also those which you have in your archive of bets and compare it with what the function calculating the occurrence of mines (sorted from 1 to 24 mines) returns... and you haven't provided any specific bet where manipulation is evident... Nevertheless, I wish you a good day and good luck. As I mentioned before, and as other users have confirmed in your previous topics, there doesn't appear to be any manipulation of bets here. From my side, that's all. looks like your profile was created only to comment on this bet,post 28th sept. go ahead and compare iteration in point 3 of the post. how can i open 13 bombs on mines games of 2 bombs. Yes and what is the point about my account, i opened exatyly because i wanted to explain you how this system works , how you can verify each of the bet, i even provided for you OPEN SOURCE CODE which everyone can see and verify if it returns correct results .. just wanted to be helpfull .. however, you are like a parrot repeating the same thing over and over again. and moreover you are saying the archive bets data is not usually provably fair.
what bullshit you are saying man.
Please read once again my comments on this topic and i hope you will understand WHY ARCHIVE BETS DOES NOT PROVE FAIRNESS .. HOW ARCHIVE CAN PROVE FAIRNESS IF YOU DONT KNOW SERVER SEED ?? THEY ARCHIVE BETS DAILY AND I DO NOT FIND ANY INFORMATION ABOUT UNHASHED SERVER SEED SO IF THAT ARICHVE IN YOUR OPINION PROVIDE A FAIRNESS HOW YOU CAN CALCULATE IT WITHOUT SERVER SEED ?? Last comment on that. Wish you to have a good day. |
|
|
|
|
cryptogeniusdice (OP)
Newbie
Offline
Activity: 130
Merit: 0
|
|
September 30, 2023, 02:00:12 AM |
|
dvdx
again Benford law can be applied and is much effective with binary data.
you have pulled the program i appreciate it.
but your claims about archive data is absolutely wrong.
archive data you must know how to read.
The byteGenerator function generates a sequence of numbers based on the given inputs: serverSeed, clientSeed, nonce, and cursor. This function is based on the HMAC-SHA256 algorithm, which is widely used to generate cryptographically secure hashes. There is no obvious connection to Benford's law here, since this law deals with the distribution of the first digits of numeric data, while this function generates a sequence of bytes based on inputs. there is manipualation in the back end of stake.com
hence the automated data which is archive in the back end won’t have such different iteration. Stake give you the results of each of the round played as the game is ended (win or lose) Told you that you can either verify the results by the graphic image of the bet, or inspecting your network tab in the browser to see the outcomes... there is no any time for manipulation in the back end, also if they would manipulate the result you would clearly see it while verifying the bets with the function i provided to you. if you are saying that archive filing does not prove fairness of the bet. so why within 2days they archive the bet . and when we search bet it’s shows betid not found. i revolve seeds after a months of play. they archive only few bets which is manipulated or giving you loss on the first tile.
this is also a illegal practice by stake.com
your php program is good . i didn’t find any issue with the bet which is showing the system.
the problem is with the archive bet.
they are archiving the bets which they have manipulated and i am 100000percent sure… I assume as the amount of bets which they handle every day it may be some delays to generate the file for each of the user and it's unique bets ... Im not behind the stake so i don't know how this process work in their backend to generate this file, but I i'm 101% sure that the file which they genereting to "provide" your bets does not prove the bet fairness.... It is just only to show you the bets which you can't see in your bet history as they limit the history to maximum of 40 last bets... You can create this archive of your bets by your self registering each of your bet places and the outcome by yourself... then rotate your seed to verify the outcome and if you will find any game that have differend results with your own archive then we may assume something is mainpulated.. but since that point you have not proved that they manipulated anything. Your acusation to them is that the iteration is different and some bets are missing in the bet archive file which you can download, but i will repeat this for x time, IT DOES NOT MATTER , as the FAIRNESS OF EACH BET is not based of that what you have in their "archive" but by the factors that i already mentioned to you at least 3 times. looks like you sign up on bitcointalk.org only this post. just kidding. see the fairness can be manioulated by stake it’s happening . hence the archive results are different. if they can manioulate the archive results which means they are purposely deleting the bets . anyways your php script was helpful , but stake.com is manipulating the bets that’s for sure and casino.guru is covering them by spreading all lies about the website. Alright, so even though the facts and arguments presented to you, as well as the solutions on how you can verify each game fairness, don't seem to convince you, you still remain stubborn and believe you know best. Despite zero evidence of any manipulation, you insist that black is white.. I provided you with all the possibilities and data you need to verify each bet, also those which you have in your archive of bets and compare it with what the function calculating the occurrence of mines (sorted from 1 to 24 mines) returns... and you haven't provided any specific bet where manipulation is evident... Nevertheless, I wish you a good day and good luck. As I mentioned before, and as other users have confirmed in your previous topics, there doesn't appear to be any manipulation of bets here. From my side, that's all. looks like your profile was created only to comment on this bet,post 28th sept. go ahead and compare iteration in point 3 of the post. how can i open 13 bombs on mines games of 2 bombs. Yes and what is the point about my account, i opened exatyly because i wanted to explain you how this system works , how you can verify each of the bet, i even provided for you OPEN SOURCE CODE which everyone can see and verify if it returns correct results .. just wanted to be helpfull .. however, you are like a parrot repeating the same thing over and over again. and moreover you are saying the archive bets data is not usually provably fair.
what bullshit you are saying man.
Please read once again my comments on this topic and i hope you will understand WHY ARCHIVE BETS DOES NOT PROVE FAIRNESS .. HOW ARCHIVE CAN PROVE FAIRNESS IF YOU DONT KNOW SERVER SEED ?? THEY ARCHIVE BETS DAILY AND I DO NOT FIND ANY INFORMATION ABOUT UNHASHED SERVER SEED SO IF THAT ARICHVE IN YOUR OPINION PROVIDE A FAIRNESS HOW YOU CAN CALCULATE IT WITHOUT SERVER SEED ?? Last comment on that. Wish you to have a good day. I know you are from Casinoguru.com . seem you went on length to lie about relation between provablyfair.me and stake.com .lied to me about 400 million dollar law suit against stake.com freeman vs stake if it was in my control , i won’t let casino archive the bet. but unfortunately it’s stake scam policy to archive the bets and the back end automatically registers the bet. stake archive those bets randomly or by practice of fooling people. i found the iteration registered in the back end for mines 2 placed as 11 . then i am the problem here ?? even 3 support agent revelaed that the mines registered for one of the bets were 11 , when orignally placed for 2 l so basically casinoguru just took information from me and therby just to damage control the reputation of stake.com ============================================================================ Do. not trust casino,guru they collude with casino and lie and provide false information to customers https://casino.guru/stake-casino-player-alleges-bet-manipulation-at-stake-comprovided them with all proof , they fail to investigate the back end of the casino which is linked to the same umbrella comoany. they are liars. |
|
|
|
|
holydarkness
Legendary
Offline
Activity: 2520
Merit: 1406
Yes, I'm an asshole
|
|
September 30, 2023, 03:55:20 AM |
|
No, the problem here is you being too stubborn to see that you made mistake and misunderstand things. Many, way too many people tried to help contributing to this case, allocating their time to inform you what exactly happened, how to verify bets, etc. and yet you still insist to stick to what you believe, despite all of the facts.
My friend the problem is not the OP's topic, it's his narrative. No one came out and said no this this this you are wrong. Stake and CG are father and child companies. I have and had every proof and stake didn't even bother to give an answer because they don't need to. They have a fan base of spastic people who don't even know how to earn a living, won from crypto; childs. I hate that no one blames stake but only players; this is how payroll works i believe.(I'm not talking about you.) As you can see from the very long and detailed exchange of posts above, the problem is OP being too stubborn. He insisted on things that he assumed to be correct and forced perspective based on what he believe, no matter how many people tried to explain to him and the length they took to help him understood his situation. Everybody that come to his case started nicely and politely, tried to explain what exactly happened, and then OP... well... [...]
Last comment on that. Wish you to have a good day.
Here's the popcorn, there's the seats, feel free to join the rest of us and enjoy the show. |
|
|
|
cryptogeniusdice (OP)
Newbie
Offline
Activity: 130
Merit: 0
|
|
September 30, 2023, 04:57:44 AM |
|
No, the problem here is you being too stubborn to see that you made mistake and misunderstand things. Many, way too many people tried to help contributing to this case, allocating their time to inform you what exactly happened, how to verify bets, etc. and yet you still insist to stick to what you believe, despite all of the facts.
My friend the problem is not the OP's topic, it's his narrative. No one came out and said no this this this you are wrong. Stake and CG are father and child companies. I have and had every proof and stake didn't even bother to give an answer because they don't need to. They have a fan base of spastic people who don't even know how to earn a living, won from crypto; childs. I hate that no one blames stake but only players; this is how payroll works i believe.(I'm not talking about you.) As you can see from the very long and detailed exchange of posts above, the problem is OP being too stubborn. He insisted on things that he assumed to be correct and forced perspective based on what he believe, no matter how many people tried to explain to him and the length they took to help him understood his situation. Everybody that come to his case started nicely and politely, tried to explain what exactly happened, and then OP... well... [...]
Last comment on that. Wish you to have a good day.
Here's the popcorn, there's the seats, feel free to join the rest of us and enjoy the show. well we’ll whose here. do me a favour compare both the iterations under point . then say provablyfair.me and stake.com and seperate entities and then say stake.com do not have. a 400 million lawsuit against them then claim casino.guru findings are true right , this is what you have been doing right holydarkness is in your mind. still none you explained how on archive bet of 2 mines i can open 12 bombs playing manually |
|
|
|
|
holydarkness
Legendary
Offline
Activity: 2520
Merit: 1406
Yes, I'm an asshole
|
|
September 30, 2023, 06:38:25 AM |
|
well we’ll whose here.
do me a favour compare both the iterations under point .
then say provablyfair.me and stake.com and seperate entities and then say stake.com do not have. a 400 million lawsuit against them
then claim casino.guru findings are true
right , this is what you have been doing right
holydarkness is in your mind.
still none you explained how on archive bet of 2 mines i can open 12 bombs playing manually
And to what outcome will it bring us? dvdx1995 had spent a lot of effort explaining everything to you, including those question you asked, and you still managed to shrug it off as Stake's fault... and CG's. |
|
|
|
|
