There is a chance that someone has obtained the private key for 1tbzj and is using it for some reason. There is an extraordinarily small chance of a collision. You might move your own funds out just be safe.
I was considering that, now done. Part 2 would be to transfer the 519.704, now 519.70399999 because of the minimum trans fee to segregate the two amounts, to an offline wallet that I have secured against fire/flood/theft. Then if someone had a collision, they'll see "their" key emptied, and hopefully post in this forum that they suffered a theft (if they don't see this thread first), sign with MY key, and get their BTC back. Then I'll have to generate a new vanity address knowing 1tbzj is compromised. Actually, is this the brain wallet you were talking about the other day? In that case, it's probably pretty likely that's what's going on here... |
|
|
|
You might have to ask Con about how block reporting works, I'm not sure. I know there was some question recently about a similar subject (I think it was a max share issue) that reported erroneous difficulty levels or shares. There was a problem with US3 yesterday, but I can't imagine the problem would result in reporting erroneous blocks. Do you have any idea what time that took place?
I'll ask Con about the possibility of erroneous block reports, but I just have no idea what time it was. All I can say if somewhere between the time I took those screenshots and the start timer on those screens. that's 21 hours I believe. I've got logs, if that helps. Logs might have the block hash. The misreported difficulty issue should not have affected the block detection. |
|
|
|
...post  Is it that you don't like using Watch or that you wanted us to know that you are?  Well... If no one wants the money back we might as well share it evenly between the first posters on this thread... just saying |
|
|
|
...post |
|
|
|
The background you've posted is wrong. Eligius has always paid out immediately (or as close to it as possible); while there were some delays in SMPPS due to the variance of block finding times, the maximum rewards ever took was a mere 3 days since I made sure to send before any balance was waiting that long.
Well, it was nice of you to dip into your own pocket to pay miners, that's not a part of the SMPPS protocol. Obviously these payouts came from the pool wallet, which gets filled by the SMPPS buffering and when miners haven't earned enough to achieve a reasonable payout yet. But the pool wallet had insufficient funds to pay extra credit - isn't that why there was a back log? There was a backlog because the pool was rewarding miners with buffer. This was mostly before we dipped into extra credit - Eligius went about a year(?) straight lucky. At no point was raw (ie, not converted to reward) extra credit paid of course. Your blog misrepresents extra credit as "owed", which it is not and never has been. This is something you've mentioned many times, and I don't understand it. If extra credit is not owed, why pay it? If you didn't pay it, would miners still earn 100% of PPS? It's paid as part of the reward system rules, as an incentive for miners to keep mining even on long rounds when the buffer is empty. No reward system can pay 100% PPS, with or without extra credit. SMPPS and CPPSRB just do the best they can to try to achieve that. Do you mean irl or in theory? Theoretically, any provable fair reward method without a fee can pay 100% PPS. If you mean irl, then ok, but the extra credit is an integral part of SMPPS and if the extra credit isn't guaranteed to be paid even in theory, then it even theoretically it may not pay 100% PPS. I understand this never happened for SMPPS, but I would like to understand your thoughts on the matter better. Theoretically, reward systems can pay 100% PPS given infinite time. SMPPS's extra credit is part of the mechanism it uses to achieve this; many other systems use variance to do it. In other words, extra credit is only as obliged in SMPPS, as if proportional pools are obliged to have lucky rounds. In theory, both (EC rewarding, and prop lucky rounds) should happen - but there is no guarantee/debt of them. This is why I thought discriminating between a "buffer" and "extra credit" was wrong. The point of extra credit is to enable fair rewards, and to achieve PPS. The discrimination is necessary and important. The buffer is guaranteed (the pool already has it!), but nothing can guarantee future findings - no matter whether it's SMPPS's EC, proportional's lucky blocks, or any other system. CPPSRB also tracks a value similar to "extra credit", but the same still applies. With CPPSRB, extra credit is actually less likely to ever be paid due to how LIFO works. On the upside, CPPSRB gives actual rewards much more like proportional, so they fit with the actual block payout availability much better without any manual sends; in normal operation, no payout should be delayed more than a single block, and most (at least on Eligius) will be paid out in the same block they are earned in. I read the info on the Eligius site for the first time, and it's quite an interesting reward method. By assuming that 100% of PPS value won't be paid (am I right in that?) you're able to make certain that reward are paid in a timely manner. So time to maturity is reduced to 100 network block confirmations, with a trade off of increased earning variance. I think most miners would be happy earning a little less if they didn't have to be worried about when it may get paid. Have you derived (or otherwise calculated) the expected PPS miners will earn under the new method? With Eligius's no-fee implementation, shares are still paid 100% PPS value, but the unavoidable loss is in the backlog of shares that inevitably never get paid. I think it's easiest to explain if you compare it to PPLNS; the main differences there are just that shares are never paid twice (which results in older shares getting paid on lucky rounds). While PPLNS effectively forces a pool to compromise between variance (low N, like <=expected) and reward delays (high N, like expected*  , CPPSRB's rewarding older shares rather than doubling rewards gives it a low variance with instant rewards. Nice analogy - that makes it clearer, thanks. However it seems that there is a possibility that in the long term not all shares would be paid. In practice, it is pretty much guaranteed that some shares will go unpaid ever. That end result is, again, unavoidable no matter what reward system is used. However, informed miners are happier miners. Including, for example, how many shares on average won't be paid in a given time period - a month in your explanation may help. Or the probability that any given share won't be paid in a given time period. It may also be possible that some shares will never be paid - and if so miners should know the probability of that, too - if it's possible to derive. The probability a share is never paid is pretty much identical to the probability of blocks being stale. Considering all the factors involved there, it can vary quite a bit (as much as 5% at extremes, it seems) and isn't likely something that can be predicted. It may be that very few shares won't be paid long term and have no significant impact on miners, but I think it would be good for miners to know what that might be - even if it's just the result of a simulation rather than a derivation. Have you managed anything like that? I don't know any simulation of stale blocks. I'm not sure it's even possible. |
|
|
|
Considering all you talk about how I act/do is lies, that clearly isn't the real problem you have with me.
so truth are lies now? this explains alot, for example why u say u never lie sry luke all ur post are proove enough. sry, youve been beaten by simple logic, there's no way to circumvent it. Obviously you have no idea what logic or truth are. Defining "Time to maturity" as follows: Maturity time: This is the average time it takes to receive the due reward. High maturity time causes loss of the time value of money, and risk of the pool being discontinued before the rewards are received. (from https://bitcoil.co.il/pool_summary.pdf) If you find the name confusing, call it "Average time to payment" or some such. 0. Background. The old Eligius reward method had an average time to maturity greater than that for other methods (for example PPLNS) and certainly longer than 100 or even 120 network confirmations. If there is significantly poor luck, then it may take a while for miners to receive their payment. So while the variance in payments is zero (SMPPS is a PPS variant, so all shares are paid at B/D) the time it catualy takes to recieve your payment varies from no time at all to a significant amount of time. After a pool using SMPPS solves 1000 blocks, on average miners will have had to wait for the pool to solve ~ 8.4 blocks before receiving payment (Further explanation here). The derivation of time to maturity for SMPPS is derived in Appendix F of https://bitcoil.co.il/pool_analysis.pdf1. Question. Now that I've made clear the meaning of "time to maturity" and shown (with references, albeit my own work) how time to maturity was a problem for SMPPS, I'm wondering what the time to maturity is for the new reward method. Have you derived it yet? I think it's important for miners to know and understand there may be more waiting involved than for other methods. Threads like this one would be much less likely if it was more wisely known and explained. The background you've posted is wrong. Eligius has always paid out immediately (or as close to it as possible); while there were some delays in SMPPS due to the variance of block finding times, the maximum rewards ever took was a mere 3 days since I made sure to send before any balance was waiting that long. Well, it was nice of you to dip into your own pocket to pay miners, that's not a part of the SMPPS protocol. Obviously these payouts came from the pool wallet, which gets filled by the SMPPS buffering and when miners haven't earned enough to achieve a reasonable payout yet. Your blog misrepresents extra credit as "owed", which it is not and never has been. This is something you've mentioned many times, and I don't understand it. If extra credit is not owed, why pay it? If you didn't pay it, would miners still earn 100% of PPS? It's paid as part of the reward system rules, as an incentive for miners to keep mining even on long rounds when the buffer is empty. No reward system can pay 100% PPS, with or without extra credit. SMPPS and CPPSRB just do the best they can to try to achieve that. If the extra credit in SMPPS was ignored/didn't exist ( PPPS), it would underpay miners during long rounds after it went broke, just like proportional always does for long rounds.
Most other reward systems (PPLNS, proportional, DGM, etc) never attempt to track or pay extra credit at all - under those systems, miners never get this. It is therefore unfair and possibly dishonest to count extra credit against "time to maturity".
I don't understand this. There's no need for other reward methods to track extra credit, since they're provable fair reward methods that have variance due to pool luck (which miners on Eligius do not experience). So what "extra credit is there to track? A DGM pool with a week of bad luck, will never try to make it up to miners who mined only for that week. CPPSRB also tracks a value similar to "extra credit", but the same still applies. With CPPSRB, extra credit is actually less likely to ever be paid due to how LIFO works. On the upside, CPPSRB gives actual rewards much more like proportional, so they fit with the actual block payout availability much better without any manual sends; in normal operation, no payout should be delayed more than a single block, and most (at least on Eligius) will be paid out in the same block they are earned in. I read the info on the Eligius site for the first time, and it's quite an interesting reward method. By assuming that 100% of PPS value won't be paid (am I right in that?) you're able to make certain that reward are paid in a timely manner. So time to maturity is reduced to 100 network block confirmations, with a trade off of increased earning variance. I think most miners would be happy earning a little less if they didn't have to be worried about when it may get paid. Have you derived (or otherwise calculated) the expected PPS miners will earn under the new method? With Eligius's no-fee implementation, shares are still paid 100% PPS value, but the unavoidable loss is in the backlog of shares that inevitably never get paid. I think it's easiest to explain if you compare it to PPLNS; the main differences there are just that shares are never paid twice (which results in older shares getting paid on lucky rounds). While PPLNS effectively forces a pool to compromise between variance (low N, like <=expected) and reward delays (high N, like expected* , CPPSRB's rewarding older shares rather than doubling rewards gives it a low variance with instant rewards. |
|
|
|
You're probably right, but time to maturity is also a factor. If miners have to wait a significant time to obtain their coins, this also has an impact on earnings. Have you derived the expected time to maturity for Eligius' new reward method? If so could you post it here so it can be compared to p2Pools?
Time to maturity is always 100 confirmations, no matter where you mine, unless the pool is doing some kind of advance (or delay). Neither Eligius and p2pool give any advance, and Eligius only delays rewards for the miners' benefit (to avoid transaction fees when you go to spend them, the pool waits until you have earned a reasonable amount). Defining "Time to maturity" as follows: Maturity time: This is the average time it takes to receive the due reward. High maturity time causes loss of the time value of money, and risk of the pool being discontinued before the rewards are received. (from https://bitcoil.co.il/pool_summary.pdf) If you find the name confusing, call it "Average time to payment" or some such. 0. Background. The old Eligius reward method had an average time to maturity greater than that for other methods (for example PPLNS) and certainly longer than 100 or even 120 network confirmations. If there is significantly poor luck, then it may take a while for miners to receive their payment. So while the variance in payments is zero (SMPPS is a PPS variant, so all shares are paid at B/D) the time it catualy takes to recieve your payment varies from no time at all to a significant amount of time. After a pool using SMPPS solves 1000 blocks, on average miners will have had to wait for the pool to solve ~ 8.4 blocks before receiving payment (Further explanation here). The derivation of time to maturity for SMPPS is derived in Appendix F of https://bitcoil.co.il/pool_analysis.pdf1. Question. Now that I've made clear the meaning of "time to maturity" and shown (with references, albeit my own work) how time to maturity was a problem for SMPPS, I'm wondering what the time to maturity is for the new reward method. Have you derived it yet? I think it's important for miners to know and understand there may be more waiting involved than for other methods. Threads like this one would be much less likely if it was more wisely known and explained. The background you've posted is wrong. Eligius has always paid out immediately (or as close to it as possible); while there were some delays in SMPPS due to the variance of block finding times, the longest that rewards ever took was a mere 3 days since I made sure to send before any balance was waiting that long. Your blog misrepresents extra credit as "owed", which it is not and never has been. Most other reward systems (PPLNS, proportional, DGM, etc) never attempt to track or pay extra credit at all - under those systems, miners never get this. It is therefore unfair and possibly dishonest to count extra credit against "time to maturity". CPPSRB also tracks a value similar to "extra credit", but the same still applies. With CPPSRB, extra credit is actually less likely to ever be paid due to how LIFO works. On the upside, CPPSRB gives actual rewards much more like proportional, so they fit with the actual block payout availability much better without any manual sends; in normal operation, no payout should be delayed more than a single block, and most (at least on Eligius) will be paid out in the same block they are earned in. for max income, use p2pool Explain... Never heard of it and dunno what it is!  He's mostly trolling. p2pool's reward system basically makes it improved solo mining. It's not a bad pool, but it certainly doesn't pay better than others. its the pool with the max outcome, besides the increased PPS pools (unlike ur scampool). Can't get higher than nofee+txnfees. Admittedly, Eligius is only nofee, but txnfees are so worthless it isn't worth the effort right now - that hardly makes it a "scampool", so that verifies your status as troll. On the other hand, p2pool has very high variance, while Eligius has much lower, so for most people, Eligius is the better choice. You're probably right, but time to maturity is also a factor. If miners have to wait a significant time to obtain their coins, this also has an impact on earnings. Have you derived the expected time to maturity for Eligius' new reward method? If so could you post it here so it can be compared to p2Pools? Time to maturity is always 100 confirmations, no matter where you mine, unless the pool is doing some kind of advance (or delay). Neither Eligius and p2pool give any advance, and Eligius only delays rewards for the miners' benefit (to avoid transaction fees when you go to spend them, the pool waits until you have earned a reasonable amount). I'm not getting involved in the argument -- I refrain from internet arguments or personal attacks. I'm just saying that if you must insult him don't insult his religion, especially if it's one of the largest religions in the world like Christianity or Islam. You'll inadvertently insult other people and then they won't like you. Some crazy people might even try to do you harm. Seems pretty clear to me his anti-Christianity is the fundamental reason he hates me enough to slander me. wrong, its 120 confirmations... dosnt even know the basics and is a bitcoin dev, shame on u... no i dont hate u because ur believe some stupid shit, its because how u act and what ur doing. Wrong, it's 100 confirmations. 120 is just what Bitcoin-Qt and (most?) other clients enforce on your computer - you could hack your client to send as soon as it reaches 100 (though due to a bug in all current released versions, no miner will accept it into their block until 101). Considering all you talk about how I act/do is lies, that clearly isn't the real problem you have with me. |
|
|
|
|
FYI, Eligius has been CPPSRB (not *MPPS) for a while now.
|
|
|
|
for max income, use p2pool Explain... Never heard of it and dunno what it is! He's mostly trolling. p2pool's reward system basically makes it improved solo mining. It's not a bad pool, but it certainly doesn't pay better than others. its the pool with the max outcome, besides the increased PPS pools (unlike ur scampool). Can't get higher than nofee+txnfees. Admittedly, Eligius is only nofee, but txnfees are so worthless it isn't worth the effort right now - that hardly makes it a "scampool", so that verifies your status as troll. On the other hand, p2pool has very high variance, while Eligius has much lower, so for most people, Eligius is the better choice. You're probably right, but time to maturity is also a factor. If miners have to wait a significant time to obtain their coins, this also has an impact on earnings. Have you derived the expected time to maturity for Eligius' new reward method? If so could you post it here so it can be compared to p2Pools? Time to maturity is always 100 confirmations, no matter where you mine, unless the pool is doing some kind of advance (or delay). Neither Eligius and p2pool give any advance, and Eligius only delays rewards for the miners' benefit (to avoid transaction fees when you go to spend them, the pool waits until you have earned a reasonable amount). I'm not getting involved in the argument -- I refrain from internet arguments or personal attacks. I'm just saying that if you must insult him don't insult his religion, especially if it's one of the largest religions in the world like Christianity or Islam. You'll inadvertently insult other people and then they won't like you. Some crazy people might even try to do you harm. Seems pretty clear to me his anti-Christianity is the fundamental reason he hates me enough to slander me. |
|
|
|
for max income, use p2pool Explain... Never heard of it and dunno what it is! He's mostly trolling. p2pool's reward system basically makes it improved solo mining. It's not a bad pool, but it certainly doesn't pay better than others. its the pool with the max outcome, besides the increased PPS pools (unlike ur scampool). Can't get higher than nofee+txnfees. Admittedly, Eligius is only nofee, but txnfees are so worthless it isn't worth the effort right now - that hardly makes it a "scampool", so that verifies your status as troll. On the other hand, p2pool has very high variance, while Eligius has much lower, so for most people, Eligius is the better choice. not even to talk about that u use ur pool to attack altchains, this is an abuse of the miners since u dont tell them. according to simple logic this is a scam. i know uve done alot for bitcoin but i also know ur a total jerk who's brain got totaly compromised by ur church stuff and most post are lies. i dont want to offend u but this has do be said once. why, just why cant u just one time not lie (yes even telling half trues like u do is lieing!) and be honest? well, this is offtopic so it dosnt belong here. No, you are lying here. |
|
|
|
for max income, use p2pool Explain... Never heard of it and dunno what it is! He's mostly trolling. p2pool's reward system basically makes it improved solo mining. It's not a bad pool, but it certainly doesn't pay better than others. its the pool with the max outcome, besides the increased PPS pools (unlike ur scampool). Can't get higher than nofee+txnfees. Admittedly, Eligius is only nofee, but txnfees are so worthless it isn't worth the effort right now - that hardly makes it a "scampool", so that verifies your status as troll. On the other hand, p2pool has very high variance, while Eligius has much lower, so for most people, Eligius is the better choice. |
|
|
|
for max income, use p2pool Explain... Never heard of it and dunno what it is! He's mostly trolling. p2pool's reward system basically makes it improved solo mining. It's not a bad pool, but it certainly doesn't pay better than others. |
|
|
|
I hacked
static bool __clone_available(void)
{
struct work *work, *tmp;
bool cloned = false;
mutex_lock(stgd_lock);
if (!staged_rollable) {
mutex_unlock(stgd_lock);
goto out;
}
mutex_unlock(stgd_lock);
I do not know if it is OK but from what i can see there is race condition accessing staged_rollable or at least i think so
I will let you know if it crashesh again
For me it seems that stage_work called from __clone_available crashed
From the other hand
static void stage_work(struct work *work)
{
applog(LOG_DEBUG, "Pushing work from pool %d to hash queue", work->pool->pool_no);
work->work_block = work_block;
static unsigned int work_block; is a global and it has been never locked, so maybe a instance of test_work_current was trying to change it
work->work_block = ++work_block; and race conditions occurred?
I am not both c and threads expert, but as long as i know each global var shall be locked when changed. Maybe when read also but it depends on gcc os and whatever. Is that true? If yes we have a potential code that can cause core dumps because of it
I do not how to lock work->work_block = ++work_block; so i am running same version with staged_rollable locked and i do expect within a day or two same crash to appear
10X
For the first function, you should note /* Called with stgd_lock held */
static bool __clone_available(void)
So adding another lock does nothing and only risks recursive lock deadlocks or livelocks. Someone might mention to Con that it is in fact called without the lock held, and that the deadlock occurred when stage_work (called by __clone_available) tried to lock the same lock. I fixed this in BFGMiner (since 2.10.0) by staging the cloned work outside of the lock in clone_available. |
|
|
|
on a windows 7 system setup with 4ztex boards and 6 6500s i can not get any version past 2.9.1 to work
a few that i have tried crash. a few just wont load the 6500 boards
any ideas hit of changes done after 9.1 that could cause this?
let me know how i can help. time's going to be limited till after Christmas but i'll for sure do what i can to help get this figured out
So 2.9.2 fails? Can you make a debuglog? bfgminer YOUR OPTIONS GO HERE --debuglog 2>debug.log |
|
|
|
I see no reference to the new pgaset command in the documentation? How do we use this command? is it a flag we use on the executable, or one for the config file?
Looks great though!
It should be documented in the API-README file. |
|
|
|
NEW VERSION 2.10.1, DECEMBER 21 2012Human readable changelog:- Replaced the work-based efficiency with new bandwidth-based efficiency.
- modminer: Enable frequency adjustments up to 230 MHz, and allow changing the frequency (non-sticky) via the new "pgaset" RPC command (based on code by kano).
- Various fixes to improve portability, specifically to Mac OS X and Windows (workaround for broken libcurl builds).
- Numerous stratum fixes, including failover recovery. Also allow using stratum with scrypt.
- miner.php updates from kano
Full changelog- libztex: fixed a typo
- libztex: check returnvalue of libusb_claim_interface() and release the interface in case of early exit
- Bugfix: submissions: Skip FD_ISSET when fd==-1 (let the next select setup deal with cleaning them out)
- Bugfix: Remove sws from write_sws list when discarding it due to pre-send stratum disconnection
- Bugfix: Shutdown stratum socket when initiate fails, so it doesn't linger
- Bugfix: Clear stratum receive buffer when initializing, in case there was extra unprocessed data in it from a previous connection
- Stop all work from the current pool if it's a stratum pool once it is disconnected since it will be invalid upon reconnecting.
- Discard all staged work from stratum pools as well as the shares upon disconnection since all the work becomes invalid.
- Use correct cbreak after 15 second delay when no pool is found alive.
- modminer: Set default clock frequency to user request so it sticks better
- modminer: Make valid frequency range consistent: 2-230
- Allow stratum to work with scrypt.
- MMQ add api pgaset for clock
- API V1.23 - new pgaset command, to be used soon
- Protect the best_share/best_diff values under control lock.
- Bugfix: modminer: Return failure to change frequency when device reports it
- opencl: Look in the right place for OpenCL library on Mac OS X
- Bugfix: AC_C_BIGENDIAN is reported to have problems, and invasive even if buried in a conditional, so don't use it
- Bugfix: Check for bswap_* first, to avoid redefinition based on other variants
- Bugfix: autoheader isn't smart enough to figure out variable defines, so use AH_TEMPLATE for each possible header
- Check a stratum pool hasn't gone dead while being a backup pool and missed having its idle flag cleared.
- Fix null pointer issue when one chip on an X6500 is not initialized yet when reading temperature.
- Hot-patch broken libcurl pkgconfig CFLAGS found in libcurl's Windows binaries
- Update OpenCL 1.2 headers from http://www.khronos.org/registry/cl/api/1.2/
- Reorganize detection of platform byteswap macros and endian to be more robust using autoconf
- Move new bandwidth-based Efficiency to status line
- Replace work-based efficiency with new bandwidth-based efficiency
- Bugfix: Pull out GBT request collapsing since it is no longer needed with new get_work main loop
- Bugfix: Free unused work when waiting on external GBT request
- README: Explicitly mention automake dependency
- README: Update AMD APP SDK URIs
- Bugfix: Free shares discarded before beginning submission
- Bugfix: Discard stratum shares waiting for a writable socket, if the pool disconnects in the meantime
- Bugfix: Always let watchpool thread handle dead pool recovery (including for stratum-only pools)
- Bugfix: Avoid lingering stratum_auth when connection is lost
- API-README explain custom page extensions in miner.php
- miner.php add a sample group pool report
- miner.php allow where,group,having on cumstom pages
- Bugfix: Hook CURLOPT_DEBUGFUNCTION to count actual bytes sent/received by libcurl
- Bugfix: Reset pool transparency_time when connecting to stratum
- Bugfix: Immediately discard shares found on disconnected stratum pools, since there is no way to submit them
- Bugfix: Decrement total_submitting when stale shares are discarded before any submission attempts
- Bugfix: Only try to compare stratum job_id for work that has a job_id (ie, ones that came from stratum)
- Bugfix: Recheck has_stratum even if the pool hasn't changed, in case pool has switched to another protocol in the process; also only delay 5 seconds before retry if pool is the same
- Bugfix: Try GBT if no pool protocol is known (can occur in the process of stratum failover to GBT)
- Bugfix: Correctly track discarded stratum shares, and log them as "disconnect" in sharelog
- Check for EWOULDBLOCK when supported in send and recv as well.
- Use the raw send() command instead of curl_easy_send since curl raw socket usage introduces random bugs on windows.
- Use raw recv() command in place of curl_easy_recv since the curl implementation introduces random bugs on windows builds when the recv fails.
- miner.php when displaying a single rig, add prev/next rig buttons if they exist, next to refresh
- miner.php allow custom page joins for STATS
- miner.php - include windows easyphp link
- driver-ztex: use the correct size for the swap array
- API stats - display pool byte transfer stats
- Pool store data transfer stats
- Benchmark incorrect work size
- ChangeLog refer to NEWS
- driver-ztex: search the complete noncerange based on the actual speed
- API-README update
- api use a dynamic io buffer, truncated before it reaches the current ~64k limit
|
|
|
|
It fixes the shares looking high because the (I am guessing backup Bitcoin) target is far higher. I would rather see what the highest achieved was not the highest accepted was. Seems like a solution in search of a problem. Both before and after intend to show the highest achieved. But the cgminer code calculated the hash twice, in two different ways, and the hash-to-difficulty code assumed it was one of those ways. When the share doesn't meet the pool target, the hash-to-difficulty code was run on it with its hash calculated the opposite way, and as a result gave the wrong result. My rewrite cleans up the code so it's actually readable, and makes the share->hash value always consistent with SHA256 and the share_diff function expectations. I also wrote a much-less-changed fix for BFGMiner 2.8.x and 2.9.x: https://github.com/luke-jr/bfgminer/commit/006faacThis one doesn't clean up the code to make it more readable, though. But as a diff, it is easier to see what the problem was. The function you replaced works fine and does exactly what I wrote it to do 15 months ago. Trolling and lies ignored... the function you wrote (regeneratehash) indeed does work just fine. The problem is in fulltest, as is clear from the much-less-changed patch. |
|
|
|
It fixes the shares looking high because the (I am guessing backup Bitcoin) target is far higher. I would rather see what the highest achieved was not the highest accepted was. Seems like a solution in search of a problem. Both before and after intend to show the highest achieved. But the cgminer code calculated the hash twice, in two different ways, and the hash-to-difficulty code assumed it was one of those ways. When the share doesn't meet the pool target, the hash-to-difficulty code was run on it with its hash calculated the opposite way, and as a result gave the wrong result. My rewrite cleans up the code so it's actually readable, and makes the share->hash value always consistent with SHA256 and the share_diff function expectations. I also wrote a much-less-changed fix for BFGMiner 2.8.x and 2.9.x: https://github.com/luke-jr/bfgminer/commit/006faacThis one doesn't clean up the code to make it more readable, though. But as a diff, it is easier to see what the problem was. |
|
|
|
It should, if you setup the SQL schemas and such correctly. |
|
|
|
After starting up 2.10.2 for the first time, I almost immediately got "Best share: 25", but no accepted shares for a while. Then I finally got an accepted share 4/4. Looks like the Best share display still isn't fixed, unless for some reason my target was above 25 (never been above 8 for me at BitMinter). Also, now Best share is at 207, even though all the accepted shares for this run are still on screen, and the highest is 55/4.
Fix for this is https://github.com/luke-jr/bfgminer/commit/bfab076d |
|
|
|
|
Show Posts
