|
While on the topic of nitpicking the investment FAQs, the examples show that a "1x kelly" actually is a 1.11x kelly. It's not clear if the example is wrong, or a "1x kelly" actually means "1.11x kelly"?
|
|
|
|
Is that any clearer?
Thanks Dooglus, that's much clearer. I lifted that into the original post. So why not just say that you have generated a long chain of sha256 hashes, and omit the stuff about the private key of a Bitcoin address?
Because like you said, it doesn't matter. It's really just a trivia piece. Just like you can't verify how long the chain is, but it doesn't impact the ability to verify the distribution of game results. It would be nice to have a 10 BTC bounty be available as a tripwire and guaranteed reward, but there's no way I can know that you even used that private key anywhere in the process, so that bit comes back down to having to trust you.
When I need to generate a new chain, I'll reveal the initial server seed, and you can verify. Or if someone does find out the initial server seed, and it's not that private key, I'll be outed as a liar. But anyway, it doesn't effect the provably distribution. But yeah, if you're a bug-bounty hunter, you'll need to trust me on that one. |
|
|
|
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 |
|
|
|
hash terminating chain: c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d
^ how did you calculate that if you dont know the client seed?
The point is I am proving I have calculated, and committed to using a particular a hash chain before the client seed is known. The client-seed is used in interpreting the hashes to create a game outcome, so there's no way I could have created a "bad" or "good" hash chain. |
|
|
|
Using our chosen starting serverSeed, the hash terminating the chain is c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d. That is to say, the first game played under the new provably fair scheme, will be played with this hash. The second money pot game played, when hashed will be this hash.
I don't like the wording. Was clearer before but fine with me. An offset of 1 doesn't really matter. But if you want to give everyone a free roll with a known hash, that's also fine with me  Yeah, it's not going to matter ( I doubt anyone will catch the first few games) but it's a bit icky. I changed the quote to: That is to say, the first game's hash played under the new provably fair scheme, when hashed will be this hash. |
|
|
|
|
Thanks very much guys. I've updated the original post to address all the concerns and fix. Since we're well and truly before bitcoin block 339300 I have updated the final terminating hash and more tightly specified what it means.
Could you guys please give it a re-review, and generate another snapshot?
|
|
|
|
this seems really good. Has it already been implemented? If not, when does it start?
Not yet, it will start after the drawing -- probably at the end of the week You need to give us a hash of the initial server seed.
It's not actually required, but you it is the private key to the address: 1J6qabbRQmxiii4j8mmAZ3XTvURZ8yzwfy For your own sake I hope you make this seed random / long enough If anyone does discover it, they are welcome to use it to make a spend  |
|
|
|
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: function genGameHash(serverSeed) {
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: 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));
}
The chain could be generated with code such as: 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);
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. |
|
|
|
They aren't contributing, so they shouldn't count.
They are not contributing to the staking, but they are contributing to the max profit. I think however it is done, the incentivizes needs to align with pushing people to keep money offsite (which is beneficial to investors, Dooglus and the coin). |
|
|
|
Another question is how to distribute the staking rewards.
Alternate solution: Don't distribute staking rewards. That would incentives people to both use offsite storage as well as stake on their own, which would allow the coin to become decentralized again and maybe grow up to be more than JD-coin. Smart investors could run a script to monitor their JD investment, keeping a minimal balance in JD sufficient to keep themselves from being margin called. |
|
|
|
Is avaiable IE??
Seems to not working on my IE browser
What should i do?
Unfortunately we don't support IE as none of us have Windows machines, which makes supporting IE a bit of a challenge. Firefox and Chrome on other hand work well and are probably better browsers. If anyone is interested, we'd happily take patches to support IE though (as we did to make it work on Safari) Thanks! |
|
|
|
|
I'm not sure of JD mechanics, but most likely they only show 'notable' bets. Where a notable bet is probably losing a certain amount of money, or winning a certain amount of money. If so, there would be a level where if you're betting at 11x, a loss isn't notable enough to show up, but a win is notable enough to show up. So for that bet amount and multiplier, you'll only see the players wins.
|
|
|
|
The server 'cowboy' you list for MoneyPot.com and PrimeDoes is just a header that heroku's reverse proxy adds. The actual webserver MoneyPot uses is raw node.js (for better or worse). The front-end framework we use is react (from facebook) and works quite well. BTW the entire MoneyPot.com stack is open source: https://github.com/moneypot |
|
|
|
If anyone is interested, https://www.moneypot.com uses bip32 to generate offline deposit addresses. We don't publish anything that would allow anyone to know anyone elses deposit address, so there's no way coinbase could se you're depositing money to moneypot. And since you're depositing directly into cold storage, we don't sweep it into a published account -- so no leakage on that front either. Just to clarify: this no longer applies. MoneyPot deposits now go directly into the hot wallet, which is swept into cold wallet addreses es. While there's no way to find out the cold wallet address, it would be easy to enumerate some other peoples deposit and withdrawal addresses. If you need privacy, for what ever reason I would highly recommend mixing your coins beforehand. On the withdrawal side, we send from totally unrelated coins -- so that's untraceable too -- so if you're worried about coinbase, moneypot.com is a pretty safe bet =D
That's a rather odd statement to make, considering coinbase was being used to process the withdrawals. In any case, withdrawals are now processed from the hot wallet, similar to most other gambling sites. |
|
|
|
To help with playing for bonuses, we've added a little bar underneath the players list that shows the portion of money on the table that is yours, still at risk and has been cashed out:  Give it a try! |
|
|
|
Good insight; yes this is true. By choosing your own strategy you may improve or worsen your chances compared to following hints.
Interesting! I ran a greedy algorithm on a 11x11 board with 33 randomly distributed mines, and despite trying a few heuristics over 500k games, I haven't been able to win more than 7% of the games (which would be a 23% house edge). So I guess my question would be: is your greedy solver better than mine? If I follow your hints, what % of the games will I win? If the difference in greedy algorithms is the difference between a 23 and 2% house edge, it seems quote possible that something more optimal will put you in -EV territory? |
|
|
|
|
Show Posts
