whats killing our numbers today? high hash or what. the larger the pool grows the lower our numbers get.
Variance? The stats day _JUST_ started. (Daily stats are based on midnight to midnight GMT, not between payouts). |
|
|
|
Had anyone had issues in driver crashes with this video card?
When clocking them too high or letting them get too hot, yes. Have issues even on stock... Right away, or after running for a while? What are your temps like before the crash? |
|
|
|
Had anyone had issues in driver crashes with this video card?
When clocking them too high or letting them get too hot, yes. |
|
|
|
Uniphase21: what whale? I don't see anybody standing out with huge hashing power right now, and wafflepool is over 16GH...
The sorting is off in the stats, it might be there, but I'm totally not digging through all of it to find. But we have not seen 7 or so GH/s drop in the hashrate, so the whale must be somewhere inside. You're right... http://wafflepool.com/miner/14t8yB3PDGfZT3VppxMY4J9xiBaXUcZvKpHe's still hashing, and at about 8GH/s now (half the pool)... @PoolWaffle: is there a reason you have chosen to hide sfire from the miners page? I'm doing my best to not treat him/(them?) any differently. Yet, 7a8678b8 definitely isn't showing on the miners page anymore... Overall, I couldn't care less about this whale - big hashing power like this causes way less server load then tons of little miners. And I suppose I understand why you might hide him from the miner's page (to stop questions), but it still smells off when you seem to have been very upfront about the pool's operations until now. |
|
|
|
|
Uniphase21: what whale? I don't see anybody standing out with huge hashing power right now, and wafflepool is over 16GH...
PoolWaffle has also said he plans to re-introduce lower difficulty coins (I believe this is still planned), but it's several days off as it requires a significant re-work of the profitability switching system.
|
|
|
|
been mining for about the last 19 hours... worker address 13f6VAKbtd83T9V269iTJ5S6iUePxYUAbL_single... coin values on miner lookup show 0.00000000 but the hash rate is going to town at around about 890khs. Something appears not quite right.
That does look extremely weird... maybe try without the worker name? PoolWaffle: probably need to look at this. |
|
|
|
--expiry|-E <arg> Upper bound on how many seconds after getting work we consider a share from it stale (default: 120) --scan-time|-s <arg> Upper bound on time spent scanning current work, in seconds (default: 60) --queue|-Q <arg> Minimum number of work items to have queued (0 - 10) (default: 1) What atp1916 suggested works best for R9 290, other cards might require different values. It has much more to do with the coin you are mining, not what cards you have. 10, 5, 0 are good values for a multi-pool. You can go down to 2, 1, 0, but there isn't likely to be much change. (some people use 1, 1, 0, but I find this results in too much work expiring). Queue 0 is the most important. Expiry is fairly irrelevant. |
|
|
|
nuts. I think wafflepool is the only pool where I have actually found blocks with, and it was more than 1!
Ya... I had over 600 blocks when they got cleared the first time =(. Was a cool record to see. |
|
|
|
I noticed my stats for blocks found seems to have cleared. Not like it matters, but I was wondering if wafflepool reset this stat at some point?
Ya, it's been cleared more then once (unfortunately). |
|
|
|
by the way, 1500 memclock I've already tried and it made the screen flicker a lot, is something wrong with my card?
1500 is high for this memory and can cause artifacts... but because of the way timings are setup in the default BIOS, only 1250 or 1500 memclock will yield good performance. You can try The STILT's 290 BIOS (works on most Tri-X cards) which changes the mem timings so that 1375-1450 will yield the same or better performance then 1500, but I would get your cards stable before flashing to his BIOS. Basically tho, 1300 will be worse then 1250 on the stock BIOS, possible a lot worse. I am using The Stilt's BIOS on my Tri-x cards, and am getting over 980KH/s on the best card (1400 mem 1100 engine), and over 920KH/s (1375 mem 1020 engine) on the worst card. |
|
|
|
|
Looking for a bit of feedback on this idea - I am interested to see how the community thinks this will work.
Right now, all the "random" block reward coins (Doge, Lotto, Moon, Leaf, Lucky, etc etc) use a pseudo-random generator with a known seed in the GetBlockValue function (see main.cpp in any altcoin) to determine the block reward. This means that the block reward, by design, is predictable before the block is discovered. This has, of course, led to many multi-pools such as WafflePool and MiddleCoin mining only the valuable blocks (which leaves the dedicated miners with on average less then the average block reward in profits).
The protocol change I propose:
- The first tx in each block remains for the miner of that block, but rewards a tiny amount, say 1 coin
- A second standard tx is added to each block (after the genesis block) that pays a pseudo-random reward (say, similar to Doge's payout scheme) to the first txout of the previous block.
By delaying the miner reward by 1 block, this allows the reward to be unpredictable until the block is actually discovered - so you don't know how much you will get paid for a block until you have already mined it.
What do you think the ramifications of this would be? Did multi-pools contribute to Doge's success, or do they detract from it? Are unpredictable block rewards actually desirable?
--
I am also experimenting with varied difficulty based on nTime gap - aka, the difficulty decreases the longer it has been since the last block. I consider this an interesting proposition, and a way to actually make use of multi-pools and coin hoppers in a much more beneficial way (they hop on when a block hasn't been discovered until after the block target time), therefore significantly decreasing time variance between block discoveries (and therefore transaction confirmations). This is more complicated however, as significant variance is currently acceptable for nTime, and so time syncing would need to be built into the network propagation, and nTime variance significantly decreased.
|
|
|
|
GPU clock 1040, memory clock 1300
Either use 1500 or 1250 memclock. Start from 1000 GPU clock and go up from there. Also, what are your temperatures like? Hot? |
|
|
|
@phzi it appears that it does use a random assigned int to discern the payout..
No it doesn't ... GenerateMTRandom isn't random... it's a pseudo-random function that when fed the same seed will always produce the same result. |
|
|
|
Perhaps we could just delay the payout for two blocks? and use a computed random but verifiable value from from previous blocks?
phzi aside from what cant be done do you have any suggestions that would be easy to implement that would work?
Easy to implement? No... Delaying the block reward is a lot more complicated then it sounds, and requires some serious modifications to the core code and protocol. Something like that is more likely to be developed for a new coin, if it ever is. (I have been considering doing this myself for a while... but as tf2 said, I have a day job that keeps me quite occupied). |
|
|
|
Aww... I was so excited that I had an idea, I forgot to read everyone else's suggestions. Also, I'm not good at reading C++ and I don't know enough about the existing CGA code to know exactly what the hell you're talking about, so can you tell me if your code is determining the reward before or after the block is hashed? Sorry if that's a stupid question, but that's the only possible problem I can see right now-- if the reward outcome of block 2 is based on the hash of block 1, it's just as easy to predict whether block 2 will pay out as it was before.
Because of how bitcoin (and all altcoins based on it so far) are designed, you MUST know the block reward BEFORE the block is hashed. Every variable reward coin so far is predictable (you know the reward before the block is found). |
|
|
|
Perhaps taking from lucky coin ?? uint256 prevHash = 0;
if(pindex->pprev)
{
prevHash = pindex->pprev->GetBlockHash();
}
int64 static GetBlockValue(int nHeight, int64 nFees, uint256 prevHash)
{
int64 nSubsidy = 1 * COIN;
//check value out
if(nHeight < XXX)
{
std::string cseed_str = prevHash.ToString().substr(8,7);
const char* cseed = rand(networkhashps) % (diff - rand(diff);
long seed = hex2long(cseed);
int rand = generateMTRandom(rand(networkhashps) % (diff - rand(diff), 100000);
if(rand > xxx && rand < blockHeight)
nSubsidy = 1 * COIN;
}
wouldnt that be a proof-able solution? I might be missing the GetBlockValue's overall function but from my understanding its only called in 2 or 3 places.. Does luckycoin actually do this? I don't see how you can possibly use a rand function in GetBlockValue... it would essentially make block rewards unverifiable at up to the miner to choose (and the miner would obviously always choose to pay himself the largest possible value). My glance at the luckycoin source doesn't show any randomness as part of the GetBlockValue function. Simply put, GetBlockValue MUST return a verifiable and repeatable value, or else you are breaking the entire system. However, surely every block has to be mined? You can't just say "oh, block 21,234 has no reward, I'll skip that one and mine block 21,235 instead" Don't you have to wait for block 21,234 to be mined, before you can move onto the next one?
Yes... this is exactly what smart multi-pools like MC or WP do - mine only the valuable blocks. And is what they would likely do to this coin if it got big enough. For most variable rate coins this doesn't matter too much - Doge, Lotto, Leaf, Karma, Kitteh, etc etc - because the "non-valuable" blocks still offer a reward and are worth mining. Moving to another hash alorithm is not advisable in my opinion because: - Scrypt is pretty ASCI resistent, even if there are scrypt ASICs now, they are not comparable to GPUs because of their very low resell value. Scrypt ASICs are not faster than GPUs.
- Changing the hash algorithm would require a hard fork or a relaunch of a coin. Relaunch would kill every confidence in the creators, changing the algorithm will result in people jumping off because mining would be more difficult (e. g. scrypt-n-factor).
Moving to another algorithm has nothing to do with ASIC resistance. It has to do with multi-pools and other large scrypt pools and their ability to attack the coin. Switching to a less used algorithm negates the risk that multi-pools pose should the coin grow much larger. Essentially, because of this coin's current design, a "51%" re-org attack (which would only require about 30% of the network hashrate due to the use of KGW) at diff>3 would allow an attacker to make EVERY block an anomaly. Or, even worse, would allow someone to say mine 2 blocks (one of which would always be an anomaly), cause the next block to not be an anomaly, and then resume the attack when the next block will be an anomaly (basically the blockchain would look fairly normal, but only the attack would get paid and everyone else would get nothing but 0s). And as an aside, you're crazy if you don't think scrypt ASICs are going to have a huge impact on GPU mining this year... if Alpha-T manages to deliver, you can expect scrypt network hashrates to basically double. And that's only one company. |
|
|
|
double remain = fmod(block, diff) + rnd(networkhashps)
??
edit :
srand(nTime(block));
double remain = fmod(block, (rand(networkhashps) % (diff - rand(diff)) + 1)
This seems interesting... please expand because I don't quite follow. I see you randomizing the difficulty, network hash rate and nTime (which may be a bit over kill) to get a new remainder. Its not tested, but in theory, you randomize a value from the nethash, rand(diff) or rand(networkhash). There would be no way to just run the cmd fmod(block, diff) to calculate if it would be an anomaly or not - It would be almost impossible to guess. in theory, edit: true something that deviates from what is standard, normal, or expected. It randomness is what make it an anomaly. edit 2: you cant calculate a anomalies - you can only calculate probability This can't work - what would prevent a miner from simply SAYING they got a random number number that causes a remainer resulting in an anomaly? You can't have a truely random function in the getBlockValue function, or else there is no way to determine if the reward listed in a given block is actually valid. This is why the "random" coins like Doge all use a pseudo-random function with a known seed value - the result is reproducible (side effect: predictable). The only way around this that I have envisioned is a massive protocol change where block rewards are granted in the NEXT block to the miner of the previous block. But again, this is a massive protocol change and unlikely to get implemented in any already existent coin. -- Changing the algorithm is a decent solution that prevents large pools and multi-pools from abusing predictable block rewards, and allows KGW to be dropped (KGW, while useful for small coins in smoothing out difficulty, actually enables other attack vectors like time-warp "51%" re-org attacks that require significantly less then 51% of the network hashrate). |
|
|
|
Waffle and team, I want to make a suggestion to you guys.
I think you should implement registrations to control the number of hashing power. The faster you grow the faster you will encounter issues, and the need to expand. Now, if you are willing to continue to keep upgrading your gear and do all the work on software, and manage to do it with no much downtime, more power to you. But, I wouldnt want to see you fall because of technical problems. One of the many reasons MiddleCoin went down the tubes.
I dont think it would inconvenience people to go and register, it takes no time. What it will give you is an ability to regulate traffic and how much youre willing to accept at any moment. Say you want to add 5 more GH, you resume registrations and when a specific number is reached you close it down.
Thoughts?
No... Besides, WafflePool has handled a 10fold increase in hashing power almost overnight quite well... I foresee little problem stemming from future growth. |
|
|
|
3-4 a day.. I wish, I get them hourly. It's irritating.
(slightly OT): RickJamesBTC... you're mining with CM? How's the payouts/MH (by your calculations, not CMs)? I've had great luck with WP for the last few weeks, my trials with CM didn't fair so well. |
|
|
|
|
Well, I'm chatting with the devs about this now. It's definitely not only a flaw that requires 51% attacks - it's a flaw that if fully realized by pools, could cause the network to grind to a complete stop (with nobody mining worthless blocks). It's also something that more then anything, WILL be exploited by multi-pools that already do so for other variable block reward coins, if this coin gets big enough without a patch.
|
|
|
|
|
Show Posts
