1. stake with 1300 Clams is about 1 clam a day
Just-Dice is staking 1.428 million CLAMs and stakes about 1310 per day. That means that each 1090 CLAMs stakes 1 per day. Almost all the CLAMs in existence are on Just-Dice.com, so I guess it's fair to say most of the utility of CLAM is that site. I also stake in just -dice, but by my calculations(since 11th July), only each ~1170 clams stakes 1 per day (including bankroll profit). ~7% too high uncertainty ? Oh, well Just-Dice takes a 10% fee from staking rewards. So each 1090 will get you 0.9 per day, and to get 1 per day you'll need 1090 / 0.9 ~= 1211 |
|
|
|
1. stake with 1300 Clams is about 1 clam a day
Just-Dice is staking 1.428 million CLAMs and stakes about 1310 per day. That means that each 1090 CLAMs stakes 1 per day. Almost all the CLAMs in existence are on Just-Dice.com, so I guess it's fair to say most of the utility of CLAM is that site. |
|
|
|
Is there a way to short onecoin?
No, it isn't a real coin and isn't traded anywhere. |
|
|
|
What is the max supply cap of CLAMS?
There's one born every minute. What's the max supply cap of minutes? Also, khashier.com seems to be down. xploited? |
|
|
|
This one staked 5 times in 8 days, despite only being worth 26 to 30 CLAMs for most of that time:
That one recently staked again, for 6 stakes in 17 days: (edit: 7 stakes in 19 days!) 84d121 -> 100 CLAM 1044120 (2016-06-21 22:14:24)
cbdfb7 100 -> 26 CLAM 1045413 (2016-06-22 18:53:20)
a799ea 26 -> 27 CLAM 1050053 (2016-06-26 00:42:40)
c6709f 27 -> 28 CLAM 1050991 (2016-06-26 16:32:00)
00d648 28 -> 29 CLAM 1052089 (2016-06-27 11:02:40)
e58636 29 -> 30 CLAM 1054628 (2016-06-29 05:42:24)
4170b5 30 -> 31 CLAM 1067683 (2016-07-08 09:20:16)
60ca71 31 -> 32 CLAM 1070634 (2016-07-10 10:57:52) I'm still monitoring the JD staking wallet. It started out with 13k outputs of size 100 CLAMs each, and I set it to split to 25 CLAM outputs when it stakes. I counted the number of outputs of each size each morning, and plotted those counts on a log scale:  I'm not sure this is of interest to anyone other than myself but it's kind of pretty so I thought I'd post it anyway. |
|
|
|
Hey dooglus, thank you for your explanation, it cleared up alot of things for me. Don't u know me from the just-dice chatbox? I was prety active there in february/march, untill I got a big 250$ loss and quited gambling. Now I just show up to chat and chill with the community  Yes, I remember you. I said hi to you when you turned up recently I thought. |
|
|
|
Do u know by any chanche how much clams are staked every 24 hours on just-dice.com?
You can see daily stats here: https://just-dice.com/misc/wagered.txtIt looks like it's been around 1300 per day recently. Interesting facts, so when 1440 clams are getting created everyday, will this number that is being created everyday increase? Since there are more total clams so the total stake per day also increases? So if the price stays the same and I stake for a year, I will make profit.  No, the difficulty of staking is automatically adjusted so that the network as a whole stakes one block per minute on average. Each block awards 1 CLAM (plus transaction fees) to the staker. So that's 1440 CLAMs per day. Even though the rate of staking is constant at 1440 CLAMs per day, you will still make a profit if you stake for a year and the price remains the same. But I see no reason why the price should remain the same - the number of CLAMs in existence is constantly increasing, so it kind of makes sense to me that the value of each individual CLAM should decrease at a similar rate. It's the market cap that we would expect to stay the same, not the price per unit. By what do I know. |
|
|
|
Note: I tried to get a proof of this with my balance and a calculator but didn't got the same results maybe I'm missing something or using the calculator wrong (like most of the time) so better wait to someone else with better maths to confirm if it is like i wrote it.
You got all the details right: 1) stake rewards are split in proportion to onsite invested amount 2) rewards are accumulated and given out every 3 minutes 3) 10% is taken off the top of the staking rewards before they are given out, not at the end of the week Here's how the calculation works. Divide your onsite amount by the total onsite amount, multiply by 0.9 and multiply by the stake amount. That will give you your share of the stake reward. For example:  |
|
|
|
So send him the money; +80 BITCOIN. Like dooglus.
I'm not saying I would pay out cheaters. I am saying that to my knowledge Just-Dice hasn't suffered from any cheaters. Hi, I meant, the only 2 trusted sites for me are just dice and betking.
Oh, sweet. Pd always has one issue or the other to keep them ib the news. All this pd stories are beginning to look like publicity stunts.
But this is bad publicity. Why would they do this on purpose? It makes them look bad. |
|
|
|
Any suggestions on a similar gambling site but which is very reliable. I would appreciate some suggestions.
BETKING AND JUSTDICE. Stay off of and rollin. They will try to rig you, if they cant they will say u cheatedvand wont pay u. Are you recommending betking and just-dice or saying they will "try to rig you"? Both sites are provably fair. just-dice.com has never refused a withdrawal to any player, never accused any player of cheating, and never "tried to rig" anyone. I remember one case where betking (in a previous life) refused to pay one player who had cheated them, but nothing of the kind ever happened on just-dice.com. We did pay one guy 1300 BTC too much one time by mistake, but that's different. |
|
|
|
There will not be much development going on for the current app, efforts are focused on the new shiny next generation Some feature requests for the next generation: 1) Allow me access multiple receiving addresses so I can issue more than one invoice at a time 2) Offer some kind of proper wallet encryption feature. A 6 digit code just doesn't cut it. I want something like Bitcoin Core has, so that when my phone is stolen I know it will take the thief a significant amount of time to access my wallet seed. Currently I think all he needs to do is root the phone and my seed is there in plain text. That's a worry. 3) Allow me to use my own local bitcore server instead of a central Mycelium server for blockchain queries and transaction broadcast. |
|
|
|
Another method of mirroring https://www.bitaddress.org(fX) rd rd d d RD rd Rd rdrd rdrd rd 1E38XQRdXVha fXoAXwSZyoxPQ7R5HtmfrW 17na83aXEao3j fXJXEN4uuvchgAjg1Mw1S Can you provide us with the name of your darknet market vendor? That's good shit you're taking. |
|
|
|
Played for a while today, was rewarded with a 100+ clam profit overall. Thanks doog  Um - you're welcome? How much did you wager overall to win 100 CLAMs? I was going to post a chart of your victory, but I've not been able to find the account number. |
|
|
|
I do not have the knowledge to read code to know how clam works.
The code is multi-threaded. So the part which loops through your own outputs checking whether they can stake runs in parallel with the part which accepts new blocks from peers. Checking the staking wallet logs I do see that it continues to search its own outputs even if it accepts a block from a peer while searching. Here's an example: starting stake
CWallet::CreateCoinStake() iteration 0
CWallet::CreateCoinStake() iteration 15000
CWallet::CreateCoinStake() iteration 30000
CWallet::CreateCoinStake() iteration 45000
CWallet::CreateCoinStake() found no stake
stake took 4s
starting stake
CWallet::CreateCoinStake() iteration 0
CWallet::CreateCoinStake() iteration 15000
stake 1.00 for xB2ecbVboyD513HJfvzvxw3tuNfRcUVUXv; not mine
SetBestChain: new best=5b2e7337902bc3e230541d1c47f135cd23efb2b984bc744aac54a5f14161691e height=1070779 trust=255420176884548245025 blocktrust=523267355223939 date=07/10/16 13:24:16
ProcessBlock: ACCEPTED
CWallet::CreateCoinStake() iteration 30000
CWallet::CreateCoinStake() iteration 45000
CWallet::CreateCoinStake() found no stake
stake took 2s
starting stake
CWallet::CreateCoinStake() iteration 0
CWallet::CreateCoinStake() iteration 15000
CWallet::CreateCoinStake() iteration 30000
CWallet::CreateCoinStake() iteration 45000
CWallet::CreateCoinStake() found no stake
stake took 3s In this case we didn't find a block, so the peer's block won. I'll see if I can find an example where JD found a block after hearing about one from a peer. Edit: I can't find any. I suspect that although it continues looping through all the unspent outputs, accepting the peer's block has somehow made it such that no local stake will be accepted and so it's a waste of time to even continue searching in the current time slot. |
|
|
|
Picture the same set of inputs, but a set of outputs all denominated in 30BTC, 10BTC, 3BTC, 0.1BTC, O.03BTC, etc.
I like the idea of using powers of 2 as the change amounts. That way any amount can be created by using at most one of each size of change. WRONG plan! You want at least ten outputs of each denomination you're creating. The whole idea of standardizing denominations is for txOuts to be indistinguishable. The only one of a given denomination created in a transaction is VERY distinguishable from all other outputs. At most one of each size goes to each participant. Each output goes to a different address. |
|
|
|
If I'm not wrong, if 77.86% of the total CLAMS in existence are on Just Dice, then the maximum multiplier should be 1/0.7786 if people were using this functionality as "it should" be used (that's assuming 100% of the CLAMS were owned by investors, which obviously is false and therefore the multiplier should be even smaller). So someone is lying there (and making a profitable investment become an unprofitable one by not understand variance).
You're not wrong that something around that percentage of all CLAMs are on Just-Dice. But I don't understand why you think the maximum multiplier should be that low. If I have $100 worth of CLAMs on the site, but have $900 worth of BTC in a cold wallet which I also consider part of my "bankroll", why wouldn't I set my multiplier to 10x? Then I get returns *as if* I had converted my $900 worth of BTC to CLAM and invested it without having to actually do that conversation. If I do that, there is a risk that my $100 worth of CLAM on the site is wiped out by a lucky player, but that's a chance I am willing to take in exchange for an increased share of the site profits. I can't answer your "someone is lying" comment unless you are more specific about who is lying, and how. But maybe the above example helps clarify things. The declared offsite amount doesn't need to actually exist in the form of CLAMs (or at all, in fact). |
|
|
|
What's the optimal multiplier knowing 1% is the edge? 1%? I see the average multiplier is 19.68.
What are you attempting to maximize with respect to the multiplier? Where do you see the average multiplier? Edit: having now read your later post I see you are talking about the offsite-invest multiplier, not the gambling multiplier. The optimum would depend on the total value of all the assets you consider part of your bankroll, as well as less tangible things like how risk averse you are and how much you trust the site to play fair. Personally I use the maximum available multiplier, because less than 4% of my 'bankroll' is in the form of CLAMs, and so even using the maximum (25x) multiplier still risks less than 100% of my total bankroll. What does "bankroll profit" mean?
Investors make profit in two ways: 1) from bankrolling the site - they profit when players lose, and lose when players win. 2) from having their coins staked We refer to 1) as "bankroll profit" and 2) as "staking profit". The sum of the two is "invest profit". You'll see all three on your stats tab in real time. |
|
|
|
>The JD staking wallet does often have two outputs which are able to stake at the same time, and so only the first of them gets to stake.
It may be so, but I was more curious about the the actual hashing events being serialized. Lets say a a wallet had 1 million inputs, then how long would it take hash all 1 million inputs? My guess is the first 1/2 million would have a greater probability to stake and not orphaned then then last 1/2 million just due to the time it takes to do hashing.
Doesn't the 1st person who has a valid stake and propagates over the network win?
Oh, yes. If it takes you more than 16 seconds to check all your outputs then you're going to be missing out of some stakes. I am able to check about 15k outputs per second, and have around 46k outputs attempting to stake at any given time, so it takes 3 or 4 seconds to check for stakes. You wouldn't want to have a million outputs unless you had a significantly faster staking machine. You would want to combine some of those outputs into a more manageable set. I'm not sure what happens if one of your peers sends you a block while you are working through your outputs. Maybe you stop working and use the peer's block, or maybe you keep working hoping to find an output of your own which can compete with the peer's block. |
|
|
|
I wonder if the size of the staking wallet affects the probability of staking. Although POS doesn't require as much work as POW, there is still hashing going on for each input. For smaller wallets this time is small . However for a large wallet or wallets with lots of tiny inputs, then I assume clam client does the hashes in a serial fashion which cause the 1st inputs to have a higher probability to stake vs ones which happen later in time.
The JD staking wallet does often have two outputs which are able to stake at the same time, and so only the first of them gets to stake. This one staked 5 times in 8 days, despite only being worth 26 to 30 CLAMs for most of that time:
That one recently staked again, for 6 stakes in 17 days: (edit: 7 stakes in 19 days!) 84d121 -> 100 CLAM 1044120 (2016-06-21 22:14:24)
cbdfb7 100 -> 26 CLAM 1045413 (2016-06-22 18:53:20)
a799ea 26 -> 27 CLAM 1050053 (2016-06-26 00:42:40)
c6709f 27 -> 28 CLAM 1050991 (2016-06-26 16:32:00)
00d648 28 -> 29 CLAM 1052089 (2016-06-27 11:02:40)
e58636 29 -> 30 CLAM 1054628 (2016-06-29 05:42:24)
4170b5 30 -> 31 CLAM 1067683 (2016-07-08 09:20:16)
60ca71 31 -> 32 CLAM 1070634 (2016-07-10 10:57:52) Whereas previously we would expect one of the thousands of outputs to be lucky, it's kind of surprising that the one which was previously the luckiest staked again in just 9 days when we would expect it to take around 33 days (edit: and then it staked again, just 2 days later!). I added some code to spit out the txid and value of every 1000th output as it's checking for staking to see what order it checks in: CWallet::CreateCoinStake() iteration 0
txid 9b85808e67aee6e2c6873a1ec1ad41a49050683506d1154714602f6be030f504 value 100.00
txid 9c289f367372d4f070bb67a49b1886532da0d19113a47fbeee17f2b682a2b909 value 25.00
txid c63ec1be3e4fb7dd0b8cac27aa407449160ecf1147c320cd0e86de630789ab0f value 25.00
txid 380d0d52ec8bd8bdc383c2a1317b77d9292fc4d7680eebc4b3c4ea9f457bfe14 value 26.00
txid c49f9e7812f309cb723fa55a78400c5f5ddf55891c837f9f17125873fedf941a value 25.00
txid b652f5dcc4da57683d12142e6e76d1d2022e78da0ab12e4de0f3d6f042f85220 value 25.00
txid cdb02cd119f8c2fb32792ce9770acf95e27b9c7c00b5d58452c63929ecb78026 value 26.0001
txid 98aa0297c835e372424957c4b0a58181ee223d95fed7d02ec2c849dcf1752c2c value 27.00
txid 7975bca559eee9b09d89d7a4e38faa47fdd99172d736c7bd81e343606907f231 value 25.00
txid 3a1951620a08d2a2591d947f2e5f6380829b544f051bff9c0225760ce86b3037 value 25.00
txid 7f3a568871c79cd361ec4f2a41d2493f4fa041b39458673c22f29ec45d54773c value 25.00
txid 1f49fb96685c2622a7487553dea48eced365704e83005cbbb56d17330acf4641 value 26.00
txid 3e5542b64c4fe1b57f69e588a86706843f396c930666a2ae4938941a38393946 value 28.0002
txid 9adeffdd5736b070872462f7b5e41053edbeacbda6322cc7ca7a983e64c1814c value 25.00
txid 9bb6a0b9bf8a299bd01c0234c6acaf69f5604b028d3f1a7f36463a513192bc51 value 25.00
CWallet::CreateCoinStake() iteration 15000
txid f02005c4188851983e3fb00cb712e109e243f112c09333331e85911153309c56 value 25.00
txid c9232307df0c5c66c81b6b312d8c14507f7fb0be84ffb32a2f6df26e9433b15b value 25.00
txid 028a55a175e3581e2520241989de310c91d5b9e915960ee7001923a8cc3bc661 value 25.00
txid 1fff98a5e28678325cce78b9b43feecc8c1cf3d63bc7f1888f5ed72150a86267 value 25.00
txid 1b998d7b47d236c907f1fb4235fad9efb7a2032c257063f792a365270d0eb96d value 25.00
txid aaba3fcbd7df14974f491253f3142bc2c984a46fa39a14511cba8b61e7e76473 value 25.00
txid aa7614f556a41fced204ba11821d3cd07324c18b2d0ac489237f09d787b30e79 value 26.00
txid fdd26dccb3ef7197cfffae0a859bece6e55c2ba81bf2ac99f8258c043c8a9f7e value 25.00
txid 1f92ef18964027cd356d0025302fa7e2b257911efc353eb377570a8824117d83 value 26.00
txid 4b85edb826508142db9af391888dd656b724db06b8d91716fa00c2759b5e0989 value 25.00
txid c1d837611f12d402460918e95a77525af840954b36d69b497f9d0488e2f89e8f value 26.00
txid d85223cf502c00371dbb325ac9ffebe2fdaebdc3d3d1332ccaa94e9856b2b495 value 25.00
txid 97dcb886be8e55871befab8bfa49361b68806ce64ce1a067371867dd2201e59b value 26.00
txid 702744a0c84026f60ff2e2be867a6e4289c80d5066fe24f5b2e14c615a2f4ca1 value 25.00
txid f8236b917599b1be1fa4b664347e860bab45f87c02a3c777ee45333fa5cdd7a7 value 27.00 So it's not sorted by txid or value, but it does seem to always be in the same order. |
|
|
|
So, how do you provide a new address to each person?
I am relatively new to BTC, so forgive me if this is a stupid question. I have tried to search for the answer but haven't found anything that answers this specific query.
As I understand it, there's no way to get Mycelium to generate a new receiving address until the previous one has received funds. It's not a stupid question, it's a stupid mis-feature of Mycelium. People have asked to have this improved in the past (in this thread I think) but I don't think the developers saw it as a desirable feature. If I'm trying to split a restaurant bill 5 ways I want to be able to give one address to each of the 5 people. I don't want to have to wait for each person to pay before I am allowed to generate the next address. That's just silly. You can use a site like https://dcpos.github.io/bip39/ to generate as many receiving addresses as you like, but it's kind of inconvenient. The site works offline - you can save it to a memory stick and load it on an offline machine (so you don't have to type your seed words on an online machine). I'll see if I can find the post I'm thinking about, and will update this message if I do. Edit: maybe this is what I'm thinking of - it appears adding the ability know more than one unused receiving address at a time is "on their list", and has been for nearly 2 years now: With the latest version, if I have given someone the displayed receiving address how do I get another address for payments before a transaction has been sent to it?
Currently thats not possible - but its on our list!
There will be an option to show multiple unused receiving addresses eventually.
It shouldn't be a problem to receive more than one payment to that same address, since all your old addresses are monitored for payments. There might also be an issue that, since HD wallet addresses are generated sequentially, the wallet scans each address to see if it's empty, and if it is, assumes that it was the last one used and doesn't scan for any new ones (we scan 2 ahead). So there may be an issue where, for example, you give three people an address to send to, each one having a new address, and the first two people don't send anything. Since those addresses will be empty, the wallet will think that it's the end of the used addresses and that there are no payments to any later addresses, and the third person's payment (or any after it) will not show up. Only way to get around that is to scan ahead for even more addresses, and/or limit the amount of empty addresses you can generate. But as I said, there shouldn't be a problem with two people sending to the same address.
Should we manage to implement stealth address payments, this won't be a problem anyway.
When we implement support to generate more receiving addresses, we will of course adjust the lookahead accordingly. At the moment it's 2 for synchronizing and 20 for discovery (like when importing or activating an archived account).
|
|
|
|
|
Show Posts
