yeah like i said on mintpal there is a pool that does a large volume of selling automatically and wipes out a lot of the buy orders on there. usually around 400000 to 700000 coins.
I think you're right except the multipool is selling only when there's volume to sell and when the volume's not there (ie right now) he is putting up these buy walls to narrow the spread and attract foolish FLT buyers. And yesterday it looks like many of his buy-walls were hit, leaving the multipool with more FLT. It looks like he finally couldn't take on much more FLT and has been selling the past 8 hours when he could. But just recently, volume dried up and so up came the buy walls again from 155 to now 170, totaling close to 800k FLT orders to buy. Pretty much the way to hurt this multipool most is to not sell and not buy. Basically dry up liquidity and make him hold his FLT until he panic sells and crashes the FLT price at which point you then go in and buy the cheap FLT back up to this level or higher with ease. He is casting a heavy weight over FLT right now because he HAS to sell his mined FLT and convert to BTC; he is a multipool and his miners want their BTC and the longer he doesn't convert his FLT the longer his miners have to wait for the remaining FLT->BTC payouts and eventually his miners will be pissed that their payouts aren't as big as they should be. JL edited: typo. 100% accurate. |
|
|
|
Peercoin's rewards based on nBits... int64 GetProofOfWorkReward(unsigned int nBits)
{
CBigNum bnSubsidyLimit = MAX_MINT_PROOF_OF_WORK;
CBigNum bnTarget;
bnTarget.SetCompact(nBits);
CBigNum bnTargetLimit = bnProofOfWorkLimit;
bnTargetLimit.SetCompact(bnTargetLimit.GetCompact());
// ppcoin: subsidy is cut in half every 16x multiply of difficulty
// A reasonably continuous curve is used to avoid shock to market
// (nSubsidyLimit / nSubsidy) ** 4 == bnProofOfWorkLimit / bnTarget
CBigNum bnLowerBound = CENT;
CBigNum bnUpperBound = bnSubsidyLimit;
while (bnLowerBound + CENT <= bnUpperBound)
{
CBigNum bnMidValue = (bnLowerBound + bnUpperBound) / 2;
if (fDebug && GetBoolArg("-printcreation"))
printf("GetProofOfWorkReward() : lower=%"PRI64d" upper=%"PRI64d" mid=%"PRI64d"\n", bnLowerBound.getuint64(), bnUpperBound.getuint64(), bnMidValue.getuint64());
if (bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnTargetLimit > bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnTarget)
bnUpperBound = bnMidValue;
else
bnLowerBound = bnMidValue;
}
int64 nSubsidy = bnUpperBound.getuint64();
nSubsidy = (nSubsidy / CENT) * CENT;
if (fDebug && GetBoolArg("-printcreation"))
printf("GetProofOfWorkReward() : create=%s nBits=0x%08x nSubsidy=%"PRI64d"\n", FormatMoney(nSubsidy).c_str(), nBits, nSubsidy);
return min(nSubsidy, MAX_MINT_PROOF_OF_WORK);
}
|
|
|
|
That negates the point of variable difficulty
Nope... PeerCoin uses the same model |
|
|
|
|
You would left the rewards as they are now, maximum 5K, 2.5K, etc, but adopted a system of adjusting the rewards down/up based on difficulty/hashrate, with the current reward levels being the maximums, possibly it could alleviate some dumping.
Say a multipool wanted to mine because it was profitable at 5000, but then their hashrate hit the coin and the reward dropped to say 4000, the coin may not be as profitable and they would switch to a new coin (maybe)
If you throw 20gH at it, say with ASIC's, maybe the reward will drop to 500 or something, and they would stop mining.
|
|
|
|
Miners are dropping off because the reward has dropped to 5000...
This isn't true at all, the average of the reward should have been 5,000FLT in the first place if the rewards were actually random, so they wouldn't be getting any less coins, therefore the reward hasn't "dropped". This only matters to people specifically targeting profit as if the coin was a static 10,000FLT per block(or gaming the rewards and only targeting blocks greater than 5,000FLT). We didn't want these people in the first place and if the hashrate has dropped because profit targeting multipools are gone, so be it, that is a good thing. multipool miners is what I meant to say. People targeting the big blocks dropped off. Wafflepool is still hitting us, but at least they can't target the big blocks anymore... Those buy orders are getting really thin. wafflepool has another 800k to dump, sub 100sat here we come?  Should fork FLT into a coin that lowers the reward based on difficulty/hashrate |
|
|
|
Miners are dropping off because the reward has dropped to 5000...
why? I think the difference is small from random 1000-10000 and fixed 5000. The difference is bigger for multipools if they only mine blocks with better rewards. Thats what I mean... MP's |
|
|
|
Miners are dropping off because the reward has dropped to 5000...
This isn't true at all, the average of the reward should have been 5,000FLT in the first place if the rewards were actually random, so they wouldn't be getting any less coins, therefore the reward hasn't "dropped". This only matters to people specifically targeting profit as if the coin was a static 10,000FLT per block(or gaming the rewards and only targeting blocks greater than 5,000FLT). We didn't want these people in the first place and if the hashrate has dropped because profit targeting multipools are gone, so be it, that is a good thing. multipool miners is what I meant to say. People targeting the big blocks dropped off. |
|
|
|
|
Miners are dropping off because the reward has dropped to 5000...
|
|
|
|
|
FYI I am not releasing binaries for now on the branch v0.4.6.x - I have built them and am testing. There are some issues with syncing I am seeing. Will release a Mac Wallet in a few days on version 0.4.5.4 (as well as updated windows binaries and linux source)
Note that the Mac Wallet has some compatibility issues with systems < 10.9.x (will not sync), trying to figure out why that is, but worst case I will release a 10.9+ Wallet.
|
|
|
|
|
BTW if blocks are really slow its one of 2 reasons. Miners jumping off - or large pools that have no upgraded stratum-mining (their hashrate is effectively nullified). in this case its hashrate related...
|
|
|
|
|
made me sweat! LOL fork is a success, reward is now 5000
|
|
|
|
Since the PoS blocks are fixed difficulty, do they affect the KGW calculations for PoW? I should look at the code for the interactions, but too lazy....
We don't use KGW. POS doesn't effect POW in any way. |
|
|
|
Not sure why this slipped my mind, but remember: once POS blocks start, the number of total coins decreases. A POS block is a block, and its a block that generates no full POW reward. So if you have 1000 blocks, and 250 are POS, thats 3,750,000 coins generated (plus whatever small number of coins is generates via POS) - not 5,000,000
This is come into play later in the coins life when more blocks are POS
This contributes to the rarity of the coin vs say a scrypt only coin.
Is this true for all PoS coins or just flutters? All |
|
|
|
|
Not sure why this slipped my mind, but remember: once POS blocks start, the number of total coins decreases. A POS block is a block, and its a block that generates no full POW reward. So if you have 1000 blocks, and 250 are POS, thats 3,750,000 coins generated (plus whatever small number of coins is generates via POS) - not 5,000,000
This is come into play later in the coins life when more blocks are POS
This contributes to the rarity of the coin vs say a scrypt only coin.
|
|
|
|
More people should be mining this coin!
Fuck 'em let us keep the coins until it gets popular  lol |
|
|
|
|
All: going forward I will be creating a new development branch with many improvements. I will release binaries as well. They can be used but always make sure you have backups of wallet.dat (especially best to have once from when you first installed the wallet).
So we will have 0.4.5.x and 0.4.6.x - hopefully we will retire 0.4.5.x soon.
When i post the binaries, feel free to use them. Just report any issues.
|
|
|
|
Kidcoin, with the knc scrypt miners coming out in a few months, how much should we worry about the hashrate being lopsided and forking?
not worried, because there isn't much that can be done IMHO. The pools need to really be careful and ban miners with huge hashrates initially. I think I might order one and mine flutter with it. This is a little off topic, but do you have any input on the reliability of knc as a company? They are a good company form what i have heard... |
|
|
|
I just updated the wallet to v0.4.5.3-ga-beta and am receiving the following error:
Invalid checkpoint found! Displayed transactions may not be correct! you may need to upgrade, or notify developers.
Anyone know how to resolve this?
"blocks" : 20547,
"currentblocksize" : 1894,
"currentblocktx" : 3,
"difficulty" : {
"proof-of-work" : 51.24222293,
"proof-of-stake" : 0.00024414,
"search-interval" : 1
},
"blockvalue" : 6847000000,
"netmhashps" : 2683.94721561,
"errors" : "WARNING: Invalid checkpoint found! Displayed transactions may not be correct! You may need to upgrade, or notify developers.",
"pooledtx" : 3,
"stakeweight" : {
"minimum" : 0,
"maximum" : 0,
"combined" : 0
},
"stakeinterest" : 1000000,
"testnet" : false
}
yep, backup your wallet.dat, and delete all other files in %appdata%/fluttercoin/ Make sure you have a conf file named fluttercoin.conf that looks like: rpcuser=username rpcpassword=password connect=54.203.244.170 connect=54.203.244.27 connect=54.199.237.235 maxconnections=3 Start the wallet, download the blockchain, and then change the fluttercoin.conf above to whatever you want it to look like, at the minimum use: rpcuser=username rpcpassword=password dnsseed=1 noirc=1 |
|
|
|
Kidcoin, with the knc scrypt miners coming out in a few months, how much should we worry about the hashrate being lopsided and forking?
not worried, because there isn't much that can be done IMHO. The pools need to really be careful and ban miners with huge hashrates initially. |
|
|
|
|
Show Posts
