I think it works like this:

When you short sell 10k CLAMs, you borrow the 10k CLAMs from a lender and immediately sell them on the market.

Later when you close your position, you buy the (10k plus interest) CLAMs back on the market and repay your loan.

So your trade causes a 10k sell when you open it, and a 10k+ buy when you close it.

It won't appear as a buy order in the market. Your buy will execute as a market order, consuming existing sell orders rather than creating a new buy order.


I'm not sure what you're getting at with "the small purchases". There aren't any small purchases.

If the price goes up high enough that you're getting close to being unable to afford to buy back the CLAMs you sold then you will be margin called, and the BTC you used as collateral plus the BTC you made by selling the borrowed CLAM will be used to buy the CLAM back so you can make the lender whole.

Basically it doesn't work in the Linux version of Flash, and it doesn't work in WINE.

The only way I had any success was installing some kind of Windows inside a virtual machine. And then it's really not running in Linux at all, is it.

I saw that too. After buying 10k CLAMs and not being able to withdraw them, I put them up for lending at 0.5% per day. They were very quickly taken up by people. The rate has since dropped considerably from lenders undercutting each other, so now you're better off staking instead of lending probably.

I got to over 20k before busting. Now I have a balance of zero, and:



How is my profit not a multiple of 1000 when I've only ever funded the account with 1000 satoshi faucet payments?

I guess there's either rounding error or missing semaphore somewhere.

I'm still not seeing any way to edit the client key.

https://fastdice.freshdesk.com/support/solutions/articles/9000002707-provably-fair says:


so how do I specify it?

I'm also wondering what the maximum bet is that you allow, or the maximum profit per bet, however it works. It's hard to think about strategies when I don't know at what point you're going to tell me I can't make that bet.


I multiplied a 1000 satoshi faucet payout by over 15x. Multiplying by 5 isn't all that amazing. I did bust 4 or 5 faucet payouts before doing this:




That's not a good idea. blockchain.info has a long history of getting things wrong and being unavailable. Much better to run your own node so you can be get this important aspect of your operation right.

Finally, the guy who recommend for buying BTC seems to be charging approximately twice the current market price:





I don't know if he buys the BTC back afterwards, but if he has a similar markup there as well then your customers will be losing 75% of their value to this guy and have very little left to lose to you. Maybe reconsider encouraging such massive overcharging and find a more reasonably priced trader to advertise.

It takes an hour or two to calculate who won. You can do it yourself though, following the information on the pevpot site.

He claims to have:


I bought 10k CLAMs at 0.00082, and know of several others who bought similar or large amounts at around the same price.

There's no guarantee that the new buyers won't be selling or that a new digger won't appear. But for now it seems the downward price pressure is on hold.

They appreciate your great feedback and all their great players but won't actually do anything about it.

They had over 200 poker players today, and none of the rest of them complained about the very slow withdrawals yet you have an issue?

What is going on here?

Please create a ticket in the ticket system. Then bump it a few times. Then forget about it.

Thank you. Come again!


Meh, it's OK. They just lost a(nother) customer is all.

This is incorrect. There are better and worse strategies.

Initially I was thinking I would allow Just-Dice users to enter any 8-digit petition-IDs they wanted to, and use those in the CLAMspeech when staking blocks. Each user would get their fair share of chances to stake a block based on their investment size.

Then I figured it would be better if I only allowed 'voting' for petition-IDs which had been correctly registered with a 'create clamour' message.

So I set about making changes to the client to have it track valid petition-IDs.

The place to track them is in the block index, so you don't have to keep re-parsing the CLAMspeech every time you start the client. That means I need to change the block index database format, and so users will need to "clam-qt -reindex" after upgrading.

Except it turns out that -reindex doesn't work, and never has. So I set about fixing that. I have some code which now does make the wallet try to reload the blk0001.dat file when you ask it to -reindex.

Except it turns out that when loading my blk0001.dat file (which I know contains all the valid blocks), it gets stuck. Like this:


This is very likely the same bug that was reported recently - the client is unable to sync the chain over the network without multiple restarts. It is also unable to sync from a local blk0001.dat file if it contains a few orphan blocks with duplicate proofs of stake in them.

So that's where I'm at - bogged down in the reference client's C++ code, trying to figure out how to get it to -reindex properly.

That's OK. I would prefer inflation now over lingering uncertainty.


It's not clear to me how much of the drop in price was due to fear of the digger dumping and how much was due to potential buyers being put off by the talk of a change to the rules. I suspect it's much more the former than the latter, but I know you think the opposite.


True enough. It's impossible to please everyone.


That's an issue with this CLAMour thing. It's possible to buy votes, in the form of CLAMs. You need 500k CLAMs or so to get 50% support for your petition, so maybe for a million dollars you could get your petition some attention.


Yes, "we will see" sums up how I feel about it pretty well.

It makes sense, but I don't have a good answer for you. For some reason, coin control (input selection) was added directly to the GUI and isn't available from the command line, and the count,amount stuff is only available from the command line, not the GUI. So you get one or the other.

