It's like scrypt.cc claims to be one of the biggest breweries in the world. Give them a glass of beer and they will use it to buy brewing equipment and you can get a slow trickle of free beer for ever more.

But it reality they just take the glass you give them and add it to the tank. They aren't brewing any beer, they're just trickling your own beer back to you. You can tell when people are brewing. It stinks. And scrypt.cc smells more like horse shit than like hops.

Some people started early and have already got back more than they put in. They say "this isn't a scam - look, I'm still drinking!"

But where is this "free beer" coming from? It comes from the suckers who bought in recently. They're never getting RoB (return on beer).

To make it worse, the owner of the fake brewery is also drinking from the tank even though he didn't put any beer into it.

OK, so let me check that I have it right:

You have 1 CLAM and want to get to 1000 CLAMs.

You can either do:

a) 1 * 1 CLAM bet at 1,000x or
b) 10 * 0.1 CLAM bet at 10,000x
c) 100 * 0.01 CLAM bet at 100,000x

If (a) wins, you end up with 1000 CLAMs. That happens with probability 0.00099

If any of (b) win, you end up with at least 1000 CLAMs. Maybe 2 or more win. You win at least once with probability 0.000989559.

If any of (c) win, you also end up with at least 1000 CLAMs. You win at least once with probability 0.000989515

So the probability of losing the whole CLAM goes up a little as you make more, smaller bets. But that is balanced by an increased chance of winning more than once.

Your expectation is the same in all 3 cases. You're risking 1 CLAM and so expect to lose 0.01 CLAMs (1%).

Here's the math for a, b, and c respectively:

>>> 1 - (1 - 0.99/1000) ** 1
0.00099

>>> 1 - (1 - 0.99/10000) ** 10
0.000989559

>>> 1 - (1 - 0.99/100000) ** 100
0.000989515

What if the QT isn't running when the orphan block is staked and orphaned? Does it still show the orphan? I think it needs to 'see it happening' in real time for it to show up.

Maybe if you copy the wallet where it happened to the machine where you run QT, then QT will show the orphan. But I'm not sure.

Then they take what you've stolen and give the rest back to you? Or what's your point?

I think your post here ages you. Since ANSI first published the C specification, writing two strings next to each other concatenates them, and so this is legal:


I think it only looks weird to someone who learned K&R C, pre-ANSI C.

PRIszu is conditionally #defined to %lu or some such, depending on which compiler is being used. I think the issue here is that it is #defined to the wrong formatting string - like "%lu" is being interpreted as "%l" + "u".

strprintf is also #defined, in tinyformat.h, and returns a new string object:


Are you thinking of the standard library stdio.h function sprintf()?

There are only a certain number of LTC mined each day. The more people who get involved, the less LTC each of them is able to mine. It's a case of deminishing returns and so it makes little sense to have "reflinks" for real mining operations.

When you see people being rewarded for recruiting new people to "invest" in a "mining" operation, it's likely a Ponzi, not a real mining operation.

To put it simply: suppose you have 50% of the LTC hash rate. You earn 50% of the LTC that are mined. Now suppose you recruit a bunch more people and you double your hash rate as a result. Do you now have 100% of the hash rate? No, you don't. You have only 66% of it. The original 50% is now only 33% of the total, and the new recruits are also only 33%. By recruiting more people your own profit has dropped.


Thanks. But can I take a rain check?

This rings a bell with me for some reason. I think I've seen issues with Windows adding a 'u' to numbers before somewhere, but I really don't remember where.

This is the commit which added the 'u':


The relevant code change is this:


I'm guessing the Windows compiler isn't interpreting the %"PRIszu" in the same way as other compilers.

http://stackoverflow.com/questions/29154364/how-to-use-symbols-in-a-string may be relevant.

https://www.reddit.com/r/blackcoin/comments/2vgzum/rpc_for_blackcoind_in_windows_7/coj3z77 is about the same problem in blackcoin.

bitcoin/src/rpcprotocol.cpp simply has:

            "Content-Length: %u\r\n"

so maybe that's the best fix.

I opened a github issue about this: https://github.com/nochowderforyou/clams/issues/202

It didn't take too long to get difficulty back to normal:

Hi. I answered this question yesterday.

tl;dr: chunks of 5 or 10 is small enough.

Betting once has a much higher variance, but a lower expectation. Note that both strategies have negative expectation and so as a player you want high variance. If the variance was zero, you would always lose what you expect to lose. It's only variance that lets players profit from a -EV game.


OK, so you're asking whether it's safer to make a single bet of 1000 at 49.5% to profit by 1000, or to make 1000 bets of 1, each aiming to make 1000 profit? Or is each bet aiming to make 2000 profit? (1000 to keep as profit, and 1000 to cover the 1000 stakes)?

Note that if you bet 1 CLAM 1000 times, each one aiming to make a profit of 1000, and only 1 on them wins, your net profit is only 1 CLAM, since one bet profited by 1000 but the other 999 all lose 1 CLAM each. If that's the case, then the 1000 bets is more likely to be successful, because you're aiming to profit by 1 overall, whereas the single large bet is aiming to profit by 1000.

