**** Total Unpaid is a combination of your confirmed Balance and your fluctuating total pending. This value will rarely be constant.
Nobody is questioning fluctuating balances. What we wonder is where 20% go during payout. Riddle me this: If I offer you $10 (that is 10 USD, not $10 worth of pesos) to wash my windows, how much do you expect to get paid? $10 or $8? If I mine 10 coins of something I expect to see 10 and not 8 coins of that something in my wallet, excluding the pool fee. Now if i DO offer you $10 worth of pesos and I DO mine coin X and get paid in BTC I DO expect the balance to fluctuate a bit. Again, you are holding an estimate, a 'non-static value' (a pending/pre-paid assumption before share paid) as a known integer(your random cash exchange montra above), a static known value. We understand that Share%*98% is what you should theoretically be paid. But again.... Theory. The path of the result is unknown to most. Is the pool getting 2% of all mined blocks, then the rest is divvied up? What order does it happen in? How would the resulting estimate be a different number between those two events? Yes. Some logic will interfere. It inherently does. This is why programmers are highly paid.... because they can understand, and think on these types of levels. But sometimes... people miss details. They stick one calculation before the rest and it work fine in all but one or two instances. These are called bugs. Now if it's a real problem (not meeting 100% in all daily payouts between everything it needs to be), yes. that is serious. But there is no proof of a problem. Just some symptoms with no cause or hysteresis of proof in them. But there's a very real chance, an equal chance or possibly greater that it could just be a display problem via the code.... remember, it's pre-estimating. I keep repeating this. Over and over again. There you go again. There is proof of a problem. It has been proven by many users mining both coins that need to be converted and coins that don't. And no one has demonstrated a correct block or overpaid block. There I go repeating myself again. The only thing that's estimated is the converted value. No conversion, value is real. That's why I'm focussed on mining the same payout coin. If the pool mines a block of a coin with a block reward of one and I get a 10% share of that block I earned 0.1 coins, period. It's not an estimate. It has been shown that the value of a cleared coin matches exactly the percentage share of a block. Yes I have done some speculation and have backed it up with the available data and reasoning. I get frustrated when the same unsupported FUD is spewed repeatedly. I then have to repeat myself to refute the bad analysis to avoid people getting more confused. The problem is now defined as precisely as possible with the data available to users. Any further speculation is based on fantasy not reasoning. We need data! You say there's no proof, I disagree. Regardless the next step is to collect more data. If you think I'm wrong, do your own test. Mine a pool with only one coin to a walltet of the same coin. Monitor the blocks that are found. You will see the amount and estimate are the same and are exactly the correct percentage of the block reward. The value will not fluctuate while the block is maturing because it is the same coin. Then note the cleared value and compare with what was credited to the wallet. If you get the cleared value or anything close to it I'm wrong. |
|
|
|
Just because one person doesn't have the coins exchanged... doesn't mean the pool doesn't calculate the split in exchange costs between all users who have shares on that block.... unless this is a known factor... which I believe it's still unknown.
Speculation has its place but must be reasonable and verified with actual data. 20% exchange cost on every block is not reasonable, not supported by any data so far and incapable of being explained is any plausible way. I assume it's every block because no one has yet demonstrated either a correct block or an overpaid block, but several have demonstrated underpaid blocks. What you suggest is also cheating because exchange to an altcoin doesn't incur exchange fees because it's done internally. There used to be a message stating that only BTC payouts had an exchange fee applied but I can't find that message anymore. |
|
|
|
so basically you will NEVER get paid the whole block.. even if its the only coin you mine..
Instead of repeating yourself try answering this question I asked 2 posts ago. If what you say is true why is it always a large negative difference, and where are the missing coins going?
The pool mined a whole block but only paid out 80% of it.
You're not helping with your off target speculation, particularly because it has already been rejected with data already available to users. We now need data that isn't available to users, not more speculation. |
|
|
|
you would probably make more if you just let it pay you in bitcoin and buy the coins of choice yourself.
I do did get paid in BTC but still got short changed. If what you say is true why is it always a large negative difference, and where are the missing coins going? The pool mined a whole block but only paid out 80% of it. like i said before, looking at the code it doesnt look like this pool cares about blocks.. it only cares about how much bitcoin they are worth.. say you are mining skien and you got a digibyte block.. to this pool this block isnt worth 974.887 DGB its worth 0.00053619 btc.. since it seems to be sent straight to the exchange and cashed out to the hot wallet as soon as its matured. then when it comes time to pay out everyone.. it converts the btc back to dgb, if you tell it to, and sends you that amount, minus exchange fees and tx fees. so by the time you reached your min payout of .005 or sunday which is lower, your dgb block of 974.887 coins might be only be worth 940.523 or whatever. That's a pile of BS. Zpool never buys altcoins at the exchange, never did and I reiterated that in this forum less than a day ago. Your making it up as you go. It has already been proven the value of the block is correct when it is cleared. The data is stored in the DB, Later the data is extracted from the DB. Is the data still correct? How is the balance credit calculated? Is that correct? Is it credited correctly to the user's wallet? Those are the major points of interest. It doesn't matter whether you use debug logs or real time DB queries it's the data that matters, not how you get it. |
|
|
|
you would probably make more if you just let it pay you in bitcoin and buy the coins of choice yourself.
I do did get paid in BTC but still got short changed. If what you say is true why is it always a large negative difference, and where are the missing coins going? The pool mined a whole block but only paid out 80% of it. |
|
|
|
I've yet to see anyone report it's "consistent" and imo it must play a role but the logic looses me . It's been reported between 15-32%?
It's been reproduced and demonstrated on enough algos and coins to conclude it's not isolated. And no one has demonstrated, let alone claimed, it doesn't happen. Anyway the first step in solving a problem is defining it. The definition of this problem is at a wall. Something happens to the amount between the time a block is cleared an when it is credited to the balance. The next step is to find out where and what, then why. A simple control test can be performed mining a pool with one coin with one user and getting paid in the same coin. Then extract all the DB info for it at various times, particularly between clearing and crediting a block. Is that too much to ask? |
|
|
|
Zpool web page says:
"Non-BTC payouts depend on that coin being mined as your BTC balance is traded internally by our system to your currency of choice."
Does that mean that if you mine an algo and reguest payout in a specific coin your coins are first exchanged in BTC and then BTC is converted to the specified coin? Or it applies only to different coins in the same algo?
Good question. The statement says it's done internally but doesn't say whether it's done in 2 stages. Analyzing the code would answer that. But, as Crackfoo said many, many times he's not a coder so it's over his head. That's why I suggested analyzing the logs. That is the job of the admin. It's possible that coins get asigned initially a bigger value when they are placed at the exchange and then, when they are sold the value is adjusted to the real value. Those are random events. Coins go up and coins go down, how could random error cause a consistent 20% downward bias? Also returning to my previous point, it's of no value to speculate about how exchange works unless we know that exchange is done in the baseline case, ie mine one coin and get paid in same coin. |
|
|
|
Zpool web page says:
"Non-BTC payouts depend on that coin being mined as your BTC balance is traded internally by our system to your currency of choice."
Does that mean that if you mine an algo and reguest payout in a specific coin your coins are first exchanged in BTC and then BTC is converted to the specified coin? Or it applies only to different coins in the same algo?
Good question. The statement says it's done internally but doesn't say whether it's done in 2 stages. Analyzing the code would answer that. But, as Crackfoo said many, many times he's not a coder so it's over his head. That's why I suggested analyzing the logs. That is the job of the admin. |
|
|
|
Most of this discussion assumes a mined coin is exchanged for the payout coin. The 20% reduction also occurs when the matured block
is the same currency as payout. In such cases there is no exchange. There's no use adding unnecessary variables to the problem.
I wish you success in finding the problem.
The theory is that the coin is exchanged behind the scenes from X to BTC and back to X for payout. Could very well be but the loss is too great and too consistent for that IMO. Agreed, their could be a double exchange but my point is the problem occurs when no exchange is needed. The single coin case is a better one to analyze as it may bypass all the exchange code. Even if it doesn't bypass the exchange code the single coin case is easier to observe because there is no exchange rate fluctuation to be concerned with. It is also my understanding that zpool does not exchange for altcoins on the open market. All altcoin payouts are done from mined coins. So any non-BTC payout does not require a market exchange. |
|
|
|
it pains my heart to see posts like this.
If you do not even understand the basics of how a GPU fits into a mobo then you have no business trying this mining game.
Do yourself a favor and at least spend 5 seconds reading before you drop 2k to build a mining rig.
I have a similar feeling. First he gets the wrong mobo and it takes him more than 30 days to realize it. Now he wants to go radical and try to use a PCIe splitter. Chances of success = 0. I didn't check the specs of the mobo but I assume it has 2 x16 slots and probably a couple of x1. This is very usable for mining, but more importantly for learning. |
|
|
|
It says it's a new algo, it won't work with old scrypt. It's scrypt-N with N factor=1048576. As a guy suggested in the other thread witch i mention, i set virtual memory at 32GB and now it works. No way to use such amount though... I still have lots of free memory. Did it actually work for him? What miner did he use? ScryptN is not supported in cpuminer-opt. The code is present but untested. If they have a working miner I suggest you try it. I was able to run a benchmark with your command line on Linux with 16 GB mem, however, there is no guarantee it is hashing correctly. Your memory allocation issue may not be related to the miner. |
|
|
|
I am wondering if the sale of coins on an exchange could cause the share of the person to be less in the end because they are also splitting the conversion cost?
Makes sense for that kind of coding mistake to happen because they are trying to make everything an equal split in the end.
I think that totally makes sense why a solo mined coin to payout type can end up being less in the end. The block reward was split after the remainder was to sold on the exchange. Sale fees, etc..... Since value and fees are unknown till sold...
anyone else see my flow of thought?
i am trying to follow the code, but it looks like what i said is right. it uses btc as a constant.. not sure but all coins might get sent to exchange.. not sure if they get sold or not tho.. they get assigned a value and that value ,im assuming after fees, is used to adjust your balance.. so say you were solo mining a coin, you got 5 blocks and it was 50 coins.. they get sent to an exchange when they mature, and you end up with x amount of btc. when payouts come around, they get revalued back to solo coin and you end up with 40. Most of this discussion assumes a mined coin is exchanged for the payout coin. The 20% reduction also occurs when the matured block is the same currency as payout. In such cases there is no exchange. There's no use adding unnecessary variables to the problem. I wish you success in finding the problem. |
|
|
|
i got this error when i try to compile your miner   someone knows this ?? minerd to compile was no porblem but it has no crptonigth algorithm ... kind regards Missing dependencies, consult README.md and ensure all packages are installed. |
|
|
|
It says it's a new algo, it won't work with old scrypt. |
|
|
|
That's a memory allocation error, how much do you have free?
Edit: there is a bug in the error message, the thread id was missing.
About 4.5GB. Restarted windows too. CPU: AMD FX(tm)-8320 Eight-Core Processor
CPU features: SSE2 AES AVX
SW built on Sep 22 2016 with GCC 4.8.3
SW features: SSE2
Algo features: SSE2
Start mining with SSE2
[2016-09-29 02:26:16] Starting Stratum on stratum+tcp://poolinat0r.com:4444
[2016-09-29 02:26:16] Scrypt buffer allocation failed
[2016-09-29 02:26:16] Scrypt buffer allocation failed
[2016-09-29 02:26:16] 8 miner threads started, using 'scrypt' algorithm.
[2016-09-29 02:26:16] Scrypt buffer allocation failed
[2016-09-29 02:26:16] Scrypt buffer allocation failed
[2016-09-29 02:26:16] Scrypt buffer allocation failed
[2016-09-29 02:26:16] FAIL: thread 52623896 failed to initialize
[2016-09-29 02:26:16] The n factor doesn't look right, the default is 6 for scrypt. |
|
|
|
@scryptr. Please also post the -msse2 compile that failed. This isn't a simple matter of telling you
the correct way, we need to figure out the correct way first.
@scryptr The correct commandline for building for your CPU Sempron 145 and Athlon X II is: ./autogen.sh && CFLAGS="-O3 -march=btver1" CXXFLAGS="$CFLAGS -std=gnu++11" ./configure --with-curl && make && strip cpuminer Try that and you will have your binary. Personally I use that on my Phenom's and Sempron 145. This commandline works flawlessly even on older AMD Athlon 64 X2 6000+ and 5000+ A SUCCESSFUL BUILD RESULTED!!! -- The following screen captures are easier to post than a pages-long compile log: https://postimg.org/image/olsjajmyj/Initial launch of CPUMiner-OPT 3.4.8-dev. https://postimg.org/image/3lwnwwy77/First accepts for CPUMiner-OPT 3.4.8-dev while mining CryptoNight at NiceHash.com. Thank you very much for the compile scrypt. I would appreciate a little explanation of the flags used. After spending several hours studying GCC flags for various CPU versions, and attempting to compile with different combinations, your help is a gift. I am also trying to compile NiceHash's version of tsiv's CCminer for CryptoNight. Perhaps their git repository is a bit skewed, tsiv's compiles with just "autogen.sh", "configure", and "make". Thanks again! --scryptr Thanks for posting the results. I am also curious about why certain flags didn't work, and especially why something that compiled crashed with an illegal instruction, and which instruction it crashed on. The compile flags for cpuminer-opt are more complicated because it supports so many algos written by different people to different standards. AMD CPUs, well that's another story. Thanks to th3.r00t for making some sense out of it. |
|
|
|
What with this error: [2016-09-29 00:57:08] Scrypt buffer allocation failed
[2016-09-29 00:57:08] Scrypt buffer allocation failed
[2016-09-29 00:57:08] Scrypt buffer allocation failed
[2016-09-29 00:57:08] Scrypt buffer allocation failed
[2016-09-29 00:57:08] FAIL: thread 46987800 failed to initialize Windows 7 x64 with 8GB RAM. My script: cpuminer-btver1 -a scrypt:1048576 --benchmark That's a memory allocation error, how much do you have free? Edit: I don't know much about scrypt but that nfactor doesn't look right. The default is 6. Edit: there is a bug in the error message, the thread id was missing. |
|
|
|
|
@scryptr. Please also post the -msse2 compile that failed. This isn't a simple matter of telling you
the correct way, we need to figure out the correct way first.
|
|
|
|
THAT TRICK DID NOT WORK-- I tried it earlier. My Sempron rigs likely won't benefit from the optimizations, thay are doing fine on Lyra2re. What bothers me is that tpruvot's CPUMiner-Multi is not working on CryptoNight at NiceHash. --scryptr Could be more than one problem, AMD often doesn't compile with "-march=native", give it a try with "-march=core2". There is some discussion about this with an AMD user several pages back in this thread. He has a good handle on the problems and I've let him take the lead as I don't have any AMD CPUs. The issue with cryptonight at Nicehash is they threw in a twist to the protocol that requires a miner update. TPruvot has been quite busy with ccminer and yiimp so I don't expect a quick fix to cpuminer-multi, especially since those other projects are producing revenue. THE COMPILATION WITH "-MARCH=CORE2"-- The compilation worked, and generated an executable cpuminer. However, the miner errors out with "illegal instruction" when it begins to mine. It will print out its version, and "./cpuminer -h > help.txt" generates a readable help file, but it won't mine. The cpuminer recognizes my CPU as an Athlon X II, links to the pool, and then errors out. What other options do I have for the "-march=" string? I am simply using the "build.sh" file. A Sempron 145, unlocked to an Athlon X II, is not a Core2 Intel chip. Is there a specification for the older Athlon chips? Or, anything else in the "build.sh" that I should alter? Thanks! --scryptr I see no reason for an illegal instruction if you compiled for core2. Please post the miner console session. |
|
|
|
|
Show Posts
