 Show Posts
|
|
Pages: [1] 2 3 »
|
Whats the hex string after the -CP? Remember this? Bounty offer: I need two new CLAM vanity addresses. One for the hot wallet, and one for the staking wallet. I want them both to start with xJDCLAMZ, case sensitive. I want them both to use *compressed* public keys. The standard vanitygen program isn't able to make CLAM addresses. I made a fork here: https://github.com/dooglus/vanitygenwhich does. Well, I need another xJDCLAMZ address. Just the one this time, but I'll pay 100 CLAMs for the first to find it (unless I find it first). Get and build the CLAM-compatible version of vanitygen from here: https://github.com/dooglus/vanitygenThen run this command: oclvanitygen -CP 0257DEAE526EEF77D275447D70F233DCF0DBF50AF0C239AD0C46CE1A6D48849B1F xJDCLAMZ
C for 'compressed', 'P' for 'public key'. The public key means only the person with the corresponding private key (ie. me) will be able to know the actual private key you find. Post the key it finds here, and I'll pay 100 CLAMs to the earliest dated non-edited such post. |
|
|
|
Was there ever a time they where equal? To clarify, if you make infinite rolls (10^100000000000000000000000000000000000000000000000000000000000000000000000000...) the heads and tails tend to even out. But when you take 10 or a trillion rolls, there is no such concept. Yeah, it is mostly correct, but if it was to even out, as the rolls go by, the tails would have more odds than heads which is incorrect. So Phildo is not exactly wrong, but in this particular part, leex is 100% correct.  tl'dr There is no such thing called evening out in practical cases/finite rolls. But the local probability always converge to the basic probability. I just rolled 20000000 times with the virtual coin and turned out: 10000630 heads and 9999370 tails, which is very close to eachother. Maximum consecutive is 29  |
|
|
|
|
This is just a guess between 35 - 15. But if I was to bet chance 35 and below and win in about 12 bets
Edited - I just saw the pastebin, I wish you didn't do that. now my answer means nothing.
Never said I can predict the next roll, just be educated in what bets do and when.
Basically when I simulate a betting idea, checking maximum loses before a win happens. I do this with many server seed and client seed pairs. Once I believe I got the maximum loses possible I add 10% to that number and then back in to the biggest bet I can make without going bust.
|
|
|
|
Which dice site? I'll agree with if you show me your betting simulations and state which dice game algorithm you used.
All I can tell you is I have made a dice simulator for JD and PD and if you group the results by 10s you do reach a point where you approach equal distribution of numbers.
Using this method I can within a good % know that a bet will win in a worst case situation.
Let us check.  Server seed hash 3aaac305ec911f3dc3965c731dfe6db16902eb23822487a593114e68922c9e32 Server seed a151b24df86e5dea2ef3--snip--- Client seed ndnhc What is the 89th nonce roll? Nonce: 88 - roll: 98.89
Nonce: 87 - roll: 56.1
Nonce: 86 - roll: 35.51
Nonce: 85 - roll: 52.52
Nonce: 84 - roll: 54.18
Nonce: 83 - roll: 6
Nonce: 82 - roll: 68.76
Nonce: 81 - roll: 16.11
Nonce: 80 - roll: 66.23
Nonce: 79 - roll: 0.46
Nonce: 78 - roll: 36.88
Nonce: 77 - roll: 59.19
Nonce: 76 - roll: 79.42
Nonce: 75 - roll: 40.23
Nonce: 74 - roll: 63.26
Nonce: 73 - roll: 63.24
Nonce: 72 - roll: 21.22
Nonce: 71 - roll: 4.21
Nonce: 70 - roll: 48.35
Nonce: 69 - roll: 59.79
Nonce: 68 - roll: 60.91
Nonce: 67 - roll: 41.93
Nonce: 66 - roll: 23.16
Nonce: 65 - roll: 30.72
Nonce: 64 - roll: 85.32
Nonce: 63 - roll: 80.74
Nonce: 62 - roll: 26.08
Nonce: 61 - roll: 98.65
Nonce: 60 - roll: 80.26
Nonce: 59 - roll: 90.74
Nonce: 58 - roll: 95.12
Nonce: 57 - roll: 18.41
Nonce: 56 - roll: 19.54
Nonce: 55 - roll: 92.7
Nonce: 54 - roll: 31.53
Nonce: 53 - roll: 20.12
Nonce: 52 - roll: 82.97
Nonce: 51 - roll: 92.78
Nonce: 50 - roll: 24.69
Nonce: 49 - roll: 91.51
Nonce: 48 - roll: 42.3
Nonce: 47 - roll: 18.55
Nonce: 46 - roll: 48.49
Nonce: 45 - roll: 42.94
Nonce: 44 - roll: 22.84
Nonce: 43 - roll: 76.58
Nonce: 42 - roll: 93.79
Nonce: 41 - roll: 91.96
Nonce: 40 - roll: 75.94
Nonce: 39 - roll: 74.44
Nonce: 38 - roll: 54.75
Nonce: 37 - roll: 6.88
Nonce: 36 - roll: 92.08
Nonce: 35 - roll: 83.98
Nonce: 34 - roll: 44.43
Nonce: 33 - roll: 9.52
Nonce: 32 - roll: 84.54
Nonce: 31 - roll: 5.33
Nonce: 30 - roll: 88
Nonce: 29 - roll: 86.96
Nonce: 28 - roll: 87.83
Nonce: 27 - roll: 53.67
Nonce: 26 - roll: 81.23
Nonce: 25 - roll: 63.29
Nonce: 24 - roll: 44.41
Nonce: 23 - roll: 29.08
Nonce: 22 - roll: 79.29
Nonce: 21 - roll: 81
Nonce: 20 - roll: 66.28
Nonce: 19 - roll: 78.82
Nonce: 18 - roll: 45.61
Nonce: 17 - roll: 6.91
Nonce: 16 - roll: 97.79
Nonce: 15 - roll: 94.84
Nonce: 14 - roll: 37.74
Nonce: 13 - roll: 45.23
Nonce: 12 - roll: 72.75
Nonce: 11 - roll: 17.79
Nonce: 10 - roll: 28.56
Nonce: 9 - roll: 2.33
Nonce: 8 - roll: 13.51
Nonce: 7 - roll: 70.9
Nonce: 6 - roll: 53.81
Nonce: 5 - roll: 72.72
Nonce: 4 - roll: 36.48
Nonce: 3 - roll: 9.2
Nonce: 2 - roll: 63.17
Nonce: 1 - roll: 96.17
Nonce: 0 - roll: 42.1 Edit: PrimeDice. I can give thousands, just doesn't want it too long, lol. |
|
|
|
I'll agree with if you show me your betting simulations and state which dice game algorithm you used. All I can tell you is I have made a dice simulator for JD and PD and if you group the results by 10s you do reach a point where you approach equal distribution of numbers. Using this method I can within a good % know that a bet will win in a worst case situation. If you would run a simulation of bets/rolls (same server seed and client seed) the outcome over many bets should roughly show equal distribution of numbers. It might happen in 1000 bets, 10000 bets, or 100000 bets, but it will happen. But knowing this will happen allows you to change the way you bet in your advantage.
Now if you say there is not equal distribution of numbers, that's even better. You can determine where most of the roll/bets hit and play that to your advantage.
Either way, not looking to the past results to determine the way you play dice is why most call it a luck game.
Which is called gambler's fallacy. The funny thing is you are the first guy I have seen who have that fallacy for select (may be only for pseudo random) cases but does not have it for the rest. LOL, your evening out strategy doesn't work. Pseudo random is kind of pre-determined random (in this case) numbers generated using a certain method. It is not predictable and does not even out (esp. in finite rolls).
That's what I was showing. It is unlikely to get 10 heads in a row. But if you do, the next one is still 50/50, AND you will get to 50/50 over the long term without changing the odds.
Yeah I was mostly agreeing with you, but sort of. I was saying the dice don't know that they rolled 10 heads in a row, so even after the 10 rolls it won't start to go more toward 50/50, from that point on it would be closer to 50/50, but after I suppose 100000 rolls if you had 10 more heads than tails it still would be close to 50/50. To clarify, if you make infinite rolls (10^100000000000000000000000000000000000000000000000000000000000000000000000000...) the heads and tails tend to even out. But when you take 10 or a trillion rolls, there is no such concept. Yeah, it is mostly correct, but if it was to even out, as the rolls go by, the tails would have more odds than heads which is incorrect. So Phildo is not exactly wrong, but in this particular part, leex is 100% correct. tl'dr There is no such thing called evening out in practical cases/finite rolls. |
|
|
|
If you would run a simulation of bets/rolls (same server seed and client seed) the outcome over many bets should roughly show equal distribution of numbers. It might happen in 1000 bets, 10000 bets, or 100000 bets, but it will happen. But knowing this will happen allows you to change the way you bet in your advantage.
Now if you say there is not equal distribution of numbers, that's even better. You can determine where most of the roll/bets hit and play that to your advantage.
Either way, not looking to the past results to determine the way you play dice is why most call it a luck game.
This is 1000 percent wrong. Lets just look at flipping a coin to make things simple. The equal distribution happens from having the correct probability happen over and over and over again over a large sample. If you flip 10 heads in a row, the odds of the next one being heads is still 50/50. If you keep flipping a coin, eventually your results will get to 50/50, not because tails is more likely on future events, but just because you keep doing it. If you get 10 heads out of 10 flips you got heads 100% of the time. If the next 10 are 50/50, you have 15 out of 20, 75% heads If the next 10 are 50/50, you have 20 out of 30, 66 2/3% heads If the next 10 are 50/50, you have 25 out of 40, 62.5% heads If the next 10 are 50/50, you have 30 out of 50, 60% heads. And so on and so on until you get back down to 50. You are comparing something that is truly random(flipping of a coin) to a algorithm. Have you run a simulation with the algorithm from a dice site? I also notice that in your example that your approaching 50% as more flips happen, which is what I'm saying. |
|
|
|
|
If you would run a simulation of bets/rolls (same server seed and client seed) the outcome over many bets should roughly show equal distribution of numbers. It might happen in 1000 bets, 10000 bets, or 100000 bets, but it will happen. But knowing this will happen allows you to change the way you bet in your advantage.
Now if you say there is not equal distribution of numbers, that's even better. You can determine where most of the roll/bets hit and play that to your advantage.
Either way, not looking to the past results to determine the way you play dice is why most call it a luck game.
|
|
|
|
Each bet is not independent of each other. Each bet is determined by a algorithm where a nonce is incremented each bet. Which means each bet is dependent on all previous bets, since the bet with nonce=10 would never exist without the previous 9 nonces.
The algorithms that determine the outcome are pseudo random and not truly random.
The result is independent. If I give you 10 rolls, can you predict the next? No. That is referred to as independence here, of the result. The 11th roll is dependent on the server seed, client seed, and nonce and the previous rolls. Example: roll 1: 0.65 roll 2: 0.23 roll 3: 0.99 roll 4: 0.55 roll 5: 0.09 roll 6: 0.13 roll 7: 0.33 roll 8: 0.67 roll 9: 0.04 roll 10: 0.97 I would be willing to bet that the next roll will be higher then 1. But without the knowledge of the previous 10 bets I wouldn't. At the same time I would like to see a server seed, client seed, nonce produce rolls anywhere close to what I listed. |
|
|
|
The only way to win at dice is to play 3 strategies at the same time.
Example:
start at 1 satoshi at 10x payout doubling the bet after 5 losses in a row. Reset the bet back to 1 satoshi after a win.
FOR BETTING LOW
At the same time keeping track of any rolls\results of less then 1 and how many bets you have placed. Once you reach 500 rolls without a roll/result being under 1, start betting at 99x payout and double the bet after 48 losses in a row. Reset the bet back to 1 satoshi and 10x payout.
FOR BETTING HIGH
At the same time keeping track of any rolls\results of greater then 99 and how many bets you have placed. Once you reach 500 rolls without a roll/result being over 99, start betting at 99x payout and double the bet after 48 losses in a row. Reset the bet back to 1 satoshi and 10x payout.
repeat
Each bet is independent. After 500 rolls without <1, the chance to have <1 does not change but is still the same at exactly 1%, so the "switch" part doesn't quite work. Also, even if a very low base bet at 1 satoshi, you will quickly run out of fund to continue doubling your bet when you hit a long losing streak. In short, your strategy would not work in the long run. Indeed, no strategy would work in the long run for the luck based dice game with negative EV. Each bet is not independent of each other. Each bet is determined by a algorithm where a nonce is incremented each bet. Which means each bet is dependent on all previous bets, since the bet with nonce=10 would never exist without the previous 9 nonces. The algorithms that determine the outcome are pseudo random and not truly random. |
|
|
|
|
The only way to win at dice is to play 3 strategies at the same time.
Example:
start at 1 satoshi at 10x payout doubling the bet after 5 losses in a row. Reset the bet back to 1 satoshi after a win.
FOR BETTING LOW
At the same time keeping track of any rolls\results of less then 1 and how many bets you have placed. Once you reach 500 rolls without a roll/result being under 1, start betting at 99x payout and double the bet after 48 losses in a row. Reset the bet back to 1 satoshi and 10x payout.
FOR BETTING HIGH
At the same time keeping track of any rolls\results of greater then 99 and how many bets you have placed. Once you reach 500 rolls without a roll/result being over 99, start betting at 99x payout and double the bet after 48 losses in a row. Reset the bet back to 1 satoshi and 10x payout.
repeat
|
|
|
|
|
My CLAM withdraw from 2 days ago is still "Pending". WHY!!!!
Then I go to support and to submit a ticket it asks me for a login and password to a site I have never been to, so do I have to register with their support site?
|
|
|
|
|
Why when I did a withdraw does the txid say "off-chain transfer". As of right now, the withdraw still has not happened and its really sad that the hot wallet balance doesn't have the tiny amount I withdraw.
Problem fixed, it was my fault.
|
|
|
|
|
I reset my password and then tried to change it to something else. Multiple times it didn't work.
I then decided it was best to withdraw all my coins and they are all stuck "pending".
Opened up a support ticket.
|
|
|
|
Still only have 1 active connection. If this is the norm, CLAM looks more centralized then decentralized. I just downloaded the 1.4.13 windows 64bit wallet and its syncing pretty fast, but its only connected to 1 active connection. This is after filling the clam.conf with a list of active nodes. What am I doing wrong?
|
|
|
|
|
I just downloaded the 1.4.13 windows 64bit wallet and its syncing pretty fast, but its only connected to 1 active connection. This is after filling the clam.conf with a list of active nodes. What am I doing wrong?
|
|
|
|
|
Just gonna keep on posting that my "pending withdraw" from Cryptsy is about 24 hours old and still a no show. Not even a reply from support about the ticket that is open. Cryptsy is so unprofessional.
|
|
|
|
Well my question is where can I buy CLAM and withdraw with no problems? Bought CLAM on Cryptsy and after 20 hours still waiting for my withdraw. I be willing to say they don't have them to sell, and that is why I'm having a hard time with my withdraw.
Overall I find Cryptsy pretty good but back in May it took me about a week to get my CLAM out, got there eventually. |
|
|
|
|
Bought CLAM on Cryptsy and after 20 hours still waiting for my withdraw. I be willing to say they don't have them to sell, and that is why I'm having a hard time with my withdraw.
*** WARNING *** Don't Buy CLAM at Cryptsy !!!!
|
|
|
|
Stunna, the token changed on me. Is that normal? I got a question about running a bot on pd. I have 2 VPS's and I ran a PD bot on each, but I appears both are banned. The time between bets was 1 bet per 0.6 sec. Just trying to determine why I have been banned and conform to what doesn't get you banned? Anybody have insite as to why?
You wouldn't be banned for something like that. If you failed to login to your account after a certain number of attempts it will be temporarily locked, try again in an hour. |
|
|
|
|
I got a question about running a bot on pd. I have 2 VPS's and I ran a PD bot on each, but I appears both are banned. The time between bets was 1 bet per 0.6 sec. Just trying to determine why I have been banned and conform to what doesn't get you banned? Anybody have insite as to why?
|
|
|
|
|
