^ Yeah, what Dooglus said.
Basically the "client seed" is a single value which is used throughout the whole chain. It's there to prevent against an attack in which I unfairly picked a hash chain (as no one knows how I seeded the hash chain). In order to come up with a client seed, we had have a few options. One obvious option would be used a trusted third party (e.g. random.org) but we can do better, by using the bitcoin blockchain itself.
The way it was done (see: the start of this thread) was preannounce that what ever hash block 339300 is going to be, would be our client seed. As we conducted this well in advance of block 339300, there was absolutely no way I (or anyone) could have known what that hash would be.
Typically when you use bitcoin block hashes, you need to be careful against what is known as a "discarding attack" where a bitcoin miner can look at the hash and decide to not publish the block. However in this case, the attack isn't relevant because the low chance of conducting it (what ever hash power I control), and the cost of conducting would've been 25 BTC, and to significantly bias the results would take at least millions (or billions) of attempts.
So I think we can be quite confident that the seed was fairly picked and there's no issues with it =)
Topic: Bustabit.com Provably Fair Seeding Event (Read 49532 times)
I saw that this 10 BTC was recently moved away last month. I assume this doesn't mean that someone was able to compromised the address and it was just moved after being satisfied that it was not compromised after this time?
Yeah, I just moved as part of my on-going campaign to reconcile my finances. If anyone does however know the private key, (or any of the future hashes) I'll more than happily give you a lot more than that in a bounty (i offered Dexon 50 btc if his brute force sha1 program actually does find it) as if someone did find it, it'd easily cost me more than that (as they would know the outcome of all future games)
Sorry if posting at wrong place, I can move the post
I read a post from 2018 I think that said the version 2 of bustabit will not crash anymore at 1.00, today in 2020 it does crash frequently at 1.00, so this part of V2 was chaged?
I also read that Should the game crash at 0x, all bets will be refunded which also does not seems to be the case today.
So why are things different than they were described in this forum in the past?
Thanks for any clarification
As you can see in the provably fair algorithmI read a post from 2018 I think that said the version 2 of bustabit will not crash anymore at 1.00, today in 2020 it does crash frequently at 1.00, so this part of V2 was chaged?
I also read that Should the game crash at 0x, all bets will be refunded which also does not seems to be the case today.
So why are things different than they were described in this forum in the past?
Thanks for any clarification
R = 99 / (1-X) with X uniformly distributed on [0;1]
R is then divided by 100 to get the crash multiplier but only the MAX between 1 and R/100 is taken.
That means every time X is =< 0.01 you will get a final crash multiplier equal to 1.
eg : 99/(1-0.01)=99/0.99=100
Code:
// 3. X = r / 2^52
let X = r / Math.pow(2, nBits) // uniformly distributed in [0; 1)
// 4. X = 99 / (1-X)
X = 99 / (1 - X)
// 5. return max(trunc(X), 100)
const result = Math.floor(X)
return Math.max(1, result / 100)
let X = r / Math.pow(2, nBits) // uniformly distributed in [0; 1)
// 4. X = 99 / (1-X)
X = 99 / (1 - X)
// 5. return max(trunc(X), 100)
const result = Math.floor(X)
return Math.max(1, result / 100)
Sorry if posting at wrong place, I can move the post
I read a post from 2018 I think that said the version 2 of bustabit will not crash anymore at 1.00, today in 2020 it does crash frequently at 1.00, so this part of V2 was chaged?
I also read that Should the game crash at 0x, all bets will be refunded which also does not seems to be the case today.
So why are things different than they were described in this forum in the past?
Thanks for any clarification
I read a post from 2018 I think that said the version 2 of bustabit will not crash anymore at 1.00, today in 2020 it does crash frequently at 1.00, so this part of V2 was chaged?
I also read that Should the game crash at 0x, all bets will be refunded which also does not seems to be the case today.
So why are things different than they were described in this forum in the past?
Thanks for any clarification
It was never said the BaB V2 cant crash at 1.0. It does and that was never up for a discussion.
I think the first BaB could crash at 0, which did something for the odds I thought.
I understand that and thats why I went to check on the live game and noticed that indeed it crash at 1.00 frequently.
I would have to read again all of one major Bustabit thread to find it, but it was at time of the announcement of the V2 version,
For the bets refunded when it crash at 1.00, I found that during a google search.
[/quote]
Can you share with us that post which shows that V2 of Bustabit will never crash on 1.00.
If this happens and i auto cash out on 1.01 always, then it would mean that i could not lose the bet and slowly my bankroll willl increase without any
risk
[/quote]
I would have to read again all of one major Bustabit thread to find it, but it was at time of the announcement of the V2 version,
For the bets refunded when it crash at 1.00, I found that during a google search.
[/quote]
Can you share with us that post which shows that V2 of Bustabit will never crash on 1.00.
If this happens and i auto cash out on 1.01 always, then it would mean that i could not lose the bet and slowly my bankroll willl increase without any
risk
[/quote]
Sorry if posting at wrong place, I can move the post
I read a post from 2018 I think that said the version 2 of bustabit will not crash anymore at 1.00, today in 2020 it does crash frequently at 1.00, so this part of V2 was chaged?
I also read that Should the game crash at 0x, all bets will be refunded which also does not seems to be the case today.
So why are things different than they were described in this forum in the past?
Thanks for any clarification
I read a post from 2018 I think that said the version 2 of bustabit will not crash anymore at 1.00, today in 2020 it does crash frequently at 1.00, so this part of V2 was chaged?
I also read that Should the game crash at 0x, all bets will be refunded which also does not seems to be the case today.
So why are things different than they were described in this forum in the past?
Thanks for any clarification
Can you share with us that post which shows that V2 of Bustabit will never crash on 1.00.
If this happens and i auto cash out on 1.01 always, then it would mean that i could not lose the bet and slowly my bankroll willl increase without any
risk
Sorry if posting at wrong place, I can move the post
I read a post from 2018 I think that said the version 2 of bustabit will not crash anymore at 1.00, today in 2020 it does crash frequently at 1.00, so this part of V2 was chaged?
I also read that Should the game crash at 0x, all bets will be refunded which also does not seems to be the case today.
So why are things different than they were described in this forum in the past?
Thanks for any clarification
I read a post from 2018 I think that said the version 2 of bustabit will not crash anymore at 1.00, today in 2020 it does crash frequently at 1.00, so this part of V2 was chaged?
I also read that Should the game crash at 0x, all bets will be refunded which also does not seems to be the case today.
So why are things different than they were described in this forum in the past?
Thanks for any clarification
Welcome to the first provably fair seeding event. One of the most requested features of bustabit has been to create a provably distribution of game crashes, to replace our provably predetermined multipliers.
The original scheme of turning a multiplayer game in which peers do not trust each other was first proposed by Dooglus, refined by Eric and solidified into code by Steve.
The high level of the scheme is as follows:
1) We have generated a chain of 10 million sha256 hashes, starting with a server secret that has been repeatedly fed the output of sha256 back into itself 10 million times. The sha256 of the final hash in the chain is: c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d, by publicising it here we are preventing any ability to pick an alternate sha256 chain.
2) Bustabit will play through that chain of hashes, in reverse order, and use the hashes to determine the crash point in a probably fair manner.
3) To avoid criticism that the Bitcoin address used in step 1 was carefully chosen to generate lots of "bad" crash points, each hash in the chain will be salted with a client seed, which we have no control of. The client seed will be the block hash of a Bitcoin block that hasn't yet been mined: block 339300.
The reference code (javascript) is as follows:
The method to create the hash chain is simply sha256:
The method to convert a game hash, mix it with the picked client seed to a money pot multiplier:
The chain could be generated with code such as:
Using our chosen starting serverSeed, the hash terminating the chain is c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d. That is to say, the first game's hash played under the new provably fair scheme, when hashed will be c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d.
The original scheme of turning a multiplayer game in which peers do not trust each other was first proposed by Dooglus, refined by Eric and solidified into code by Steve.
The high level of the scheme is as follows:
1) We have generated a chain of 10 million sha256 hashes, starting with a server secret that has been repeatedly fed the output of sha256 back into itself 10 million times. The sha256 of the final hash in the chain is: c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d, by publicising it here we are preventing any ability to pick an alternate sha256 chain.
2) Bustabit will play through that chain of hashes, in reverse order, and use the hashes to determine the crash point in a probably fair manner.
3) To avoid criticism that the Bitcoin address used in step 1 was carefully chosen to generate lots of "bad" crash points, each hash in the chain will be salted with a client seed, which we have no control of. The client seed will be the block hash of a Bitcoin block that hasn't yet been mined: block 339300.
The reference code (javascript) is as follows:
The method to create the hash chain is simply sha256:
Code:
function genGameHash(serverSeed) {
return crypto.createHash('sha256').update(serverSeed).digest('hex');
}
return crypto.createHash('sha256').update(serverSeed).digest('hex');
}
The method to convert a game hash, mix it with the picked client seed to a money pot multiplier:
Code:
function crashPointFromHash(serverSeed, clientSeed) {
function divisible(hash, mod) {
// We will read in 4 hex at a time, but the first chunk might be a bit smaller
// So ABCDEFGHIJ should be chunked like AB CDEF GHIJ
var val = 0;
var o = hash.length % 4;
for (var i = o > 0 ? o - 4 : 0; i < hash.length; i += 4) {
val = ((val << 16) + parseInt(hash.substring(i, i+4), 16)) % mod;
}
return val === 0;
}
var hash = crypto.createHmac('sha256', serverSeed).update(clientSeed).digest('hex');
/* In 1 of 101 games the game crashes instantly. */
if (divisible(hash, 101))
return 0;
/* Use the most significant 52-bit from the hash
to calculate the crash point */
var h = parseInt(hash.slice(0,52/4),16);
var e = Math.pow(2,52);
return Math.floor((100 * e - h) / (e - h));
}
function divisible(hash, mod) {
// We will read in 4 hex at a time, but the first chunk might be a bit smaller
// So ABCDEFGHIJ should be chunked like AB CDEF GHIJ
var val = 0;
var o = hash.length % 4;
for (var i = o > 0 ? o - 4 : 0; i < hash.length; i += 4) {
val = ((val << 16) + parseInt(hash.substring(i, i+4), 16)) % mod;
}
return val === 0;
}
var hash = crypto.createHmac('sha256', serverSeed).update(clientSeed).digest('hex');
/* In 1 of 101 games the game crashes instantly. */
if (divisible(hash, 101))
return 0;
/* Use the most significant 52-bit from the hash
to calculate the crash point */
var h = parseInt(hash.slice(0,52/4),16);
var e = Math.pow(2,52);
return Math.floor((100 * e - h) / (e - h));
}
The chain could be generated with code such as:
Code:
var serverSecret = 'If you knew this, you could steal all my money';
var clientSeed = '0000examplehash';
var gamesToGenerate = 1e7;
var serverSeed = serverSecret;
for (var game = gamesToGenerate; game > 0; --game) {
serverSeed = genGameHash(serverSeed);
console.log('Game ' + game + ' has a crash point of ' + (crashPointFromHash(serverSeed, clientSeed) / 100).toFixed(2) +'x', '\t\tHash: ' + serverSeed);
}
var terminatingHash = genGameHash(serverSeed);
console.log('The terminating hash is: ', terminatingHash);
var clientSeed = '0000examplehash';
var gamesToGenerate = 1e7;
var serverSeed = serverSecret;
for (var game = gamesToGenerate; game > 0; --game) {
serverSeed = genGameHash(serverSeed);
console.log('Game ' + game + ' has a crash point of ' + (crashPointFromHash(serverSeed, clientSeed) / 100).toFixed(2) +'x', '\t\tHash: ' + serverSeed);
}
var terminatingHash = genGameHash(serverSeed);
console.log('The terminating hash is: ', terminatingHash);
Using our chosen starting serverSeed, the hash terminating the chain is c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d. That is to say, the first game's hash played under the new provably fair scheme, when hashed will be c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d.
hello are u mod in there i need help right now
Hehe, funny to play but will small amounts.
Got recenty @ 20x. Sent $0,5, cashed about total $40. Enough for nice dinner with gf.
Got recenty @ 20x. Sent $0,5, cashed about total $40. Enough for nice dinner with gf.
So I think we can be quite confident that the seed was fairly picked
do you call this scam FARE !!!!!!!
(just kidding)
If I get the hash of a game, how do I determine what block hash(clientseed) was used? How do you get the block hash(clientseed), the timing of it being used is unknown?
There was only one seeding event. Only a single block hash was used.
The client seed is 000000000000000007a9a31ff7f07463d91af6b5454241d5faf282e5e0fe1b3a, as mentioned in this post.
Did you read my post which tries to make the process clearer? Does it help?
Rayn
If I get the hash of a game, how do I determine what block hash(clientseed) was used? How do you get the block hash(clientseed), the timing of it being used is unknown?
If I get the hash of a game, how do I determine what block hash(clientseed) was used? How do you get the block hash(clientseed), the timing of it being used is unknown?
if bitcoin is still around at the end of the week, i'll check it out
Lol why do you say that ? Of coarse it will still be around silly
Its good to see vista bit doing this to renenforce the fairness factor. Personally I have never felt cheated. I just day "omg bs" lol but everyone in the room loses as well so ita not like its just me so in that way its actually great to prove fairness.
I dont know Ryan personally but he really doesn't seem the kind to steal. He knows how to conduct business and this is clearly demonstrated by the success of bustabit. People who run and only shooting the!selves in the foot. Why run why you can simply keep at it and create a lovely passive income in the long term.
Do not eat everything today for tomorrow is a new day. Runners eat everything in one day and forget about the future. They could have made much more but they have no foresight. Ryan knows this so he makes more then these runners. Well done Ryan. Also ita a very fun unique game.
Welcome to the first provably fair seeding event. One of the most requested features of bustabit has been to create a provably distribution of game crashes, to replace our provably predetermined multipliers.
The original scheme of turning a multiplayer game in which peers do not trust each other was first proposed by Dooglus, refined by Eric and solidified into code by Steve.
The high level of the scheme is as follows:
1) We have generated a chain of 10 million sha256 hashes, starting with a server secret that has been repeatedly fed the output of sha256 back into itself 10 million times. The sha256 of the final hash in the chain is: c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d, by publicising it here we are preventing any ability to pick an alternate sha256 chain.
2) Bustabit will play through that chain of hashes, in reverse order, and use the hashes to determine the crash point in a probably fair manner.
3) To avoid criticism that the Bitcoin address used in step 1 was carefully chosen to generate lots of "bad" crash points, each hash in the chain will be salted with a client seed, which we have no control of. The client seed will be the block hash of a Bitcoin block that hasn't yet been mined: block 339300.
The reference code (javascript) is as follows:
The method to create the hash chain is simply sha256:
The method to convert a game hash, mix it with the picked client seed to a money pot multiplier:
The chain could be generated with code such as:
Using our chosen starting serverSeed, the hash terminating the chain is c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d. That is to say, the first game's hash played under the new provably fair scheme, when hashed will be c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d.
The original scheme of turning a multiplayer game in which peers do not trust each other was first proposed by Dooglus, refined by Eric and solidified into code by Steve.
The high level of the scheme is as follows:
1) We have generated a chain of 10 million sha256 hashes, starting with a server secret that has been repeatedly fed the output of sha256 back into itself 10 million times. The sha256 of the final hash in the chain is: c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d, by publicising it here we are preventing any ability to pick an alternate sha256 chain.
2) Bustabit will play through that chain of hashes, in reverse order, and use the hashes to determine the crash point in a probably fair manner.
3) To avoid criticism that the Bitcoin address used in step 1 was carefully chosen to generate lots of "bad" crash points, each hash in the chain will be salted with a client seed, which we have no control of. The client seed will be the block hash of a Bitcoin block that hasn't yet been mined: block 339300.
The reference code (javascript) is as follows:
The method to create the hash chain is simply sha256:
Code:
function genGameHash(serverSeed) {
return crypto.createHash('sha256').update(serverSeed).digest('hex');
}
return crypto.createHash('sha256').update(serverSeed).digest('hex');
}
The method to convert a game hash, mix it with the picked client seed to a money pot multiplier:
Code:
function crashPointFromHash(serverSeed, clientSeed) {
function divisible(hash, mod) {
// We will read in 4 hex at a time, but the first chunk might be a bit smaller
// So ABCDEFGHIJ should be chunked like AB CDEF GHIJ
var val = 0;
var o = hash.length % 4;
for (var i = o > 0 ? o - 4 : 0; i < hash.length; i += 4) {
val = ((val << 16) + parseInt(hash.substring(i, i+4), 16)) % mod;
}
return val === 0;
}
var hash = crypto.createHmac('sha256', serverSeed).update(clientSeed).digest('hex');
/* In 1 of 101 games the game crashes instantly. */
if (divisible(hash, 101))
return 0;
/* Use the most significant 52-bit from the hash
to calculate the crash point */
var h = parseInt(hash.slice(0,52/4),16);
var e = Math.pow(2,52);
return Math.floor((100 * e - h) / (e - h));
}
function divisible(hash, mod) {
// We will read in 4 hex at a time, but the first chunk might be a bit smaller
// So ABCDEFGHIJ should be chunked like AB CDEF GHIJ
var val = 0;
var o = hash.length % 4;
for (var i = o > 0 ? o - 4 : 0; i < hash.length; i += 4) {
val = ((val << 16) + parseInt(hash.substring(i, i+4), 16)) % mod;
}
return val === 0;
}
var hash = crypto.createHmac('sha256', serverSeed).update(clientSeed).digest('hex');
/* In 1 of 101 games the game crashes instantly. */
if (divisible(hash, 101))
return 0;
/* Use the most significant 52-bit from the hash
to calculate the crash point */
var h = parseInt(hash.slice(0,52/4),16);
var e = Math.pow(2,52);
return Math.floor((100 * e - h) / (e - h));
}
The chain could be generated with code such as:
Code:
var serverSecret = 'If you knew this, you could steal all my money';
var clientSeed = '0000examplehash';
var gamesToGenerate = 1e7;
var serverSeed = serverSecret;
for (var game = gamesToGenerate; game > 0; --game) {
serverSeed = genGameHash(serverSeed);
console.log('Game ' + game + ' has a crash point of ' + (crashPointFromHash(serverSeed, clientSeed) / 100).toFixed(2) +'x', '\t\tHash: ' + serverSeed);
}
var terminatingHash = genGameHash(serverSeed);
console.log('The terminating hash is: ', terminatingHash);
var clientSeed = '0000examplehash';
var gamesToGenerate = 1e7;
var serverSeed = serverSecret;
for (var game = gamesToGenerate; game > 0; --game) {
serverSeed = genGameHash(serverSeed);
console.log('Game ' + game + ' has a crash point of ' + (crashPointFromHash(serverSeed, clientSeed) / 100).toFixed(2) +'x', '\t\tHash: ' + serverSeed);
}
var terminatingHash = genGameHash(serverSeed);
console.log('The terminating hash is: ', terminatingHash);
Using our chosen starting serverSeed, the hash terminating the chain is c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d. That is to say, the first game's hash played under the new provably fair scheme, when hashed will be c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d.
just to save the copy, if it gets edited..
Awesome site very addicting and IMO way better than the Hi-Lo dice games.. 
btw, are you saying there is a 10btc bounty for the compromisation of your scheme?
There's a 10 BTC bounty for knowing the server secret. You can claim it by doing nothing more than just spending from it (it's a private key, for address with 10 BTC in it). That's because if you know the server secret, you could cheat the game anyway, so I would prefer if someone does discover it (it's stored in the database along with the hashes) you just take the 10 BTC, which will act as a bounty for you and a trip wire for me
I saw that this 10 BTC was recently moved away last month. I assume this doesn't mean that someone was able to compromise the address and it was just moved after being satisfied that it was not compromised after this time?
I'm wondering why the system used for dice games cannot be extended to multiplayer games in a straightforward way. Before the round the server would generate a server secret and publish the hash of the server secret. All players generate a client secret. When a player clicks on place bet, he submits his secret to the server. When the next round starts all submitted client secrets are concatenated with the server secret and used to compute the crash multiplier.
What am I missing?
What am I missing?
i dont understand what exactly are you trying to do here :O.
your saying that there is possibility to cheat in bustabit??? im a bit confused here
regards.
-Katerniko1
your saying that there is possibility to cheat in bustabit??? im a bit confused here
regards.
-Katerniko1
The point of this thread, is to prove that the game is fair. Or more specifically, the game sequence has been pre-determined and from a fair distribution, and can not be influenced by any players actions =)
explain a bit better for me xD
regards.
-Katerniko1
i dont understand what exactly are you trying to do here :O.
your saying that there is possibility to cheat in bustabit??? im a bit confused here
regards.
-Katerniko1
your saying that there is possibility to cheat in bustabit??? im a bit confused here
regards.
-Katerniko1
Jump to: