The 'effective bankroll' (ie. actual investments times Kelly multiplier) was over 1000 BTC at the time. That means the maximum profit per bet should have been over 10 BTC. So when someone wins 20 BTC because the site is risking too much, it's not more than double the correct amount to be risking.

The most you should have been able to lose is 10% of your investment per roll.

Even taking this fixed 20 BTC maximum profit into account, the most you should have been able to lose is ~20% of your investment per roll.

So how on earth did you end up losing 29%?

It seems there's more than one bug here.

It will be interesting to hear DaDice staff try to explain their way out of this major fuckup.

Can someone explain how this guy was able to win around 20 BTC when the effective bankroll is only around 1000 BTC after taking Kelly multipliers into account?



The maximum profit per roll is meant to be 1% of the effective bankroll, which would be around 10 BTC.

Will the investors be expected to pay out of their own pockets for this error, if that is what it is?

I just tried finding that message. I checked https://twitter.com/myceliumcom but it wasn't there. Mostly that was retweets of stuff unrelated to Mycelium. Eventually I found it here: https://twitter.com/MyceliumCom/with_replies - mixed in with a lot of out-of-context replies to questions that I can't see without clicking - and the retweets are still there too. I have to scroll through pages of photos of people's feet and such like to find important announcements? Seems sub-optimal. There must be some better way of communicating important information directly affecting users of the wallet. Is the service back up now? Is it safe to use it? If not, is there an ETA for when it will be safe? Those are the questions I'd want to see addressed, maybe on a dedicated "service status" page so I don't have to get distracted by pictures of feet or Julia in short shorts.


While github is a good resource, I don't think its issue tracker is the place for announcements about back-end server issues. The issue tracker is for tracking issues in the 'open-source' components of their wallet, which I don't think includes the back-end server databases.


Let us know if you find anything good for Android. I had high hopes for airbitz but it wanted access to so much stuff on my tablet that I ended up not installing it.

I didn't realise you guys were at all involved with DigiShield, or I probably wouldn't have been so flippant about it. Which coin were you involved with which first added DigiShield? Was it a DOGE thing? I really don't pay much attention to other altcoins.

While we don't have to worry about multi-pools we do have to be able to cope with sudden changes to the total network stake weight. A big staker could go offline temporarily leaving the difficulty too high for a while, or someone could dig up a bunch of distribution CLAMs and start staking them, leaving the difficulty too low for a while. The effect is similar to a big multi-pool visiting.

With the first (single block) difficulty retargetting what would happen that due to variance we would see 20 second gap between blocks occasionally, and the retargetting algorithm would overreact, setting the difficulty far too high, and it would take quite a while for things to recover. That would leave us with >2 minute blocks for a while, when all that had happened was one staker got lucky once.

Are there any plans for a hard fork any time soon? If so, it would be worth experimenting with the various adjustment algorithms and seeing what we can do to improve things. I imagine running a simulation, plotting the difficulty over time with various different retarget algorithms, etc. If not, I don't think it's a big enough problem to warrant a hard fork on its own.

Splitting a CLAM into 10^8 separate outputs is going to cost you a lot in transaction fees.

Splitting is a case of diminishing returns. The gains you get from splitting 1 CLAM into two halves are far bigger than any gain from splitting those two halves into 4 quarters.

And yes, merging those outputs back into a single output will also cost you a fortune in transaction fees.

So it's a trade-off. There's pressure in both directions (too little splitting and your coins spend too much of their life "maturing"; too much splitting and you pay a lot of transaction fees both when splitting and when re-joining, and use too much CPU time checking all your outputs for staking opportunities), and so you can solve some equations to find the optimal splitting level based on how long you anticipate staking for, the speed of your staking machine, the price of CLAM, etc. (Or you can just set all your outputs to be 13.37 CLAM each because you think the number is 'kewl').

Doesn't sound right to me. I think it was cooler sounding.