When you type "/offsite max", it sets your offsite amount to 99 times the value of your current onsite amount. And leaves it there. Your onsite amount will grow and shrink 100 times faster now and your offsite amount stays the same.

If the site has a run of bad luck, your onsite amount will decrease and so your offsite amount (which remains fixed) will be more than 99 times your onsite amount. There's no way of requesting such a state - it only happens if the site loses.

When you set it to 0 and then back to 'max', you're setting it to 99 times your *new* onsite amount, which is different than it was before.

I saw your post last night and decided to experiment with the two versions of the client to see what happened. I'm sure I've seen orphaned blocks in the QT client but never in the headless one. I loaded up a wallet from a headless client into the QT client, and saw that it didn't show the orphans. I figure the orphans only show if they happen *while the QT client is running*.

The QT wallet is really laggy for me. It spends almost all its time updating the confirmation count in the thousands of rows of the transaction table and almost no time listening to me. So I typed "clamd stop" to stop it. Unfortunately I was logged in to the Just-Dice staking wallet at the time, so it stopped JD's staking and not the QT client. 8 hours later I realised my mistake.

I guess anyone solo-staking had a great night!

http://www.presstab.pw/phpexplorer/CLAM/ has charts of network difficulty:






They both use the same copy of wallet.dat, but I guess the QT client has some kind of additional storage. I never really understood the QT client. We should really get to the bottom of this. I often switch between wallets by shutting down the client and moving wallet.dat files around. If the QT has its own separate storage, do I need to be moving that too? Or does it have a section of wallet.dat that only it knows about?

I don't know if the headless client keeps track of the blocks it staked that were later orphaned.

Here's what I see in the logfile when a block I staked is orphaned:


That "stake -1 for [me]" is me losing 1 CLAM of staking reward, and someone else getting it instead. But the block doesn't show up in 'listtransactions' at all that I can see. I don't think those lines are even logged if you aren't tracking amounts staked (which is turned on when you run 'getstakedbyaddress' the first time).

Dabs got back to me. He's still running his child-feeding thing:


so I sent him the 75 CLAMs.

OK, cool.

I just sent 75 CLAMs, 50 donated by a guy I caught scamming on Just-Dice, and 25 from Just-Dice.

I'm betting at 1%, and setting the stake such that if we win, we get a balance of 2k.

When we win a 1% bet, the payout is 99x, so the profit is 98x, so if our balance is B, we need to calculate the stake S such that the profit, 98S is makes our balance go to 2000, ie. profit is 2000-B.

98S = 2000-B
S = (2000-B)/98

So when balance is 1000, stake is (2000-1000)/98 = 10.204081633
When balance is 989.79591836, stake is (2000 - 989.79591836) / 98 = 10.30820491
and so on.

I listed all the stake sizes in my previous post.

I tried that, but it seems to only want to generate the addresses of the first HD wallet I ever created. I've since deleted that one.

On the Mycelium tab, 'BIP32 Derivation Path' seems hardcoded to m/44'/0'/0'/0

I figure I need to change one of those 0's to a bigger number to get the addresses for the wallet I'm currently using. I didn't realise I could use the BIP44 tab to edit those numbers individually, so got lost making a fork of the page where you can edit the derivation path on the mycelium tab. But all I needed to go was use the BIP44 tab and change the 'account' from 0 to 1 to see my receiving addresses.

I found that if I used m/44'/0'/1' as the derivation path then the displayed "BIP32 Extended Key" and "BIP32 Extended Key (addresses only)" in the mycelium tab of the bip39 web page match the keys I see in mycelium when I export my wallet. But the addresses it generates with that derivation path aren't right. In order to get the correct address list I have to use m/44'/0'/1'/0 as the derivation path (ie. with the /0 on the end).

My wallet contains 49 private keys according to the accounts tab of mycelium, but only addresses 0 through 17 have been used. I guess the other 31 must be change addresses.

I tried m/44'/0'/1'/1 as a derivation path and saw a list of my change addresses. 0 through 29 have been used. So that's 30 change addresses and 18 receiving addresses that have been used, and I guess one extra receiving address has been displayed but not used, making the displayed total of 49.

I sent some coins to the first receiving address in the list, hit the 2-arrows-in-a-circle icon, and the deposit showed up. So it does look back through at least 17 old receiving addresses.

I implemented the ability to 2FA-lock your seeds a long time ago when someone asked for it because they were worried they would accidentally hit the keyboard shortcut for 'randomize' and lose their seed. I copied the functionality from the 2FA-lock on gambling - if the lock is on you can't gamble. If you want to gamble, remove the 2FA-lock. I think the people who are worried about accidentally changing their seed will be changing it rarely enough that editing their 2FA settings to do so isn't a big deal.


Your question could use some tightening up. Are you looking for a certain net profit when you say "certain amount to win"? So if I start with 1000 CLAMs and want to get it to 2000 CLAMs, say. If I bet all in at 49.5% I have a 49.5% chance of profiting by 1000 CLAMs. That case is clear.

