I sent 0.0001 BTC too little to my pre-order address.

I see:


as my transaction confirms.

There's no txid shown.

Does the missing 0.0001 BTC matter? How can I fix it?

That looks unprofessional.

I think you misunderstood.

I never agreed to play Road's game, and didn't back out.

I also didn't accuse Dean of anything.

I said Road's game wasn't provably fair since it was open to collusion. I didn't say Dean would collude, I said he could.

Someone (you?) said he would be unlikely to ruin his reputation over a small amount like 20 BTC. In response I said that he had already risked his reputation by refusing to pay out a similar amount to sjess so I wouldn't be so sure.

I don't have logs of the chat - this is from memory. Sorry for any confusion.

I know a lot of players will withdraw them redeposit again, but that's all part of making them feel secure.

When I hit 'withdraw' on a site and have to wait more than a minute to see the transaction hit my wallet, it's always a little unnerving. Even on well established sites like Seals With Clubs there's still a concern "what if they miss my withdrawal?"

Having it instant just feels better for the player, and I'm sure makes them more likely to return.


In unrelated news, sorry for being so indecisive last night about the 90% dice-off with Road.

If I was Dean I would consider adding multi-round multi-player games like that.


For those who weren't there, I saw the max profit was 3 BTC now, and said I was tempted to bet 30 BTC at 90%.

Road2Wealth was there and challenged me to a game, as follows:

We both deposit 10 BTC with a trusted escrow (in this case I was the escrow, but in general the site could be) then take turns betting 10 BTC at 90%. The first one to lose his bet gets his loss covered by the escrowed coins, and gets his own deposit back too. We also came up with a rule that if we each won our first 10 rolls, we would stop and take the profits.

I ended up backing out, but the idea seems interesting if it could be made provably fair (ie. remove the possibility for the site owner to collude with one of the players against the other). Maybe provable fairness isn't even an issue - investors already accept the possibility of the site owner colluding with a player against the investors, so maybe it doesn't even matter.

Right after posting that I went out for the day and left my laptop staking. But I forgot to plug it in, so it quickly went to sleep and stopped staking. So I guess things were slower still for a while.

I noticed that.

Last I checked we were averaging 1 block per 3.5 minutes.

We're stuck on the minimum difficulty.

I guess we need to reduce the minimum difficulty to allow more frequent staking with reduced network weight.

I wonder if the weight dropped because someone is withholding non-lotto blocks.

Maybe the lotto payout structure needs to be analysed to ensure that it isn't game-able.

Or maybe half the network weight went offline because it's held by a single player who has technical trouble.

I posted some stats about that here.

True, but only once per output.

If you "dig" for clams now and find that you have one 4.6 pile, that 4.6 pile is around 3 months old and will have an expected time-to-stake of about 1 hour. Once it has staked, however, it is immature, just like any other recently staked coin.

It seems a little unfair to me that early adopters (before the lotto came into effect) "wasted" our mature initial distribution coin age getting tiny (0.0001) stakes and killing the age in the process. New adopters dig up mature coins and get a free lotto entry almost immediately.

I think that's exactly right.

You need to split your stacks up so that none of them is likely to stake within the first 510 blocks.

At minimum difficulty, and 3.5 minutes per block (like we're currently seeing) that means:

>>> 2**20 / (510 * 3.5 * 60)
9.79062558356676

a pile of 10 CLAMS expects to stake at around 510 blocks.

So keep your piles around half that size, or about 5 CLAMS each. By an amazing coincidence that's roughly how big everyone's piles started!

My math may well be wrong here - please check it for me...

Good point.


I don't see why.  If the pool has 40% of the weight, it should get 40% of the blocks, and so 40% of the lotto wins. It's linear.

If the pool modifies the code to withhold min-reward blocks, that gives pool members and advantage, but non-pool members can make the same modification and level the playing field without joining the pool.

I don't see the "no choice" argument.

If the pool gets 51% of the weight then they own the network, but that's the same with PoW pools as well.

Let me clear that up for you:

Every deposit lower than 0.01 will probably be lost.
Every deposit over 0.005 will probably be lost.

Really we're just talking about a web wallet I suppose.

Each user could have an option "share stakes" which lets them decide whether they're pooling their stakes or working alone. One consideration here is that I think it is possible to look a short distance into the future and see whether your coin is going to stake soon. I don't fully understand how it works, but I think the staking algorithm depends on a "stake modifier" which changes every 10 or so minutes based on recent block hashes - so we can't look very far ahead since we don't know future block hashes.

We would need to prevent people from checking "share" only when they're not about to "win"...

I like the idea.

Unfortunately I don't think there's any way to make it zero-trust. You'll have to trust the person with your coins.

I don't see why you would have to have everyone contribute the same amount. Just keep track of how much each person has in their balance, and split all stakes in proportion to their balance. If you have 2 CLAM and I have 18, I get 90% of all stakes (lotto or otherwise) and you get 10%.

It would be worth limiting withdrawals I guess, because coins stake better when they're old, and servicing withdrawals kills their age.

The protocol allows you to stake a coin 4 hours after it was last transferred, but the wallet software won't try staking it until it has 510 confirmations.

I expect this is a bug, and have reported it as such:

https://github.com/nochowderforyou/clams/issues/13

It doesn't matter either way.

The account has a history of promoting scams, and there's no way to prove it has since changed hands. Even if it has, removing negative trust from accounts when they change hands only increases the potential value of scam accounts. If potential purchasers know in advance that the "red mark" is permanent then they'll be less likely to buy the account, resulting in less coin for the scammer.

That's good, right?

He's been harassing me too:



Idiot scammer thinks I'm going to waste time removing negative trust after they've promoted an obvious Ponzi, then gets mad when I don't respond to his mass-PM'ed spam? Tsk.

I've had a buy order at 0.001 for about a week now, but it hasn't been hit at all. The price was just a fraction over 0.001 when I placed it, and now it's around 0.003.

I'm not very experienced with exchange markets. Could my large buy order (I have a series of smaller buy 'steps' now) be driving the upward price movement even though I'm not actually buying anything?

I don't think so. Each half would take twice as long to stake on average.

I just checked, and it appears that no change is necessary.

My function works for DOGE and LTC addresses without modification.

>>> print btc2clam('DT4ZXv7ByoGbrkE6umxLpVesy5BUWmRqxw')
xWE6tY11x6rMN89NXfbShun4K3kQXVj7C8

Some people just can't help themselves.

kingofsports (on coinroll) and LiKaShing (on JD) are two examples that spring to mined of people who won big, tried to withdraw, couldn't because the hot wallet had insufficient coins, and ended up losing their winnings as a result.