I guess I'm thinking of this, from https://en.wikipedia.org/wiki/Dogecoin:


But KGW looks interesting too:

http://bitcoin.stackexchange.com/questions/21730/how-does-the-kimoto-gravity-well-regulate-difficulty

My point is that there are probably better ways to retarget the difficulty than the naive way we're currently doing it (which in turn is better than the way we were doing it before...).

Seems like I misread the option. i see the same as you, and don't understand the options. Maybe there isn't an option not to use Tor, idk. I don't have orbot installed, and so have always had 'Use https' selected, which shows up in the top level options as "(only https)". Maybe "Use https" means "don't use Tor", but it's really not clear.

I just wonder if there isn't a better way of doing it that doesn't cause this constant swinging up and down.

Is there a chart of the DOGE difficulty over time I wonder. They use some difficulty adjustment system with a fancy name that I forgot. Turbo lightning. Black vortex. You know, something silly like that...

Three things:

1) When the time granularity changed from 1 second to 16 seconds, another accidental change went in at the same time which missed out a factor of 10^8 in the difficulty calculation. It made blocks 100 million times easier to solve, but gave us 16 times less chances to try, so the two factors combined made it 6.25 million times easier than before to stake. As a result everyone was staking every 16 seconds, everyone was orphaning everyone else for a few hours, the network difficulty adjusted upwards very quickly, and after 3 or 4 hours everything was back to normal. Is was kind of amazing to watch the difficulty adjustment code do its thing and deal with the accidental 10^8 error. Do you have long-term difficulty charts? If so you'll easily see the time I'm talking about. You need a log scale, or it will look like the difficulty was 0 before the steep rise.

Edit: I don't see how to adjust the date range on your chart, but http://blocktree.io/charts/CLAM shows this:



The difficulty wasn't really 0 before November 2014, it just looks that way when you don't use a log y-axis.

2) I don't think the CLAM project is responsible for the 16 second granularity idea or code. I think it is from one of the upstream projects. I've never paid attention to any of them, but I think it was dark coin, black coin, or something like that.

3) The difficulty adjustment code was written by me specifically for CLAM, and went live at the same time as the v2 protocol and the 10^8 error. It's not ideal how it waves up and down several times per day, but it's better than the previous system of difficulty adjustment, which was far too reactive to how long the last 1 block took to stake.

Do you have "only use Tor" enabled? It's towards the end of the settings.

Thanks for forwarding it here. I rarely use Twitter and it didn't occur to me as a place to look for Mycelium annoucements.

I'm pretty sure I don't use Tor at all. I never enabled it in the settings, and so I guess the Tor server isn't the only server having trouble.

The nSearchInterval variable used to (before v2 of the protocol) be set to how many seconds since the last time we tried hashing, and the hashing function would then iterate through all those missed seconds.

In v2 we don't want it doing that, so we set the variable to 1 so we get a single iteration of the loop.

The 16 second mask thing makes it 16 times easier to find a block than it was before, since we get to try 16 times less often, but still want the same frequency of blocks being solved. This makes it 16 times more likely that two peers will find a block at the same time, and so we end up with 16 times as many orphans as before. Other than that it's cool though.

Oh, and as for SuperClam's "dooglus can verify and expound on this; but", I don't need to. She pretty much nailed it.

Good idea. When you're specific like that it's easier to pinpoint where we're talking at cross purposes.


No, I'm talking about kernel.h:


and main.cpp:


That is 'AND'ing the time with binary ~1111, ie. zeroing the last 4 bits, ie. rounding down to a multiple of 16.


No, because look at the lines before that:


It only gets into that block if nSearchTime is greater than the last search time. And nSearchTime has already been rounded down to a multiple of 16 seconds. So it will only get into this block at most once per 16 seconds.


... and now you can!

This is interesting. What terms and stakes do you propose?

We already do - we split the outputs in the JD wallets to be around 13.37 CLAMs each. I think that the rounding down doesn't happen any more - that was on old (the original?) version of the protocol I was describing.