But what if I make a bunch of bets at 1% chance, aiming to reach 2000 CLAMs. Is that what you're saying? My first bet would be around 10.204 CLAMs at 1% to make a profit of 1000 CLAMs. But if it lost, my 2nd bet would need to be a little bigger, since now I need to recover the 10.204 CLAMs I just lost, as well as win an extra 1000 CLAMs. So the 2nd bet would need to be around 10.308 CLAMs, then 10.413 CLAMs, and so on. The amount rises exponentially.

I believe you have a better expectation doing the 1% bets than the all-in 49.5% bet. Because your expected total stake is less than in the 49.5% case, and so your expected loss is correspondingly less.

It turns out you can afford to bet 68 times at 1% and get to 2000 CLAMs if any of them win. If none of them win, you have 5.56408786 left over, and give up trying.

Each of the 68 tries has a 0.99 probability of failure.
You lose all 68 bets with a probability of 0.99^68 = 0.504885888
You win, and reach your goal with probability 0.495114111

So amazingly, your probability of success is greater than with the single all-in bet (which is 0.495) AND even when you fail you have 5.5 CLAMs left over!

In the single-bet case, your expected profit is -1% of 1000, or -10 CLAMs. That's hopefully clear. We can calculate it by summing the product of probabilities and profits:

>>> 0.495 * 1000 + 0.505 * -1000
-10.0

In the 68 bets at 1% case, your expected profit is [p(loss) * profit_on_loss + p(win) * profit_on_win]:

>>> (0.99 ** 68) * (5.56408786 - 1000) + (1 - 0.99 ** 68) * 1000
-6.96254812965384

So it is considerably better. You expect to lose only 6.96 CLAM instead of 10.00 CLAM.

Here are the 68 bets we can afford to make:


I also wrote a simulation to sanity check the math:


I left it running for a while for the numbers to settle down:


That's pretty close to the -6.96 the math predicted.

Edit1: I left it running, but it doesn't appear to be converging on 6.96. So:

a) the math is wrong or
b) the simulation is wrong or
c) I didn't wait long enough yet

Edit2: Probably it's (c).

Well, if you were getting 5% orphans before JD and 11% after, maybe JD has doubled your orphan rate. Even before JD the staking will have been dominated by a few large wallets I guess. I'm thinking there wouldn't have been any with >50% of the stake weight, but there still will have been some big ones.


Shortly after the hard fork everyone was on their own version of the chain. It was so easy to stake for the first hour after the fork that everyone was staking every few minutes.


The CLAM client seems to truncate its logfile sometimes, so I don't have much history. Here's what I do have:


Those are the orphans the staking wallet saw in the last day and a half. Note that JD stakes two wallets - a 'staking wallet' (...CLAMZsZg...) with the majority of the coins in it, and a hot wallet (...CLAMZtRD...) with 20k to 30k in it. To further confuse matter I think the first few lines above were while a DDoS attack was ongoing and I ran the staking wallet on two machines at the same time so it was orphaning its own blocks.


CLAM blocks are mostly tiny and so quick to broadcast. I don't know if there's much to be gained by sending your blocks to JD first, but maybe it would help.


The only reason to split your outputs up into smaller pieces is to reduce the effect of the 8 hour delay after staking. Suppose you're happy with the 8 hour delay being 1% of the time your coins are staking, so you only lose 1% to the delay. That means you would want the expected staking time for your outputs to be 800 hours each. The total network staking weight is currently around 700k, and the total network stakes 60 blocks per hour:

So we can calculate the size an output needs to be to have an expected time to stake of 800 hours. Then it will spend just 1% of its time maturing:

>>> weight = 700e3
>>> loss = 0.01
>>> delay = 8
>>> weight * loss / delay / 60
14.58333

There it is. You need to split your balance into pieces of size 14.6 CLAMs if you're happy to accept a 1% loss due to maturation delays.

>>> loss = 0.05
>>> weight * loss / delay / 60
72.91666

If you're happy to lose 5% to maturation delays, you can get away with staking with bigger outputs (size 73 CLAMs each). And so on.

To check my math I looked at the JD staking wallet.

It has 562819 CLAMs split into 32351 outputs very roughly the same size. The average output size is 17.397 CLAMs.

Currently, of the 562819 CLAM balance, 554969 is mature and 7850 is waiting to mature. So that's 1.39% of the balance that is currently waiting.

>>> loss = 0.0139
>>> weight * loss / delay / 60
20.270833

According to my calculations I would expect a 1.39% loss like that with outputs of size 20, so I'm doing a little worse than predicted. That probably means my guess for the total network staking weight was a bit wrong. If I change my guess to 600k it fits much better:

>>> weight = 600e3
>>> weight * loss / delay / 60
17.375

But can that be right? JD is staking 590k on its own.

Checking the rich list shows that other than JD there aren't many big addresses, and other than bitdice's 7k most of the other big addresses aren't staking (presumably being in poloniex's wallet, which we know doesn't stake).

It's look like maybe JD is much closer to 100% of the network staking weight than I previously thought, and the JD staking wallet's biggest competitor is the JD hot wallet...

I heard nothing from him yet. I'll try PMing him: