So we've only seen 8k dug since the digger stopped, 3k of which was all at once.
I thought that 3K bump was due to the faulty math of supply that was corrected. I'm pretty sure I went back through all the old blocks and corrected them for the supply bug, and that the 3k bump is real. I'll find the 3k bump and post a link to the block(s) in question when I get a chance. Edit: this block contains three transactions digging up ~1k CLAMs each. |
|
|
|
Ok lets go through doogs post. Doog I've got to be as fucking sick of answering these fucking posts as you
Yeah, I'm torn between replying to defend myself and just letting it go. I'll just reply to the max-proft-and-FBI bit, because that's curious to me... JD right now has a large max bet than it ever did when it was Bitcoin. https://en.bitcoin.it/wiki/Just-DiceThis wiki isn't correct about the max. The max bet for a 50,000 BTC bankroll was 250 BTC. When JD first launched it was 1%, but the site got raped 10,000+ Bitcoins and Dooglus freaked out a bit. True. We started out having investors risk up to 1% of their coins per bet, and dropped it to 0.25% when the first whale started knocking the bankroll around. I put it back up to 0.5% a few days later and that's where it has stayed ever since. But then I came up with the idea of "offsite investments", in a failed attempt to encourage people to take the majority of their coins offsite and stake them for themselves. It didn't work, and seems to have done nothing other than causing an arms race where everyone has to either take stupid risks or get left behind. I'll be reducing the maximum offsite multiplier over the next few weeks I think to address this problem. Right now the max bet is 583.51938 BTC.
The maximum profit, that is. And only if you use the current price. You wouldn't be able to actually get 500 BTC if you won the maximum profit, due to slippage. There just isn't enough demand for CLAM to be able to sell that many of them very quickly. The only reason JD isn't earning more now via CLAM is because Dooglus doesn't have as many crooked FBI Agents and others of that sort playing there via CLAM (yet!)
That's an odd thing to say, and is the first I've heard about it. Can you fill me in on any details? I'm pretty sure that the reason the CLAM site earns less than the BTC site is because CLAM is relatively unknown compared to BTC, and has a much lower total value. That's why I switched to using it, to keep things smaller. CLAM is smaller than BTC by several orders of magnitude: BTC is worth billions while CLAM is worth millions. |
|
|
|
That method with only 64 hashes is indeed interesting, but, it is complex to understand.
Sorry for going offtopic here, but here's an explanation: I made an implementation of a variant of it, where all hash chains are of length 10, so it works better for people who think in base 10 (ie. all of us).
Suppose we know that the 9999th hash is 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
From that we can get to the 9998th hash by adding 1 to the last digit of the above hash, and hashing it:
sha(...b9825) -> 9998th hash
Or, we can get to the 9989th hash by adding 1 to the last but one digit and hashing it:
sha(...b9834) -> 9989th hash
And so on:
We can get from the 9999th hash to the 8999th hash by adding one to the last-but-three digit and hashing it:
sha(...ca824) -> 8999th hash
We would have to define what adding 1 to an 'f' does - does it carry a 1 to the left or wrap around to 0 without carrying. Either works, but we must decide which we are using.
And we have to note that you can only use this trick to get from one hash to the next if all the digits to the right of the digit you're decrementing are 9's.
So we can go: 9999->8999->7999->7989->7979->7969->7968 to get to the 7968th hash
But we can't go 9999->9989->8989->... because the bolded section is modifying the thousands digit when the tens digit isn't a 9.
Once hash 99 is published, you can calculated any lower numbered hashes. But from hash 103 you can only go back to hashes 100, 101, and 102 and none of the double-digit hashes (since you can't edit the hundreds digit unless the tens and units are both 9's).
So when we are on game 24648 for instance, we would need to be publishing the hashes for these games:
24648, (gives you 24640 to 24648)
24639, (gives you 24600 to 24639)
24599, (gives you 24000 to 24599)
23999, (gives you 20000 to 23999)
19999 (gives you 00000 to 19999)
From those 5 hashes you are able to get back to any previous hashes using the rules laid out above, and in the worst case you'll be doing no more than 9*5 = 45 hashes to get to the hash you want (up to 9 hashes per digit, to get it from a 9 to a 0, and up to 5 digits in this example).
|
|
|
|
Ok. Makes more sense. I was trying to get around the computation part for more than 30 minutes. That's "hard". Not a problem for a once a week game, or even a daily game, but it does mean you have to set aside processing this. This is slow to compute AND slow to verify (please correct me if I'm wrong.)
You're not wrong, but you are kind of missing the point. It is slow *on purpose* so that the miner can't tell whether the block he just mined makes him win or lose, and so he can't cheat by withholding a block that makes him lose. By the time he figures out that his block makes him win it has already been orphaned, so he may as well just publish the block immediately and not try cheating the lottery. It would be better if it was slow to figure out who won but very quick to verify the result, but nobody was able to come up with a way to do that, and so pevpot uses a calculation that is just as slow to verify as it is to run the first time. The ideal algorithm would be: a) slow to determine who won given a list of tickets and the mined block hash b) quick to verify the winner given a list of tickets, the mined block hash, and the winner c) deterministic, so that step a) always gives the same winner for the same inputs It's not hard to find systems which give us any two of these three: A+C: The current system has (a) and (c), but there's no quick verification step. B+C: Just using the block hash gives us (b) and (c) - it's instant to verify, and deterministic, but step (a) is also instant and so the miner can cheat. A+B: We can get (a) and (b) using some kind of proof-of-work algorithm. We search for a nonce such that sha256(blockhash+nonce) starts with 10 zeroes (or whatever difficulty is suitable), then use that new hash to determine the winner. It's slow to find such a nonce, and quick to verify that the nonce works, but it isn't deterministic. Lots of different nonces would work, and give different winners. We could insist that the nonce search starts at zero and works upwards, such that only the lowest such nonce is accepted, but then verification is no longer instant, since we have to replicate the whole proof of work to check that the given nonce is the lowest one that works. Can you find a method that gives all three of (a), (b), and (c)? It shouldn't rely on any "server secret", since we have no way of knowing for sure that the server owner isn't also playing the game. I'd also like to avoid external secrets, meaning "real life" secrets. These include actual lottery results from maybe Mega Millions or Powerball. (Although that certainly makes it provably fair, as no way would anyone know the Powerball results before the draw, unless all the balls were rigged.)
Re-read what you just said: that's provably fair unless it isn't... Using powerball numbers isn't provably fair - it is relying on the trust that whatever process they use to select balls isn't rigged. There's no proof that it isn't, and so the game is "trustably" fair, not provably fair. |
|
|
|
I am pretty bad at explaining things, but I'll try before Dooglus replies and makes me look like a babbling toddler.
That is funny. I read your previous post, and was just about to reply to clarify *why* using N and N+1 is equivalent to only using N+1 but I thought I should read to the end of the thread in case anyone else had already done so. Then I saw this, and it made me laugh out loud. Now I'll read to the end of the thread... |
|
|
|
When it first happened I considered PMing the others in DT1 and asking them to ~BayAreaCoins to fix the situation,
Lol I am amazed to see this response from you dude.Lets assume if someone is accusing falsely then you simply ask others to ignore or remove him from DT but wont shed some light on the accusation ? particularly when the person accusing is not a newbie or some typical spammer here to earn money.This is hilarious and unexpected. I saw the feedback, immediately realised it was nothing more than retaliation for my negative comments about his clamdigger fees and/or for me encouraging discussion re. the future of CLAM, and figured everyone else would see it the same way. It never occurred to me that anyone would take his feedback seriously. Let's go through it and see if it has any merit as a negative trust feedback. There are 5 paragraphs: Gave me insider information of Just-Dice reopening with something called Clamcoin that allowed us to acquire a large amount of the "most fairly distributed crypto ever" before pushing it to the ignorant public. 1/5: It's true. I mentioned that I was working on getting the CLAM client ready for use with Just-Dice in the course of a conversation with him. It wasn't a secret. I would have told anyone who asked what I was working on. My work was all published to github in real time for anyone to see anyway. No telling what percentage of the network was owned by Doog and I alone. 2/5: I could figure it out if anyone cares. I had less than you, but more than most. I don't think anyone would open a dice site that only accepts a currency they have no interest in. Dooglus is very very smart and you'd never know if he got one over on you generally. 3/5: I'm not sure what to say about this. Is being smart a bad thing? Ditched Bitcoin Just-Dice because he'd earn more Bitcoins on Just-Dice through shitcoins that he'd corned the market on. Now that there is a BIG digger and doog no longer has a corner on the market... they are pushing for core changes on CLAM to remove digging all together. Stinks to high hell IMO. 4/5: This isn't true. Just-Dice for BTC was making far more than Just-Dice for CLAM has ever made. I switched to CLAM from BTC because I wanted to downsize. Just-Dice for BTC was stupidly huge. I was holding over $60 million worth of BTC in my house at one point, and hated the responsibility of having to look after so much of other people's money. If I was in it for the money wouldn't I have run sites for both BTC and CLAM at the same time? Or maybe just kept the $60 million? I've never seen any CLAM developer pushing to remove digging. I was attempting to allow an open discussion of possibilities. That seems like a good thing to me, not something to complain about. We ended up putting it to a 'vote' of sorts, and it appears there is no consensus to change anything - and so nothing has been changed. Dooglus has a very good history of giving people back their coins though I will say that. I saw him return over 60,000 BTC to rightful owners. 5/5: This also seems like a good thing. So in summary the "negative" feedback appears to consist of: 1. He talks to his friends. 2. The currency he accepts on his dice site is the one he is most interested in. 3. He is smart. 4. He didn't like being responsible for too much of other people's money, and fostered community discussion of ways to improve CLAM. 5. He is honest. Given this, I don't see how the feedback is "negative", and can only assume the intent was to damage my reputation. Removing him doesn't Fixes the situation.
It depends how you see "the situation". The situation as I see it is my reputation goes to zero because of a single 'negative' feedback. He left similar negative feedback for the other CLAM developers too. Removing him from DT2 would fix that situation. The the main plot in BAC's ratings is just a warning and to be cautious with you, but not to remove you from DT ,you are a scammer,you should be punished etc..But you appear to have an exact opposite behavior by calling him an asshole etc..
I think the main point of his feedback was to damage my reputation because he didn't like that I was trying to have a discussion with the CLAM community about possible reactions to the large CLAM digger. So when it first happens you simply PM others to remove him but all the clam problems is suddenly equal to shit and all you care is about the ratings...Not Cool dude.
I didn't PM anyone. I just let it slide and figured most other people would see the feedback for what it is. In short two trolls have been attacking me. Hopefully anyone with a little intelligence can see it for what it is.
How is that an attack when none of them made this thread or any other appeal ? Do you mean the OP is one of their alt's ? I think leaving someone unjustified negative feedback is an attack. Especially when you see how the forum trust system works. A single 'respected' negative cancels all previous positives. And QS trolls me all over the place. But let's not give him any more attention than he deserves. Not to derail thread but can anyone tell me how much default trust you need to get into dft1? Or is it just more of a case of who you know? I havent been able to find anything on how you actually get in.
I have no idea how it worked. I never asked to be added to DT, and didn't even know I had been added for a while. There was no welcome message or anything of the sort. |
|
|
|
People were asking in the JD chat for updated 'dig' charts, so I figure I'd post them here too. Click for bigger versions: 1) all-time:  2) since just before the big digger started:  3) since just before the big digger stopped:  So we've only seen 8k dug since the digger stopped, 3k of which was all at once. |
|
|
|
Currently if I want to verify that you're using the "correct" hash for game #123456 I need to run 123456 sha256 hashes and check that I end up with the genesis hash. Under Rusty's scheme the same could be achieved using something in the order of just 20 sha256 hashes.
doog, please correct me if I'm wrong or if the method has changed since I last remember it, but wasn't a genesis hash or chain hash generated last year for 10 million games? And a then future block hash was used. Combined, is the game hash, but you only need the next game's hash to verify the hash of the game you are currently playing. You don't need to run all 123456 hashes, just check the next one when it's available. And maybe check the previous 100, at least you know that hash is from the same chain. OK, but you wouldn't know that the chain the game is currently using is actually the same as the 10-million-hash chain that was selected a year ago. Maybe Ryan made a new chain which has lots of low crashes on it, and we're playing through that instead. We wouldn't be able to tell the difference unless we hash all the way back to the genesis hash to check it. I've no reason to think that's actually happening of course. I am just saying that to check it we would need to run thousands of hashes (one for every round that happened since the game became provably fair - so it will take longer and longer over time), whereas the method I posted about gets rid of that problem. That method never needs more than 64 hashes to get from the current game to the genesis game - but it is quite significantly more complex to understand, so it's a tradeoff. |
|
|
|
Spoiler alert... I give the game away in this post. If you don't want to read it yet, scroll past... x x x x x What i meant is that your statement might be true WHEN you don't check it against the reality. So we know one clam block is found in average every 1 minute. Then when you don't check it against the real blocks found, let's say you take a point in the future, then you would await that the next block, in average would be 1 minute away. The last block was one minute away in average too. Because you don't have data to rely on. Though when you check it against the past blocks or wait until the blocks were solved around that point then the theoretical truth proofs to be wrong because that point in time has to be somewhere between 1 minute blocks. Which would be the same for the average of all points in time that are checked against the real blocks.
Whether you check against theoretical or real blocks, you find the same. If you randomly pick a point in time over the last year and see what the time between blocks was at that point, you get number around 2 minutes on average. Even though the average blocktime is only one minute. So was your statement theoretical only?
No, it really happens. Do you want to know why? It's because when you pick a random point in time you have very little chance of picking one of the quick blocks, and a much bigger chance of picking a slow block. That's what messes up the average time - there's a bias towards you picking the bigger gaps, just because they are bigger. But what i want to say is that how can the average be higher than the average of these points in between a block if the average blocksize is 60 seconds?
It's a funny effect isn't it. Maybe this related situation makes it clearer: Suppose there are two busses per hour at your local stop. One one the hour, and one at 5 minutes past the hour. You don't know the timetable; you just know that there are 2 busses per hour, so an average time between busses of 30 minutes. You guess your expected wait time will be 15 minutes. Now suppose you arrive at the bus stop at a random point in time. How long do you expect to be waiting for a bus? 5/60 probability you arrive between x:00 and x:05 and have an average wait of 2.5 minutes 55/60 probability you arrive after x:05 and have an average wait of 27.5 minutes Note that the average of 2.5 and 27.5 is 15 minutes - but the probabilities aren't equal. The long wait is much higher probability. The actual expected wait time is (2.5 * 5/60) + (27.5 * 55/60) = 25.4166 minutes. The expected 'time between busses' you see, when you randomly arrive at the stop is twice that, at around 51 minutes. Because almost all the time you're not lucky enough to get there between :00 and :05. -- Alternatively, suppose there are two busses, one with 10 people on it, and one with 90 people on it. You take the 100 people into a room and do a survey. You ask them "how many people were on your bus?" and average the replies. There was an average of 50 people per bus, but you're going to hear "90" much more than you hear "10", so the average of the numbers you hear is going to be closer to 90 than to the true average. I'm not a python programmer, but in the find routine, it looks like your returning the newer block, and then the older block. but in the main routine, your looking for the older block then the newer block.
Have you tried running the code with a small subset, just so you can manually verify the output.
I would expect the averages to be 1/2 the block time.
Maybe I don't know what I'm talking about.... (Won't be the first time)
It's not clear from my code, but the datafile has newest blocks first, so find routine is returning the older block first, then the newer one. I did test it on a small sample first, and it is doing the first thing. I would have expected the averages to be 30 seconds too, but they aren't. See my "bus" examples above for an intuitive explanation of why... basically when you pick a random time you have a bigger chance of picking a time when we were waiting a long time for a block than picking one of the quick ones... x x x x x |
|
|
|
The way the trust system works is that a single negative by anyone high enough up resets your rating to zero. In my case BayAreaCoins left me a negative trust rating that is entirely undeserved because he was butthurt when I pointed out that his "clamchecker" site was charging fees incorrectly. Rather than fixing it he got mad. Then when I started paying attention to people asking the CLAM developers to consider doing something about the large amount of "CLAM digging" that was going on he went off the deep end with his paranoid ranting about the developers wanting to ban digging. At one point he went as far as saying that he wanted one of the developers to die in childbirth. The guy's just an asshole who has no business being in the default trust system at all. I removed him from my view of the trust system and guess that eventually others will come to the same conclusion that his ratings are worthless. When it first happened I considered PMing the others in DT1 and asking them to ~BayAreaCoins to fix the situation, but I don't think it's really worth bothering people with. I don't trade here and don't care what my trust rating is that much. Shorena: It's true that I mentioned to BAC that I was working on getting Just-Dice working with the CLAM client a few weeks before it went live. I never made a secret of it, and was making lots of public pull requests to the CLAM git repository. It wouldn't have been hard to figure it out for anyone who was paying attention. As for my having lots of addresses to dig from JD and Doge-Dice, that's not the case. I had somewhere between 20 and 30 funded addresses from all my wallets in total, and got a little over 100 CLAMs from digging. I have always been very careful with my wallets, regularly sweeping coins into cold storage. I just randomly checked the JD hot wallet right now. There are 17 funded addresses in it. 8 of those contain faucet dust. So my very active hot wallet has 9 non-dust funded addresses right now. That's similar to how the hot BTC wallet used to be: "xJ9ApbTQsfJnqPc9GxPPszfZGAXTrcC713" : 17.72441707
"xNjsbT6kLP3LyW9aR2DLMGdxJJJvAuJHpw" : 39.38004266
"xBRE6bSNXgaf4NjqYpoDchth9B5ArqkvDB" : 48.33039541
"xLhjtmranwzG6zm3JZ3bFaDNJKvLgCXTAH" : 78.30468981
"xPRYSMnczKEhrb4Xx6hzY9vC1Dw2a1fR4A" : 107.81917395
"xBuA6bdL34f8zyJDZtZWTop79Bg28RcTeh" : 184.52912759
"xVEHfSmipES5HKvgRPof1bwdbzBS7HREVz" : 294.12728304
"xKjyY4P4c9qwUmowjW3VVJPNvKEKZM1QWd" : 436.29586189
"xJDCLAMZw7oNy2cUXAwnxbrkqyimL54zto" : 30593.76849031
QuickSeller is always going on about how I "endorsed" a couple of gambling sites that turned out to be scams. I always went to great lengths to say that I didn't know who ran them and that I didn't trust them. I was never anything but honest about my dealings with the sites. In both cases I was able to withdraw my deposit before they stopped allowing withdrawals. In both cases there were signs that something was wrong before the sites shut down, so it wasn't hard to get out if you were a little cautious, as I usually am. I think QS is pissed at me for some reason - maybe because I stood up to him when he was bullying tsp, but I don't know if that's really why. Recently he dug up some years old story about Just-Dice accepting deposits from TF's inputs.io site. Now I see he's saying I offered "incentives" for people to use it? That's not true at all, but happily he has lost pretty much any credibility he once had here anyway. In short two trolls have been attacking me. Hopefully anyone with a little intelligence can see it for what it is. I only just found this thread after RayBrady mentioned it in the bustabit trollbox. Thanks for bringing it to my attention Ray. I think. Note: I only just skimmed the thread and answered the main points that stuck in my mind. I didn't want to do my usual trick of quoting every point and addressing it. If I missed anything important I'm happy to reply to it, but I'm kind of sick of going over the same old stuff again and again. |
|
|
|
But to aim its bonus I dont think that you can win all games right? Sometimes you must take some loss too so I think there is no way you can earn just through the bonus thing. And btw how much is the max bonus? Depends on how much you bet and your multiplier?
There's no maximum bonus. It depends on how other players bet. If you and 9 other people each bet 1 million bits, nobody else plays, and you are the last one to cash out, you get 10% of your bet as a bonus. If you notice they're all cashing out at 2x you can set your cashout point at 2.01x. Then half the time you'll be getting a 10% bonus, which only losing 0.5% to the house edge on average. That's enough to make a decent profit over time. Edit: the last person to cash out gets a bonus percentage which is (total_stakes / biggest_stake). In my example the total_stakes were 10 million, and the biggest stake was 1 million. 10 million / 1 million = 10, so the bonus is 10%. So if there were 200 people each betting 100 bits, the last one to cash out would get a 200% bonus! |
|
|
|
Ryan, I stumbled upon this novel way of making huge sha256 chains efficiently: https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txtInstead of a linear chain of a few million sha256 hashes for provable fairness, he proposes a 64 dimensional hypercube of hashes, giving 2^64 hashes with very little precomputation required. I thought it was kind of an interesting idea, extending the usefulness of the technique you're using at bustabit. Currently if I want to verify that you're using the "correct" hash for game #123456 I need to run 123456 sha256 hashes and check that I end up with the genesis hash. Under Rusty's scheme the same could be achieved using something in the order of just 20 sha256 hashes. Not that it's worth changing at this point in time. But it may be helpful for your next venture.  |
|
|
|
If you're not doing anything that's already against or Terms and Conditions, then you won't have an issue.
For example - user gets a 'big win' and then bets on lower odds to clear his bonus. That user is thereby disqualified.
Don't the above two quotes contradict each other? Is getting a 'big win' or betting at 'lower odds' against the terms and conditions? If not, why would that user be disqualified? And can you explain the "automatic adjustment"? Are you saying that some 1 BTC bets don't count as 1 BTC wagered for the wagering requirements? I saw nothing about that when reading about the bonuses.
I guess you have a bunch of players trying to clear bonuses who are unaware of the fact that they are having to bet more than 888x times their bonus amount. Will you honor the terms they agreed to?
You didn't respond to these questions at all. Please try to be clear (here and on the site) about the real wagering requirements and what kinds of bets would result in disqualification. |
|
|
|
First you told me some kinds of bets would get me disqualified: For example - user gets a 'big win' and then bets on lower odds to clear his bonus. That user is thereby disqualified.
But when I asked for details you told me that I can play however I want and that the system would adjust the rollover: You're allowed to play any game that allows you to play bonus money.
The amount of a bet that is applied to the rollover is automatically adjusted for the odds of the game.
So which is it? Do you disqualify some people because of how they play? If so, how can I avoid being one of those people? What are the rules? And can you explain the "automatic adjustment"? Are you saying that some 1 BTC bets don't count as 1 BTC wagered for the wagering requirements? I saw nothing about that when reading about the bonuses. Also, we've never, EVER disqualified someone so far for this type of play. If we do, we will address it in a public forum if requested. I would prefer if you told me the rules so that I don't get disqualified, rather than having to guess them and then having a forum argument about it after it happens. Are the rules a secret? Do they exist? Or do you just go by gut feeling whether to 'disqualify' someone who overcomes the huge odds against them ever clearing a bonus? Also, the 'auto adjustment' is a universal thing in all casinos. Different games apply different amounts toward your rollover requirements. Our casino handles it based on the calculated odds, not the game itself.
Your casino clearly states: For you to withdraw any of the winnings you get with the bonus amount, you will need to bet your bonus amount times 888x on any of our games. Nothing about certain bets counting for less. Just that you have to bet 888x times the bonus amount. It sounds to me like the actual terms of the bonus deal are even worse than how they are presented on the site. "888x times" is bad enough, but now you're telling me it is actually "888x times (some extra unspecified factor) times". I guess you have a bunch of players trying to clear bonuses who are unaware of the fact that they are having to bet more than 888x times their bonus amount. Will you honor the terms they agreed to? |
|
|
|
Are you sure that you used the same point in time to calculate the first 2 points? If C is correct then in average you should always find a point in or on a 1 minute timeframe.
Are you saying that the next block always happens within one minute of the current time? That isn't true. The average expected(*) time to the next block is always one minute. It is often more than one minute to the next block. Note that when staking you don't make "progress" to finding a block. You either find it or you don't. The same with Bitcoin mining. When you are waiting for a block, if you wait 5 minutes without a block being found, it doesn't mean a block is "due", or that a block "should" be found in the next 5 minutes. Even after waiting 5 minutes, the expected time to the next block is still 10 minutes. And if there is no block in the next 10 minutes, the expected time *after that* is still 10 minutes. (*) I've been using the word "average" when I meant "expected". Let's pick a random time, say Sat Jan 16 02:33:17 2016. The previous block was found at 02:32:32 (45 seconds earlier). The next block was found at 02:33:36 (19 seconds later) The time to the next block was 19 seconds. The "average" time to the next block was 19 seconds, I guess, if you can average a constant. The average of 19 seconds is 19 seconds. But at that point in time the *expected* time to the next block was 60 seconds, even though at that time it had been 45 seconds since the previous block. When i would chose a random point in the future then the next block after that point should be a half minute later, i think, too.
OK, let's test it. I wrote a script which picks random points in time over the last month or so, then looks up the time to the previous and next block. #!/usr/bin/env python
import random, string, time
def rand():
return start_date + random.random() * (end_date - start_date)
def fmt(seconds):
return '[%s]' % time.ctime(seconds)
def find(seconds):
last = None
for sec in times:
if sec < seconds:
return sec, last
last = sec
datfile = "clamblocks.dat"
count = 0
lines = 100000
samples = 100000
times = []
fp = open(datfile, "r")
while True:
line = fp.readline()
if not line:
break
line = string.split(line[:-1])
times.append(string.atoi(line[5]))
count += 1
if (count == lines):
break
start_date = times[-1]
end_date = times[0]
print "picking random dates between %s and %s" % (fmt(start_date), fmt(end_date))
before_sum = 0
after_sum = 0
count = 0
while True:
t = rand()
before, after = find(t)
before_sum += t - before
after_sum += after - t
count += 1
if count % 1000 == 0:
print ("(%6d) %s is %6.2f seconds after %s (%6.2f) and %6.2f seconds after %s (%6.2f)" %
(count,
fmt(t),
t - before, fmt(before), before_sum / count,
after - t, fmt(after), after_sum / count))
I happened to have the data in a file already, so it's a bit quicker than querying the clam daemon. But never mind that. Here's the output of the script. It shows the average times in (parentheses): (200000) [Fri Nov 13 01:41:39 2015] is 67.13 seconds after [Fri Nov 13 01:40:32 2015] ( 52.78) and 44.87 seconds after [Fri Nov 13 01:42:24 2015] ( 52.96)
(201000) [Tue Dec 8 16:40:24 2015] is 40.73 seconds after [Tue Dec 8 16:39:44 2015] ( 52.76) and 7.27 seconds after [Tue Dec 8 16:40:32 2015] ( 52.97)
(202000) [Sun Jan 17 05:09:04 2016] is 16.23 seconds after [Sun Jan 17 05:08:48 2016] ( 52.77) and 31.77 seconds after [Sun Jan 17 05:09:36 2016] ( 52.97) After picking 200k random points in time the average of all the actual times from the previous block is 52.78 seconds, and the average of the actual times to the next block is 52.97 seconds. I'm surprised it's coming out around 53 seconds and not 60, but can imagine two explanations: 1) the CLAM network is always a little bit too fast; the average block time is 59.xx seconds, not 60 seconds; not a significant error 2) the average time to the next block is 60 seconds because it's possible (though unlikely) to have *very* long gaps between blocks; we're not seeing those very long gaps in the sample that I'm averaging over, but we are seeing lots of short gaps Either way, it's closer to 60s than to 30s, and their sum is way over 60s. Edit: I ran it again, using a year's worth of blocks, and let it run for longer. The results barely changed: picking random dates between [Sun Jan 18 03:37:36 2015] and [Thu Jan 21 07:04:00 2016]
(276000) [Mon Feb 23 00:40:30 2015] is 62.58 seconds after [Mon Feb 23 00:39:28 2015] ( 52.74) and 289.42 seconds after [Mon Feb 23 00:45:20 2015] ( 52.76) First, statements A and B don't make sense. The average amount of time from the chosen point in time is a singular number. You probably mean the average of a distribution of randomly chosen points.
You are correct. The average time to the next block from a particular random point in time is whatever the actual time to the next block was. I was being sloppy. I meant the expected time to the next block if the future wasn't already known. You wake up, turn on your computer, look at blockchain.info. How long since the last block was found? Make a note. Wait for the next block; how long does it take from when we woke up? Make a note. Repeat this every day for a year, average times to the previous blocks, and average the times to the next blocks. Do you get something close to 5 minutes for both averages or something close to 10 minutes? I think SebastianJu would tell us that on average we are half-way between blocks, so the average time would be 5 minutes to the previous and 5 minutes to the next. I'm claiming that the average is actually 10 minutes in both directions, and that the sum of the two averages would be 20 minutes. But I am also claiming that the average time between BTC blocks is 10 minutes. [/quote] The error is in your final assertion, "Wouldn't you expect ...". No I wouldn't expect that.
Right. A+B = C is false. In fact A + B = 2C. The expected time to previous block + the expected time to next block = twice the expected block time. |
|
|
|
is there a staking pool planned? I currently found out about just-dices shared staking... but you have to invest your coins so it comes with a certain risk I'd love to see dooglus setup a stake pool Read about "offsite investing" in the Just-Dice FAQ. By default JD investments are really quite safe because they are very diluted by people taking advantage of this "offsite" thing. There has never been a week over which any CLAM investor who was invested without using the "offsite" feature made a loss at Just-Dice. But if you want a pure staking pool, check smooth's offering. |
|
|
|
First you told me some kinds of bets would get me disqualified: For example - user gets a 'big win' and then bets on lower odds to clear his bonus. That user is thereby disqualified.
But when I asked for details you told me that I can play however I want and that the system would adjust the rollover: You're allowed to play any game that allows you to play bonus money.
The amount of a bet that is applied to the rollover is automatically adjusted for the odds of the game.
So which is it? Do you disqualify some people because of how they play? If so, how can I avoid being one of those people? What are the rules? And can you explain the "automatic adjustment"? Are you saying that some 1 BTC bets don't count as 1 BTC wagered for the wagering requirements? I saw nothing about that when reading about the bonuses. |
|
|
|
Here's a fun thing:
Pick a random point in time, then:
A) the average amount of time from that point to the next CLAM block is 1 minute
B) the average amount of time from that point to the previous CLAM block is also 1 minute
C) the average time between CLAM blocks is also 1 minute
Wouldn't you expect A + B = C? Yet A, B, and C are all 1 minute.
I don't believe that's a valid equation for the problem. Why on earth not? If the last block was B seconds ago and the next block is in A seconds, then how far apart are the two blocks? Isn't it A+B? The above is the kind of math politicians use...  If X is the time of the block picked. A is the time of the next block B is the time of the previous block C is the average block time. Then (1+( ( ((X+A) + (X-B)) /2) - X)) = C should give you C as the average block time. What is "average block time"? Suppose blocks were found every minute, at the top of the minute, and my random point is 30 seconds past the minute. It's 30 seconds since the last block and 30 seconds to the next block. The time between blocks is 30+30. ie. A+B=C I did mean for A to be the expected time to the next block (ie. 1 minute), not the time of the next block (ie. Tuesday at 12:34 or whatever). A, B, and C are all 60 seconds. A) From a random point in time we all agree that the expected time to the next block is 60 seconds. I don't think anyone's going to argue with that (except that we find blocks a little too fast, so it's actually 59 seconds or something, but let's ignore that. B) I don't think anyone can really make a reasonable argument that the same isn't true about the expected time to the previous block. Just record the block creation process happening and play it backwards. It's indistinguishable from playing it forwards. Like smooth's sliding paper revealing the blocks. You can slide in either direction and the expect time to the 'next' block (which is the 'previous' one when sliding backwards) is 60 seconds. C) Can anyone argue that the expected time between blocks is not 60 seconds? I put it to you that A, B, and C are ALL equal to 60 seconds, and that this isn't a contradition. There is a rational explanation for this. I just like to make people figure it out for themselves -- dooglus the deceiver |
|
|
|
CLAM is a centralized coin. It's basically whatever Dooglus says since he is basically the King/President of CLAM. He can change core rules, reverse transactions and pretty much anything else he'd like or felt was "fair".
So you are saying I could have stopped digging if I wanted to, but I didn't stop digging. Doesn't that imply that I don't want to? Basically, if the CLAM developers wanted to remove digging it would be gone already. We can change the client code and we control the majority of the coins. And yet we didn't do it. I don't think any of us want to make an unpopular change to the rules, but we are all happy to make a change if the community shows sufficient support for it. That is all. |
|
|
|
You should claim your money before the developers remove the digging in order to protect their and early diggers coins "value"... this was a big talk not very long ago... they want to completely change the core distribution of the coin because there was to many sellers.
This isn't true. I don't think any of the CLAM developers want to stop digging. What we want is for the community to decide whether it happens or not. Currently it appears that the community wants digging to continue, and so digging is continuing. |
|
|
|
|
Show Posts
