Topic: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin" - page 466. (Read 1151252 times)

Been awhile since we had a huge lotto block...
A few small ones...  but no biggies...

Also glad the big lotto winners didn't go and just dump the coins too...

That post is pretty poorly written, by someone that seems to have an insufficient understanding of coinage.

It can also be argued that attacking a PoS coin is much more costly then a PoW coin, because (for example) it has been shown that only ~$600 would be needed to attack Dogecoin with their shitty hashrate, whereas to attack a coin like CLAM, you must be a significant stakeholder in CLAMs, are you would be destroying your own investment.  So; the security of a PoS coin goes UP with value increase, whereas PoW security is linked only to network hashrate.

Kinda says it all - "I'm not a programmer, I don't understand this, I might be wrong, but let me now talk like I am an expert...."

This may migrate this attack a little, but still this's magnitudes insecure than PoW.

Projections are almost impossible - as it entirely depends on how much time and thus "percentage" a miner has accrued v. time and "percentage" of other miners.  i.e. Week #1 != Week #2.  Add to that calculations of present price * current hash....

The formula Itself is extremely simple.

percentage = (# of shares * share difficulty * algo-profitability multiplier) / combined total of all other miners

I find it hilarious that there are some very small time miners with small hash rates that have done a great deal of mining at kHashier.com and they consistently get great payouts (proportionally) quite possibly due to simply not knowing enough to be skeptical.  They are having some of the best mining of their career, and quite likely aren't even aware of it

Always up for ideas, of coarse.

Speculative GPU miners I think are a lot more common then speculative scrypt miners. 
And nscrypt profitability has dropped a lot lately, it's just not worth mining compared to X11 or X13.

I mined for a bit with nscrypt when it was worthwhile, but am waiting to point my rigs at khashier until we have some new algos.  And I think you'll see there are others in the same boat as me.

Also, as someone else said, people really like stats.  More stats would probably help the multi-pool more then anything.

Scypt and Scrypt-N is fine... there are tons of ASICs floating around.

But KHashier is a Black Box....
It's impossible to determine ROI even approximately...
So after a few days miners move on to more standard pools.

You've had > 150 miners... and maybe 10% of them stick around.

Provide more stats like # of total clams/day or week projected...
Or the exact formula for determining your Percentage Payout.
 

If you guys are serious about mining; I can bump it up on the list of TODO's.
Take a look at it tonight.

Been trying to delegate and divide up time as efficiently as possible... given the lack of interest in the Multi-Pool, adding an additional algorithm to dilute hash was not a priority (though still planned).

Yup...

x11 and other algos needed on kHashier.
I could help forge the clam shell much better if I were able to mine DRK or other x11 coins.

No Pearl payout here either but there have been days before when there hasn't been any (I'd assumed it was to wait to build up funds to minimise the exchange tx fees). The 21st July for example.

I've noticed another "feature" of staking.... could be a bug or what was happening before could be the bug:

I have 2 separate outputs under 1 address. 1 of 10 CLAMs and another of 6. Up until now the 10 CLAM pile has staked a few times and that amount has been moved from the balance to "Staked" leaving the 6 coin output to spend/stake. I have other piles of coins that seem to always stake before those remaining 6 - so they have never actually staked themselves.

Last night the 10 CLAM pile matured after mining and then it looks like the 6 pile finally staked (all the other piles were already staked and awaiting 510 confirmations), however instead of only 10 CLAMs or 6 CLAMs being moved to "Staked" as a result of the mining - both were.

The question is: When staking should all the outputs of an address be combined (i.e. should I have been staking 16 coins every time from that address)? Is this part of the "fix" that's being referred to?

Also are there any tips on how to get the git version to compile using minGW on Windows 7? I'm guessing that nobody is doing that and instead it's being cross compiled on a Linux platform?

PM me your worker name / CLAMS address and I can take a look for you.

I didn't receive my Pearl Payout today, did anyone else?

Not exactly.  It's been discussed in this thread a bit, but it appears somewhere around 5 CLAM is the ideal amount to have in an address for staking rewards.

This will change with the upcoming hard-fork, however, that should fix the merging and splitting of txouts.

i was thinking the more coins in different address in one wallet will give you more chance to mined the lotto prize?

Indeed.  Nothing fancy like multiple wallets required. 

Coin Control is your best friend for understanding how your coins are stored. Use it; love it.

send them to yourself. Make more addresses with your wallet if you  have to

The point at which you have enough coin piles where-by splitting them to separate wallets (not the same wallet, as mentioned above) and start what is essentially a Proof-Of-Work race...... well, as far as I aware, that shouldn't be a concern.

The piles would be so small, tx fees would mount so quickly, and coin days would accrue so slowly - it would result in the most inefficient waste of CLAMS possible, imho.

You may as well call one of the wallets an "Orphanage"

Won't work.

What would happen if you ran simultaneous versions of exactly the same wallet?
I am NOT doing this but just curious if this would be some sort of cheat....

My guess is you would 'fork' yourself...

Just split them to different addresses in a single wallet and they will stake. Larger piles of coins have a higher weight so I guess there's a balance between # of stacks and the size of each.