Possible workarounds include making a separate wallet and importing only the private keys you want to spend from, or using raw transactions (create|sign|send)rawtransaction to manually select the inputs and outputs (createrawtransaction accepts the same count,amount syntax), but be careful with that, because you need to calculate the 'change' yourself. If the inputs sum to more than the outputs, the difference is considered a transaction fee.

They stay at the same address, yes.

They need to have not been involved in a transaction for 4 hours, and not involved in staking for 500 blocks (or around 8 hours). That's before they will start trying to stake. After that it's just down to luck how long it takes.

Yesterday Creative posted her draft "CLAMour" voting proposal, allowing the community to vote whether they want to change things like the distribution process. The coin didn't die.


CLAM hit a low of 72k then a high of 300k a few hours ago:



The digger now claims to have sold his remaining CLAMs. The price started rising as soon as he said this.


It's a rolling window of 1 week. It's not like a petition has a week to gather support. It lives until it gains 50% (or whatever) support over any 1 week period.


No, on the word "clamour.



    combinelimit=0 in clam.conf

Its default value is 1, which means it will attempt to combine values of less than 1 CLAM together, but nothing bigger than 1.

You can also:

    combineany=1

which means it will consider combining outputs even if they are on different addresses.

For Just-Dice's hot wallet I use:

    combinelimit=25
    combineany=1
    splitsize=13.37

to keep the outputs around 13 to 25 CLAMs in size, and allow cross-address combining.

Edit: oh, and I meant to say... if you want to see an example of a big transaction sending to multiple addresses with {"amount":...,"count":...}, check this one out. That's me splitting all the recent new Just-Dice deposits up for staking.


That certainly has a couple of benefits over decreasing the 4.6 CLAM reward:

1) We don't have to break any promises. "If you owned BTC you may already own CLAM!" stays true. The 4.6 per address that you "may already own!" stays there. We aren't accused of deleting people's property.

2) Technically, it's awkward to implement a reduction in the initial rewards. What if I've dug my address but not spent or staked it yet? I see 4.6 CLAMs in my wallet. One day I update the client and what, my balance drops to 2.3? What if I try spending my 4.6 CLAMs just before the hard fork, but by the time it confirms the fork has happened and my transaction is no longer valid? It's a mess.


It would reduce the price per CLAM, but everyone's CLAM holdings would be growing at the same pace (except for those who aren't staking, of course) so the market cap should stay about the same.

I doubt such a proposal would be successful, even though it's better than trying to reduce the initial reward in my opinion. Rich CLAM holders voting to make themselves richer isn't good from a PR angle...


Yes, that's about it. It's a way of discovering what "we" want. Once we know what we want, implementing it is relatively simple. And since so many of us want it, it shouldn't be hard to find one of us with the necessary skills (or budget) to make it happen.


Yes, or in clam.conf without the hyphen.

I use:

    staketo=xJDCLAMZW9xZEFRfWhxXkcCGYkHAzhsjT5

in clam.conf.

That's the chance of hitting the same numbers twice in a row on a specific pair of days. But it didn't happen twice in a row - there were some draws in between - and it wasn't on some particular special day, it was just some random day.


That's faulty logic. What are the odds of starting a hold'em hand with a pocket pair? It's 1 in 13 that you get the first card you got, and about the same (3 in 51) that you get the same rank for the 2nd card, so it's 1/13 * 3/51 = 1 in 221 that you get a pocket pair? No. Because the first card doesn't matter. Your "AFTER knowning" is saying that you need to take the rarity of seeing that first card into account, but you don't. The odds of starting with a pocket pair is simply 3 in 51 (1 in 17) - because you're always going to get some first card, and there are always going to be 3 cards left out of the remaining 51 cards which have the same rank.


That would be the odds of seeing a particular set of 6 numbers twice in a row. 1,2,3,4,5,6 say. But that's not what happened.

1) the 6 numbers were nothing special
2) it didn't happen twice in a row

I was saying that it would be just as "amazing" if the same numbers came up twice in the same year, and saying that that happens in about 1% of years if you draw every day.

Think about it.

What are the odds that a certain number comes up on a 6-sided dice? It's 1/6, right?

So what are the odds of the same number coming up twice in a row?  "Much less than that"? Why?

I gave an example of how the chance of doubling up can be higher than 49.5% - check the bold number in the quoted text.

It's nothing to do with imperfect calculations, it's a true effect. The strategy I outlined has a chance of doubling up that is closer to 49.6% than it is to 49.5%.

The trick is to risk less on average. If you always bet your whole bankroll on a single event, you expect to lose 1% of it all. If you sometimes double it up without having to bet it all, on average you risk less than all of it, and so expect to lose 1% of less than all of it.

There's a couple of problems with that:

1) you reach the maximum profit per bet too quickly

2) the place I was playing gives you better loyalty rewards if you play at a higher payout multiplier, so I didn't want to play at 2x

I don't want to be seen as endorsing them, in case one day they turn out to be a scam and some QuockSucker tries to make it look as if my mentioning them means that I was somehow in on the scam.

But they have a maximum profit per bet of 1000 mBTC.

I was playing "by feel", mostly, and getting very lucky.

For example: