Search content
Sort by
Showing 20 of 30 results by lionproof
Re: ✅ Paradice.in | 🍀 Provably Fair 🎲 | Rain☔| 30 sec Faucet | 1% House Edge
Users are only able to set their own client seed string. The server seed is generated by the server, not by the user.
The nonce doesn't appear to be random. During the games I played, it is incremented in sequence from 0 after every seed refresh. At which point does the nonce become random?
The user is only allowed to choose between refreshing both seeds, or only the server seed within a 10 minute window.
Changing the client seed string will automatically generate a new server seed, and push it into the queue.
Choosing to advance the server seed queue will generate and queue a new server seed, without being given the option to change the client seed string, effectively locking both client and server seeds for 10 minutes.
Some areas for improvement if you wish to hold true to the claim of "Provably Fair":
1. Locking-in the client seed when choosing to advance the server seed queue.
> The server would already have the client seed before choosing this option. Without being given the option to change their client seed after choosing to advance the server seed queue, the server has the client seed at the time of creating the next queued server seed. Even if the nonce was random between 1-100, at this moment the server has the resources and variables needed to pre-compute outcomes.
2. Users may only refresh their seeds every 10 minutes.
> This appears to be an attempt at hoping the client forgets which seeds were changed 10 minutes ago, and choosing to advance the server seed queue instead of changing their client seed string. If true, this will move the server seed in the "next" position into current use. That seed was created while the server knows the client seed string (because 1, changing client seed will automatically generate a new "next" server seed; and 2. the client seed is unable to be changed after advancing the server seed queue).
3. Users must advance the server seed queue in order to verify their rolls.
> By doing this, the user is not able to change their client seed string again for another 10 minutes. This also appears to be a method designed to cause the server seed, created while the client seed was known to the server, to be moved from the next position into the current position.
4. Lack of transparency regarding the seed's creation.
> The server seed, not the hash of the seed, appears to be another hash output: a 64 character hexadecimal string. Doing a quick query with online hash identifier tools confirms the hash is made with SHA256. Meaning, the seed is also a hash. Hashes need input to be created, what was the original input of the seed before it was hashed and used as the seed?
For a truly "provably fair" system, the user should be allowed to change their client seed immediately after being served with a new server seed hash. The user would also be allowed to refresh their seeds at any time without limit. The actual server seed would also be known to the user, rather than a hash output.
Because of these issues, there is reasonable doubt the server is not pre-computing outcomes with unfavorable bias for players.
Quote
https://paradice.in/faq
Combination = Server Seed (can be generated by user) + Client Seed (can be changed by user) + Nonce (random 1-100)
[...]
Seeds can be changed by players, but only once per 10 minutes.
Combination = Server Seed (can be generated by user) + Client Seed (can be changed by user) + Nonce (random 1-100)
[...]
Seeds can be changed by players, but only once per 10 minutes.
The nonce doesn't appear to be random. During the games I played, it is incremented in sequence from 0 after every seed refresh. At which point does the nonce become random?
The user is only allowed to choose between refreshing both seeds, or only the server seed within a 10 minute window.
Changing the client seed string will automatically generate a new server seed, and push it into the queue.
Choosing to advance the server seed queue will generate and queue a new server seed, without being given the option to change the client seed string, effectively locking both client and server seeds for 10 minutes.
Some areas for improvement if you wish to hold true to the claim of "Provably Fair":
1. Locking-in the client seed when choosing to advance the server seed queue.
> The server would already have the client seed before choosing this option. Without being given the option to change their client seed after choosing to advance the server seed queue, the server has the client seed at the time of creating the next queued server seed. Even if the nonce was random between 1-100, at this moment the server has the resources and variables needed to pre-compute outcomes.
2. Users may only refresh their seeds every 10 minutes.
> This appears to be an attempt at hoping the client forgets which seeds were changed 10 minutes ago, and choosing to advance the server seed queue instead of changing their client seed string. If true, this will move the server seed in the "next" position into current use. That seed was created while the server knows the client seed string (because 1, changing client seed will automatically generate a new "next" server seed; and 2. the client seed is unable to be changed after advancing the server seed queue).
3. Users must advance the server seed queue in order to verify their rolls.
> By doing this, the user is not able to change their client seed string again for another 10 minutes. This also appears to be a method designed to cause the server seed, created while the client seed was known to the server, to be moved from the next position into the current position.
4. Lack of transparency regarding the seed's creation.
> The server seed, not the hash of the seed, appears to be another hash output: a 64 character hexadecimal string. Doing a quick query with online hash identifier tools confirms the hash is made with SHA256. Meaning, the seed is also a hash. Hashes need input to be created, what was the original input of the seed before it was hashed and used as the seed?
For a truly "provably fair" system, the user should be allowed to change their client seed immediately after being served with a new server seed hash. The user would also be allowed to refresh their seeds at any time without limit. The actual server seed would also be known to the user, rather than a hash output.
Because of these issues, there is reasonable doubt the server is not pre-computing outcomes with unfavorable bias for players.
With all due respect, this comment doesn't appear to be mathematically correct.
HMAC and SHA-2 are standard functions. So please don't mess the impression you have with the real principle of random algorithms.
But thank you any way. I will pass your ideas to Paradice management, because the sky is the limit!
Where, exactly, do you believe I made a mistake? I only get the impression of dismissal from you, considering there is no actual reply to my concerns.
When the server has been provided with the inputs used to generate a winning number: a nonce, and a client seed, it can then generate a new seed and calculate the outcomes of the hashes created from that server seed, client seed and nonce. During the moment when the server has the two random inputs, i.e: the client seed+nonce, it has full capability to generate hundreds of new server seeds, then pre-compute the outcomes, then decide whether or not it will bias towards winning outcomes or losing outcomes. Is this incorrect?
In other words,
Quote
1. To get a random number each time, the system combines your Server Seed , your Client Seed and Nonce (rate number):
Message = Client Seed:Nonce
2. Then, the HMAC-SHA-512 message is calculated, where your Server Seed is the secret, the result is a 128-character hexadecimal string:
Hash = HMAC-SHA512(Message, Server Seed)
3. The first 5 characters of this line are converted to decimal a number in the range 0 to 1,048,575 (16 ^ 5 - 1). If the resulting number is more than 1 million, for The calculation uses the following five characters, etc. (the process can be repeated up to 25 times).
In a very rare case ((48,576 / 1,000,000) ^ 25), when all 25 hash fragments over 1 million when translated to decimal number, the remaining 3 characters are used.
4. In Dice, the resulting number is divided by 10,000. your throw. Received quotient is used as the result of your dice roll.
5. In Roulette, the resulting number is divided by 37. The resulting remainder of the division is used as the dropped out number.
User selects a value between 2 and 98 to win. Over or under
Message = Client Seed:Nonce
2. Then, the HMAC-SHA-512 message is calculated, where your Server Seed is the secret, the result is a 128-character hexadecimal string:
Hash = HMAC-SHA512(Message, Server Seed)
3. The first 5 characters of this line are converted to decimal a number in the range 0 to 1,048,575 (16 ^ 5 - 1). If the resulting number is more than 1 million, for The calculation uses the following five characters, etc. (the process can be repeated up to 25 times).
In a very rare case ((48,576 / 1,000,000) ^ 25), when all 25 hash fragments over 1 million when translated to decimal number, the remaining 3 characters are used.
4. In Dice, the resulting number is divided by 10,000. your throw. Received quotient is used as the result of your dice roll.
5. In Roulette, the resulting number is divided by 37. The resulting remainder of the division is used as the dropped out number.
User selects a value between 2 and 98 to win. Over or under
Code:
local hmac_input = client_seed .. ":" .. nonce
local hmac_output = hmac(sha512, hmac_input, server_seed)
for i = 1, 25 do
local start = (i - 1) * 5 + 1
local chunk = hmac_output:sub(start, start + 4)
if #chunk < 5 then break end
local dec = tonumber(chunk, 16)
if dec and dec < 1000000 then
return dec / 10000
end
end
local fallback = tonumber(hmac_output:sub(-3), 16) or 0
return fallback / 10000
local hmac_output = hmac(sha512, hmac_input, server_seed)
for i = 1, 25 do
local start = (i - 1) * 5 + 1
local chunk = hmac_output:sub(start, start + 4)
if #chunk < 5 then break end
local dec = tonumber(chunk, 16)
if dec and dec < 1000000 then
return dec / 10000
end
end
local fallback = tonumber(hmac_output:sub(-3), 16) or 0
return fallback / 10000
Is this incorrect? From my understanding it appears there is in fact many opportunities for the server to pre-compute biased outcomes. These are not hidden, however the answers to my questions in the last post are non-existent in your reply.
Re: ✅ Paradice.in | 🍀 Provably Fair 🎲 | Rain☔| 30 sec Faucet | 1% House Edge
⭐ Merited by nutildah (2)
Users are only able to set their own client seed string. The server seed is generated by the server, not by the user.
The nonce doesn't appear to be random. During the games I played, it is incremented in sequence from 0 after every seed refresh. At which point does the nonce become random?
The user is only allowed to choose between refreshing both seeds, or only the server seed within a 10 minute window.
Changing the client seed string will automatically generate a new server seed, and push it into the queue.
Choosing to advance the server seed queue will generate and queue a new server seed, without being given the option to change the client seed string, effectively locking both client and server seeds for 10 minutes.
Some areas for improvement if you wish to hold true to the claim of "Provably Fair":
1. Locking-in the client seed when choosing to advance the server seed queue.
> The server would already have the client seed before choosing this option. Without being given the option to change their client seed after choosing to advance the server seed queue, the server has the client seed at the time of creating the next queued server seed. Even if the nonce was random between 1-100, at this moment the server has the resources and variables needed to pre-compute outcomes.
2. Users may only refresh their seeds every 10 minutes.
> This appears to be an attempt at hoping the client forgets which seeds were changed 10 minutes ago, and choosing to advance the server seed queue instead of changing their client seed string. If true, this will move the server seed in the "next" position into current use. That seed was created while the server knows the client seed string (because 1, changing client seed will automatically generate a new "next" server seed; and 2. the client seed is unable to be changed after advancing the server seed queue).
3. Users must advance the server seed queue in order to verify their rolls.
> By doing this, the user is not able to change their client seed string again for another 10 minutes. This also appears to be a method designed to cause the server seed, created while the client seed was known to the server, to be moved from the next position into the current position.
4. Lack of transparency regarding the seed's creation.
> The server seed, not the hash of the seed, appears to be another hash output: a 64 character hexadecimal string. Doing a quick query with online hash identifier tools confirms the hash is made with SHA256. Meaning, the seed is also a hash. Hashes need input to be created, what was the original input of the seed before it was hashed and used as the seed?
For a truly "provably fair" system, the user should be allowed to change their client seed immediately after being served with a new server seed hash. The user would also be allowed to refresh their seeds at any time without limit. The actual server seed would also be known to the user, rather than a hash output.
Because of these issues, there is reasonable doubt the server is not pre-computing outcomes with unfavorable bias for players.
Quote
https://paradice.in/faq
Combination = Server Seed (can be generated by user) + Client Seed (can be changed by user) + Nonce (random 1-100)
[...]
Seeds can be changed by players, but only once per 10 minutes.
Combination = Server Seed (can be generated by user) + Client Seed (can be changed by user) + Nonce (random 1-100)
[...]
Seeds can be changed by players, but only once per 10 minutes.
The nonce doesn't appear to be random. During the games I played, it is incremented in sequence from 0 after every seed refresh. At which point does the nonce become random?
The user is only allowed to choose between refreshing both seeds, or only the server seed within a 10 minute window.
Changing the client seed string will automatically generate a new server seed, and push it into the queue.
Choosing to advance the server seed queue will generate and queue a new server seed, without being given the option to change the client seed string, effectively locking both client and server seeds for 10 minutes.
Some areas for improvement if you wish to hold true to the claim of "Provably Fair":
1. Locking-in the client seed when choosing to advance the server seed queue.
> The server would already have the client seed before choosing this option. Without being given the option to change their client seed after choosing to advance the server seed queue, the server has the client seed at the time of creating the next queued server seed. Even if the nonce was random between 1-100, at this moment the server has the resources and variables needed to pre-compute outcomes.
2. Users may only refresh their seeds every 10 minutes.
> This appears to be an attempt at hoping the client forgets which seeds were changed 10 minutes ago, and choosing to advance the server seed queue instead of changing their client seed string. If true, this will move the server seed in the "next" position into current use. That seed was created while the server knows the client seed string (because 1, changing client seed will automatically generate a new "next" server seed; and 2. the client seed is unable to be changed after advancing the server seed queue).
3. Users must advance the server seed queue in order to verify their rolls.
> By doing this, the user is not able to change their client seed string again for another 10 minutes. This also appears to be a method designed to cause the server seed, created while the client seed was known to the server, to be moved from the next position into the current position.
4. Lack of transparency regarding the seed's creation.
> The server seed, not the hash of the seed, appears to be another hash output: a 64 character hexadecimal string. Doing a quick query with online hash identifier tools confirms the hash is made with SHA256. Meaning, the seed is also a hash. Hashes need input to be created, what was the original input of the seed before it was hashed and used as the seed?
For a truly "provably fair" system, the user should be allowed to change their client seed immediately after being served with a new server seed hash. The user would also be allowed to refresh their seeds at any time without limit. The actual server seed would also be known to the user, rather than a hash output.
Because of these issues, there is reasonable doubt the server is not pre-computing outcomes with unfavorable bias for players.
Provably Fair Game Servers Can Still Predetermine Future Rolls
I've been researching the mechanics behind "provably fair" systems used by sites like freebitco.in and duckdice.io. There's no doubt of the validity of the (HMAC + seed + nonce) hashes being verified for consistency. What I could find are many explanations of what 'verified' means, and the mathematics behind conjuring a number between 0 and 10000.
There are many promises made of not tampering with seeds *after* the roll, giving the impression the server commits to a seed before the client submits theirs.
> When sites only reveal the server seed hash for the next round after the client sends their seed for the current round, the submitted client seed can be used to generate rolls of unfavorable outcome.
Consider the flow of playing a round on freebitco.in:
A player opens the page to play a new round. The server seed hash is presented along with nonce, the user is able to choose their seed if they wish. By default it is left unchanged after being generated.
After choosing the odds/multiplier, player smashes HI or LO to deliver a payload containing their variables: https://static.freebitco.in/cgi-bin/bet.pl?m=hi&client_seed=OneSeedToRuleThemAll&jackpot=0&stake=0.00000001&multiplier=666&rand=0.1234567890987654321&csrf_token=000000
It's at this point, one would assume the server, prior to playing this round, had already prepared the next server-seed it will use for the next roll.
However, between receiving the client seed and sending the results of the current roll; the server has the opportunity to cycle through any number of potential server seeds. Coupled with the client's seed, and the next nonce, the server can pre-compute rolls to select a known outcome for the following roll.
With the result of the current roll being delivered to the user, along with the next server seed hash, giving the illusion of unbiased selection, all the server must do now is to assume the user will stay on the path of least resistance.
> The end-user has a predictable behavior pattern, and at least in the case of "Provably Fair" gambling, it becomes a vector of potential exploit.
Compared to jamming one of two keys and watching your coins evaporate, there is more resistance in: scrolling back to the top of page, clicking on the "PROVABLY FAIR" link to open the dialoge, type in a bunch of nonsense into the text area for the next client seed, close the dialoge, and replay.
None of this means that servers are scamming users. But it does give an invite to any nefarious practice which could fly under the radar: deny big wins only allowing small amounts, to force a loss on a large wager, or to break a new world-record losing streak.
> And they could do it while still providing a "Verified Hash" after every roll.
Because hash verification only proves the server didn’t change the seed after generating the result. It can't validate the conditions of the seed's generation, and says nothing about why or how they picked that seed in the first place.
The "provably fair" model only floats if:
1. The server commits to its n+1 seed before knowing the client's.
- Can prove having generated the seed for the game following the current roll, before seeing the client seed.
2. Users routinely rotates their client seed; no less than after every single roll.
If a "provably fair" system doesn't include any sequencing or legitimate proof of seed commitment, then it’s not provable. It’s just branding.
Thanks for reading!
There are many promises made of not tampering with seeds *after* the roll, giving the impression the server commits to a seed before the client submits theirs.
> When sites only reveal the server seed hash for the next round after the client sends their seed for the current round, the submitted client seed can be used to generate rolls of unfavorable outcome.
Consider the flow of playing a round on freebitco.in:
A player opens the page to play a new round. The server seed hash is presented along with nonce, the user is able to choose their seed if they wish. By default it is left unchanged after being generated.
After choosing the odds/multiplier, player smashes HI or LO to deliver a payload containing their variables: https://static.freebitco.in/cgi-bin/bet.pl?m=hi&client_seed=OneSeedToRuleThemAll&jackpot=0&stake=0.00000001&multiplier=666&rand=0.1234567890987654321&csrf_token=000000
It's at this point, one would assume the server, prior to playing this round, had already prepared the next server-seed it will use for the next roll.
However, between receiving the client seed and sending the results of the current roll; the server has the opportunity to cycle through any number of potential server seeds. Coupled with the client's seed, and the next nonce, the server can pre-compute rolls to select a known outcome for the following roll.
With the result of the current roll being delivered to the user, along with the next server seed hash, giving the illusion of unbiased selection, all the server must do now is to assume the user will stay on the path of least resistance.
> The end-user has a predictable behavior pattern, and at least in the case of "Provably Fair" gambling, it becomes a vector of potential exploit.
Compared to jamming one of two keys and watching your coins evaporate, there is more resistance in: scrolling back to the top of page, clicking on the "PROVABLY FAIR" link to open the dialoge, type in a bunch of nonsense into the text area for the next client seed, close the dialoge, and replay.
None of this means that servers are scamming users. But it does give an invite to any nefarious practice which could fly under the radar: deny big wins only allowing small amounts, to force a loss on a large wager, or to break a new world-record losing streak.
> And they could do it while still providing a "Verified Hash" after every roll.
Because hash verification only proves the server didn’t change the seed after generating the result. It can't validate the conditions of the seed's generation, and says nothing about why or how they picked that seed in the first place.
The "provably fair" model only floats if:
1. The server commits to its n+1 seed before knowing the client's.
- Can prove having generated the seed for the game following the current roll, before seeing the client seed.
2. Users routinely rotates their client seed; no less than after every single roll.
If a "provably fair" system doesn't include any sequencing or legitimate proof of seed commitment, then it’s not provable. It’s just branding.
Thanks for reading!
Re: FreeBitco.in-$200 FreeBTC🏎Win Lambo🔥0.2BTC DailyJackpot🏆$32,500 Wager Contest
the payouts changed?? i noticed yesterday they're rounding off a good portion of the profit payout
on a bet of 0.0001
99 odds: 0.00979600
100 odds: 0.00990000
101 odds: 0.01000600
payout used to be the odds minus the bet exactly. not anymore
on a bet of 0.0001
99 odds: 0.00979600
100 odds: 0.00990000
101 odds: 0.01000600
payout used to be the odds minus the bet exactly. not anymore
That is the correct payout for odds of 100. The odds cannot be exactly 99 or 101, when you type these numbers they get changed to 98.96 and 101.06 and those are the correct payouts corresponding to those odds.
Alright thats relief to hear, i appreciate the confirmation.
At lower odds, like 9, 10, 11, the payout is ((odds * wager) - wager), I probably never noticed the difference between higher odds and lower odds until my last post.
cheers
Re: FreeBitco.in-$200 FreeBTC🏎Win Lambo🔥0.2BTC DailyJackpot🏆$32,500 Wager Contest
the payouts changed?? i noticed yesterday they're rounding off a good portion of the profit payout
on a bet of 0.0001
99 odds: 0.00979600
100 odds: 0.00990000
101 odds: 0.01000600
payout used to be the odds minus the bet exactly. not anymore
on a bet of 0.0001
99 odds: 0.00979600
100 odds: 0.00990000
101 odds: 0.01000600
payout used to be the odds minus the bet exactly. not anymore
Re: FreeBitco.in-$200 FreeBTC🏎Win Lambo🔥0.2BTC DailyJackpot🏆$32,500 Wager Contest
captcha is not showing anymore for me
Please tell me what amount you have on your balance, I used to have an amount equivalent to 100 US dollars on my balance, because of this I had no captcha and all the bonuses for RP were available. Now I can't check it, because I have withdrawn almost all the funds from this site and I have a captcha, although I am premium.Yea it was probably around 100$ worth, i was forced to pay 1 RP for a no-captcha spin, and the captcha was restored for the next free roll so its no big deal.
What is a big deal however is this bug I found that caused some money loss. A slip of the finger caused a wager to be placed worth the maximum allowed amount by the game (as much of a wager needed to yield the max 20BTC), way more than what I had in the bank. Waiting to hear back from support, hopefully they see this error and fix it (and maybe get my money back)
Re: FreeBitco.in-$200 FreeBTC🏎Win Lambo🔥0.2BTC DailyJackpot🏆$32,500 Wager Contest
I just got a bad gateway error after doing the cloudflare human check, and it was inaccessible for as long as it took to recover this account to post this message. It's back online now, in any case.
"There are things considered legal in the U.S but not in Canada"
For example: cannabis, in some states... Same thing vice-versa, US legalized gay marriage only a decade after CanadaRe: manyproofs loanding service (I am pro lender to this Place)
Open scam accusation against ManyPoops: https://bitcointalk.org/index.php?topic=1376999
Re: Syrian "refugee" attempts to rape 8-year old Danish girl
Small doses of neo-nazism could be considered as cure for this case.
Nope. That is the tactic used by the pro-immigration left wing loonies. For them everyone who oppose the mass immigration of Muslims to the European continent is a Nazi. For example, in Sweden the left-wingers have labelled the center-right Sweden Democrat party as "neo-Nazi", although its ideology is more similar to the Republican Party of the USA.
The free app converts steps to Bitwalking dollars (BW$) that you can manage and use as you wish.
You can make purchases at Bitwalkings in-app marketplace, trade BW$ with other users, and make purchases with our third party partners.
You can make purchases at Bitwalkings in-app marketplace, trade BW$ with other users, and make purchases with our third party partners.
Why do YOU hate islam?
I hate evil, and if islamists condone brutal and murderous acts of violence, then I shall hate that behavior with all my heart. This goes for pretty much everyone; Equal Hate Distribution for All
I think only fixed rate campaigns should allowed, pay per post campaigns makes more spam on forum.Everyone in rush to make posts because they get paid more when they post more but fixed campaigns will reduce spam on forum and users will make posts only that is good.
So what prevents me from creating 10 accounts and using each of them to make 20 posts per week instead of 200 posts with 1 account? Nothing. Let's move on; this idea won't work. This especially has no effect on the quality. What's preventing people from doing this already?
Fixed rate campaigns coupled with posts per week could be a good way to deter people from spamming while pushing them to include themselves in conversation.
Weekly pay, BTC0.00x/week, min 5 posts of good quality and constructive commenting. Make sure the language of the poster is fluent in the forums where which they post.
People would be less likely to spam all over the place, while viewers and advertisers would be sharing quality paid content.
I've been seeing ads for people who wish to buy and sell Bitcoin with PayPal, and this got me curious of the risks involved.
After researching, it seems chargebacks are prevalent, and PP is still shutting down accounts known to be exchanging Bitcoin.
Is it even worth the risk? Chargebacks being my main concern
After researching, it seems chargebacks are prevalent, and PP is still shutting down accounts known to be exchanging Bitcoin.
Is it even worth the risk? Chargebacks being my main concern