Most real-time discussion is in the IRC channel, though I'm of course taking forum posts and polls into consideration too. A lot of people didn't like the PPLNS plan; CPPSRB is similar to PPLNS, but without the objectionable parts (that is, it retains the EC, and pays out with less variance and in a more reasonable timeframe) Thanks for the info. I actually got that from the first poll (which didn't include it as an option). I guess my question was actually about the timeframe and changes necessary. I was under the impression you weren't switching yet, the second poll implied that whatever new thing we would use would have a separate URL, and then bam, artefact2's statistics are down to allow a new system to get up and running faster. I'm not sure if it's a new system for statistics or for miners, and while EC is aparently transferring, I'm not sure whether or not I need to point my miners to a different server at a given point. I guess I should check the OP, which I just did, and assume all is well since it hasn't changed. Retaining EC doesn't really make parallel pools possible. Statistics had to be dealt with sooner than expected because they grow the disk use by at least 3 GB/day, and we were running out too fast... |
|
|
|
Statistics are filling the disk fast, and since they don't allow for deleting data, it's doomed to die permanently within 1-2 weeks (47 GB remaining). If it fills the disk completely this time, it will also kill mining(!) too, so it's essential that we get things moving on the updates.
Patches welcome to adjust them to survive without endless share database... wizkid expressed that he might be able to finish new ones this weekend.
Based on all the past discussion, it seems like CPPSRB is the way to go, with EC carrying over from Eligius-Ra. I feel like there's some other thread I should be watching, because I have no idea why statistics are down to set up a new server faster, or if I should be pointing at a new server. The two poll threads I saw didn't have CPPSRB as an option (although I did see enough posts in them to understand why it would be the way to go). Maybe this has all been posted in IRC or something other than this forum, but I would like to know what's going on, and only watch the forum. Most real-time discussion is in the IRC channel, though I'm of course taking forum posts and polls into consideration too. A lot of people didn't like the PPLNS plan; CPPSRB is similar to PPLNS, but without the objectionable parts (that is, it retains the EC, and pays out with less variance and in a more reasonable timeframe) |
|
|
|
|
Does the "restart BFGMiner when ADL fails" function do anything useful for anyone? I understand it was an attempt to workaround ADL/driver bugs, but I'm told that it never helped. On the other hand, it breaks when used with "Switch User" or some "hwinfo64" tester on Windows. If it doesn't do anything useful, I'll plan to remove it for 2.7.5, which I hope to release later today (so tell me ASAP if you need this!).
|
|
|
|
|
FWIW, my 5850 (stock settings, SDK 2.1) has a 5 MH/s performance loss with the new kernels.
|
|
|
|
I see some features that are planned for 0.7 release (like get raw block/transaction data). Is there anyplace to download the development version for that 0.7?
Thanks
0.7.0rc1 is due out any day now. |
|
|
|
|
I've received the X6500, but it doesn't have the stock heatsinks/fans, so I'll need to sort that out first. Any recommendations on the best (without going crazy on price) for the highest clockspeeds?
|
|
|
|
Luke: pretty please? Let's switch to some sort "active mining" PPS for now. Someone have code for this? |
|
|
|
is there a problem with the statistics?
2nd. I've got a 10-ish hour gap today where there were no statistics, but I don't believe my miners failed over. Statistics are filling the disk fast, and since they don't allow for deleting data, it's doomed to die permanently within 1-2 weeks (47 GB remaining). If it fills the disk completely this time, it will also kill mining(!) too, so it's essential that we get things moving on the updates. Patches welcome to adjust them to survive without endless share database... wizkid expressed that he might be able to finish new ones this weekend. Based on all the past discussion, it seems like CPPSRB is the way to go, with EC carrying over from Eligius-Ra. |
|
|
|
Everything aside, I think this might be a good idea to support. Is there a reason standard PGP doesn't work, though? |
|
|
|
NEW VERSION 2.7.4, AUGUST 23 20122.6.6 is also released with more backported fixes. Human readable changelog:Full changelog- Perform select_pool even when not lagging to allow it to switch back if needed to the primary.
- Simplify macros in output kernels avoiding apparent loops and local variables.
- Carry the needed bool over the work command queue.
- Move the decision to queue further work upstream before threads are spawned based on fine grained per-pool stats and increment the queued count immediately.
- Track queued and staged per pool once again for future use.
- OpenCL 1.0 does not have native atomic_add and extremely slow support with atom_add so detect opencl1.0 and use a non-atomic workaround.
- Pools: add RollTime info to API 'stats' and 'Stats' button in miner.php
|
|
|
|
This does not explain in noob friendly language what this is for.
This is pure geek speak for 100% of the new users.
Sign messages? Why? To who?
Prove I own them? What them?
A much better text is needed.
The text need to explain.
Why?
What?
Who can see the message, everyone or just the one who recieves the coins?
Does it cost anything?
Will they see the message for sure?
Can the message be changed?
Will it stay forever?
Something like this:
You can prove you own an adress and any coin in it, by signing a message with that adress.
This message can be seen by the one who recieves the coins and anyone who looks at your adress.
The explanation text is unrelated to this poll/discussion. If you think the current wording is not good enough, you may wish to open a new issue. |
|
|
|
The only reason it looks useful is because of the Verify option - or is that because you used a more recent code base than is stable? Maybe because it's exclusive to Linux? in any case, I want that Verify option in my client.
It's in 0.7 regardless of first/second class. |
|
|
|
Just to make things clear, by "first-class" you mean the way to access this functionality is from an always-visible button on the every screen?
Yes, it is a tab in the main window like other first-class functionality. |
|
|
|
 First-class messaging, where the "Signatures" tab is part of the main window, was originally the default mode of operation for the Sign Message GUI function, but was relegated to the menu by default due to uncertainty of how much use it would get. I think 0.6 has proven it useful (for example, Bitcoin OTC now uses it for primary authentication) and it should be given first-class by default. However, others disagree and even want to remove the option (to make it first-class) entirely. Supposedly I'm the only one who wants message signatures to be first-class. I am hoping this poll will prove the opposite. First-class messaging is a compile-time feature for Bitcoin-Qt 0.6. By adding the FIRST_CLASS_MESSAGING=1 option to qmake, builds will treat message signing the same way as other Bitcoin-Qt functions, instead of relegated to another dialog via the menu as it is by default. On Gentoo, users can enable it simply by installing with the "1stclassmsg" USE flag. Note that the Verify Message will be available with both first-class and second-class messaging. |
|
|
|
Temporary hack to fix 2.7.3 with StreamSDK 2.1: 1) Figure out which *.cl file you use, and open it in a PLAIN text editor (eg, Notepad - NOT Wordpad!) 2) Add to the very top: #pragma OPENCL EXTENSION cl_khr_global_int32_base_atomics : enable Find and replace every instance of " atomic_add" with " atom_add" Note that this seems to still have a 2 MH/s (on 5850) performance hit. |
|
|
|
NEW VERSION 2.7.3, AUGUST 23 2012Human readable changelog:- Fix new networking code.
- OpenCL: New kernels.
- Updated miner.php
Full changelog- Minimise the number of getwork threads we generate.
- Pick worksize 256 with Cypress if none is specified.
- Give warning with sdk2.7 and phatk as well.
- Whitelist sdk2.7 for diablo kernel as well.
- Only keep the last 6 blocks in the uthash database to keep memory usage constant. Storing more is unhelpful anyway.
- Increase kernel versions signifying changed APIs.
- BFL flash - more FPGA-README
- Check we haven't staged work while waiting for a curl entry before proceeding.
- Use atomic ops to never miss a nonce on opencl kernels, including nonce==0, also allowing us to make the output buffer smaller.
- Remove compile errors/warnings and document compile/usage in FPGA-README
- Ignore the submit_fail flag when deciding whether to recruit more curls or not since we have upper bounds on how many curls can be recruited, this test is redundant and can lead to problems.
- API-README update cgminer version number
- API-README fix groups P: example mistake
- API-README add COIN and other edits
- miner.php allow 'coin' is custom pages
|
|
|
|
I do wonder if there was an attacker in the wild trying this, there are various stalled out Bitcoin reports in different threads where new users getting the blockchain had to wipe the datadir and start again....
I checked github and this issue was worked around (fixed) 4 month ago: https://github.com/bitcoin/bitcoin/commit/be8651dde7b59e50e8c443da71c706667803d06dThe corresponding issue https://github.com/bitcoin/bitcoin/issues/1167 doesn't mention the merkle root calculation vulnerability, probably on purpose. It's hard to imagine someone stumbling upon this issue or this fix and suspecting and finding the problem with the merkle root calculation. The info might have slipped out some other way (maybe it was even pretty common knowledge amongst the devs) or maybe someone found this on his own seperately. I still think it's likely (gut feeling) that the problems people reported were actually caused by someone trying to exploit this (I also had these troubles). On the other hand, there's probably many other possible explanations. A lot of stuck nodes were investigated over the last year, and as far as I know they all turned out to be harddisk corruption. I'm aware of at least two people who were trying to figure it out on their own (with no information); one managed to suspect something to do with the merkle tree calculation (after giving up and resuming a number of times), but that was the closest he got before it was disclosed. |
|
|
|
winsows 7 x64 driver 12.8 SDK 2.7 cgminer 2.7.1 after few hours run appear error : [2012-08-22 08:41:14] Failed to create get_work_thread Most unusual. That is a fatal error because there are too many threads running or the system has run out of ram. This bug falls into the "I have no idea" category. Miners used to get this when there were a lot of weird network problems. I fixed it in BFGMiner, but it's back with the 2.7.0 changes. Perhaps my original fix might shed some light on the current problem. |
|
|
|
Luke is talking about block withholding. We know how to fix it for centralized pools in an incompatible way— as luke points out, though not for fully decentralized pools. You must have missed my decentralized-compatible fix on the dev ML a few months ago :p |
|
|
|
|
Show Posts