I just replied to the posts you quoted in their own thread.

That's how long it takes to search for staking opportunities each 16 seconds. Most times you check you find that there isn't any such opportunity. There's only one per minute globally, so even with 100% of the staking weight you'd have around a 1 in 4 chance of any particular search being successful. When we do find a block, it will be at a random point through that 4 second search, and so on average a successful search takes 2 seconds ((0 + 4) / 2).


I don't think you're understanding still. "Difficulty leading to 16 seconds" isn't what's happening. The difficulty adjusts how hard it is to stake a block. It adjusts such that we find around one block per minute. But blocks can only be found when the time (in seconds since some date in 1970) is a multiple of 16. That only happens every 16 seconds. That's fixed by the protocol (until the developers change the protocol again, of course), and isn't related to the difficulty.


It's a real 4 seconds. 4 seconds out of every 16 seconds the CPU on one core of JD's staking wallet server is pegged at 100%. They're outputs of the transactions that created them. They're not the inputs of any transactions yet, or they wouldn't be unspent. They're potential inputs, if you like, but actual outputs. When they stake they become inputs of the staking transaction.

The rounding down to an integer was related to how the age of an output affected its staking power in an older version of CLAM. I think it used to multiply the value by the age and round down to an integer. I don't think it does that rounding any more, or the multiplication by the age. These days the staking power (called the "weight") is just the same as the value in CLAMs. Each output is considered separately. It doesn't matter if you have lots of 1 CLAMs outputs on a single address, or in lots of different addresses. They each get their own individual chance of staking, with a probability proportional to their own individual value in CLAMs.

There is a benefit to splitting your outputs up into several smaller outputs. Suppose you have 1000 CLAMs. It will stake very quickly, and become 1001 CLAMs. But then it will take 8 hours to mature before it can stake again. The best you could hope for it that it will stake 3 times per day (since that's how many 8 hour maturation periods you can fit into a day).

If instead you split it into 1000 outputs of size 1, each one tries to stake independently. Each one has a 1000 times lower chance of staking than the 1000 CLAM output did, but there are 1000 of them, so it takes roughly the same time for one of them to stake, and turn from 1 CLAM to 2 CLAMs. Then, however, only the 2 CLAM output is frozen for 8 hours while it matures. The other 999 CLAMs continue trying to stake. So you have saved yourself an 8 hour wait for 99.9% of your value.

If you split your value up into *too* many outputs, you'll have too much hashing to do every 16 seconds that you won't be able to get through it all. And if you ever want to spent your outputs, having them split up into millions of tiny pieces makes the transaction which spends them very big (and so very expensive in tx fees).

So there's a tradeoff - split enough, but not too much.

Deb calls it "the clamily".

I don't understand what you're asking, sorry.

The CLAM protocol has a time granularity of 16 seconds. Every 16 seconds it checks each of its unspent outputs to see if it can stake, then sleeps until then next 16-second "tick" of the clock.

If it takes you more than 16 seconds to check all your unspent outputs then you'll be missing out on staking opportunities, because you'll be falling further and further behind. JD is able to do all its staking work in 4 seconds and have a 12 second snooze before the next opportunity comes up.

I don't understand the bit about "missing 3 variations of hashes". There's only one hash per output per 16 seconds.

Now if JD was able to check all of its outputs in 0.001 seconds then it would probably have a lower orphan rate, since it is kind of a race. Maybe that's what you're referring to?

Is there some other place for Mycelium support? It's awfully quiet here for such a serious trouble. Where are the updates?

I don't think that can be the problem (ie. I don't think it's an issue with the block explorers), because when I rebooted my tablet the unconfirmed transaction vanished. As if it had never happened. And I was able to successfully double-spend it using bitcoind. If the transaction was broadcast successfully surely it wouldn't vanish from Mycelium's transaction list would it?