* P2Pool will "skip ahead" to building on blocks not yet processed by the local bitcoind based on block headers received from P2Pool peers. This should significantly reduce the number of orphaned blocks we have if everyone upgrades. Honestly, without looking at the code, this sounds like it's begging to be exploited as an attack vector.
|
|
|
Is there any specific reason that a large number of transactions would specifically cause orphans? Is it just because they are slower to be propagated to the network, or is it just too taxing to current pool softwares and algorithms to deal with? They propagate the network much slower. First, because the larger amount of data takes longer to upload. Then more, because Bitcoin nodes don't relay it until they've verified every transaction in the block.
|
|
|
FWIW, all pools have been experiencing higher stales and orphaned blocks due to the excessive transaction volume lately resulting from SatoshiDice abusing the blockchain (there are much cleaner ways to do the same thing). After our second set of 3 orphans in a row, I'm a bit on the annoyed end. For now, I am blocking transactions to 1dice* addresses and limiting our blocks to 32 transactions until we've caught up on the extra credit or at least have a viable alternative solution. I really hate to do this, as Eligius has traditionally been one of the most accepting mining pools, so any suggestions on other possibilities would be most welcome.
While SatoshiDice does force its users/victims to pay a transaction fee, those fees despite their high volume still don't add up to anywhere near the 300+ BTC we've lost by mining their transactions - so it's not like we can just "make up for" the orphans by throwing transaction fees into the pot.
Note that this is really a global Bitcoin scalability problem, but wasn't an immediate issue because up until recently the transaction volume growth was accompanied by an equivalent influx of more people using Bitcoin. SatoshiDice's abuse breaks that balance, so the developer and mining communities need to find a solution faster than previously anticipated.
|
|
|
mpbm works also with the icarus miner, just change the bautrate to 56000 as kano has described. SW6 = 1234 ON
Tried that and still getting: "could not open port /dev\ttyUSB0: [Error 3] The system cannot find the path specified. Help? Learn what a slash is, and what a backslash is.
|
|
|
MPBM is the cgminer of the FPGA world. No, that's BFGMiner. Spare me the self promotion. What is the difference between cgminer and BFGMiner ? Maybe officially endorsed by BFL ( in the Mini Rig screenshots ) BFGMiner works better on FPGAs.
|
|
|
What did people think? They test them on testnet? Why would they do that? IMO, the fact that they're tested by mining real Bitcoins is obvious :p
|
|
|
MPBM is the cgminer of the FPGA world. No, that's BFGMiner.
|
|
|
The reason multi-wallet hacks like this are so easy is because we (in particular, sipa and Matt) have been working toward proper support for multiple wallets for some time now. With Satoshi's original code, it would have been very difficult - these are some big changes to refactor the code. 0.6 contained sipa's changes to abstract the CWallet class, and 0.7 or 0.8 will probably include Matt's abstraction layer for the blockchain. When all these bigger refactoring are complete, there will probably be a small change to tie it all together in a user-friendly way - until then, end users won't notice the bigger under-the-hood stuff that's been going on
|
|
|
I would hope the bitcoin community would be capable of showing a reciprocal respect by providing professional feedback as to what needs to be improved and continue to support this new vendor in a courteous manner. I feel Con's notification of infringement was more than courteous. He could have instead demanded they immediately cease distribution and comply or face loss of all license and legal action, for contrast.
|
|
|
FWIW, BFGMiner 2.4.3 has some very basic support for the MiniRig now. Hoping to have completely updated drivers to take advantage of the MiniRig better in the next version (and also in CGMiner), but this should be enough to get miners going for now.
|
|
|
FWIW, Eligius was just hit with 6gbit/sec DDoS for about 15 minutes before they gave up and moved on. No services were affected at any point as far as I can tell.
|
|
|
This is why I think the so-called "stable" backports are a bad idea. I want people to spend time finding and fixing bugs in 0.6.2, People running production services don't need the risk of new bugs, and will run old versions even if they're buggy. Stable branches let these people keep patched against bugs without the huge risk of new ones that comes with bleeding edge. I've been holding back on pointing out that the real cause of this was the huge complexity of BIP16, and that it would have probably not been a problem if we had adopted the simpler BIP17 instead. Nobody writes perfect code, so the risk of bugs in new versions is impossible to avoid. and I want people to realize that the core developers are not supporting older releases. I am, at least.
|
|
|
Regarding the stuck block bug...Block 177618 was rejected by BIP16-enabled backports (0.4.x and 0.5.x) due to containing a P2SH redemption with over 200 bytes in. Since the BIP16 code uses IsPushOnly to check the scriptSig for compliance, and IsPushOnly in these versions also enforced the 200-byte "is standard" rule, they were effectively treating it as a network rule. This was not a problem in 0.6 because the original OP_EVAL commit (e679ec9) moved the check outside of IsPushOnly. This problem could have been avoided if either IsPushOnly was renamed when its semantics/behaviour changed significantly, or I inspected the OP_EVAL commit in detail instead of skipping it over as a new feature and not bugfixes. Additionally, it might have helped, if the commit message mentioned the change, but I'd probably have still missed it as it wasn't relevant until months later. To get unstuck, follow these instructions:1. Ensure you have the minimum required 1280 MB memory available 2. Create a new file in your bitcoin directory (the same one with wallet.dat) called DB_CONFIG with the following two lines: set_lk_max_locks 1000000 set_lk_max_objects 1000000 3. Start bitcoind or Bitcoin-Qt 4. WAIT AT LEAST SIX HOURS; Your client will NOT show any signs of making progress during this time 5. When complete, your client should be up-to-date on block count 6. At this time, you may wish to delete the DB_CONFIG file and restart your client, to use less memory
|
|
|
NEW VERSION - 2.4.3, JUNE 14 2012This release cycle, things went mostly smooth with getting (new) things into CGMiner. Con doesn't want anything to do with CPU mining (I think he's planning to remove it completely from CGMiner), so some CPU mining improvements I made are BFGMiner-specific. ButterFlyLabs is supposed to be getting me some updated protocol docs for their MiniRigs like 2 days ago, but it's still not ready apparently, so I put in a stop-gap minimal change to get BFGMiner at least working on them, if not as ideal as they will when BFL gets me the new stuff (I offered the change to Con for CGMiner, but he prefers to wait until we have the "real deal" ready to go). ModMiner support got into CGMiner, but Kano made a mess of it when he added it to the RPC API; I cleaned it up in BFGMiner, so you can see the independent temperature and clock frequency of each of the 4 FPGA boards on the device. The problems cablepair was having with CGMiner on Windows seem to be a hardware issue with his prototype and shouldn't affect the production units. There were some reports of problems with Windows not liking many failed openings of invalid devices, so Kano cleaned up the driver selection part of --scan-serial (that is, where you can put "drivername:" in front of it to only try that driver); unfortuantely, he insisted on changing it to "TLA:" instead of the driver name, and Con threw the whole thing out because he wouldn't leave it backward compatible. In the meantime, I've got the actual improvement part of Kano's change in BFGMiner, so it should work if you had that problem. Finally, after giving it more thought, I decided to drop the CPU/GPU/PGA acronyms in favour of CPU/OCL (for OpenCL)/BFL/ICA/MMQ/ZTX. Since BFL is coming out with ASICs soon, probably using the same driver, and OpenCL might very well not be a GPU, it doesn't really make sense to assume they are. Human readable changelog:- Protocol acronyms replace device-type
- Basic BFL MiniRig support
- CPU mining improvements
- Mod miner FPGA support.
- Fixes for load balance and rotate pool strategies
- GPU engine speed changes - will not increase GPU speed if the fanspeed is above the maximum.
- Improvements in detecting lagging pools
- Lots of other minor fixes
Full changelog- Change device API "name" to reflect driver name abbreviation instead of device type name
- miner.php allow a separate user settings file
- modminer: Implement extended device stats to expose each Board to the RPC API
- Bugfix: Use new cgpu->thr for longpoll waking
- bitforce: Remove 4.5s delay before polling starts, since MiniRig finishes sooner
- FPGA - allow device detect override without an open failure
- Bugfix: Missing printf value in merge from cgminer
- Ensure C compiler is in C99 mode
- Add CPU core count detection for BSD/Mac
- Set CPU mining idle priority on Windows
- can_roll and should_roll should have no bearing on the cycle period within the miner_thread so remove it.
- Check for strategy being changed to load balance when enabling LPs.
- Check that all threads on the device that called get_work are waiting on getwork before considering the pool lagging.
- Iterate over each thread belonging to each device in the hashmeter instead of searching for them now that they're a list.
- When using rotate pool strategy, ensure we only select from alive enabled pools.
- Start longpoll from every pool when load balance strategy is in use.
- Add mandatory and block fields to the work struct. Flag any shares that are detected as blocks as mandatory to submit, along with longpoll work from a previously rejecting pool.
- Consider the fan optimal if fanspeed is dropping but within the optimal speed window.
- Fix typo in some API messages (succeess/success)
- api.c MMQ stat bugs
- Bugfix: Fix warnings when built without libudev support
- Bugfix: slay a variety of warnings
- Bugfix: modminer: Fix unsigned/signed comparison and similar warnings
- API add ModMinerQuad support
- Bugfix: Honour forceauto parameter in serial_detect functions
- modminer: Temperature sensor improvements
- modminer: Make log messages more consistent in format
- Only adjust GPU speed up if the fanspeed is within the normal fanrange and hasn't been turned to maximum speed under overheat conditions.
- ModMiner use valid .name
- New driver: BTCFPGA ModMiner
- Abstract generally useful FPGA code into fpgautils.c
- API add stats for pool getworks
- miner.php option to hide specific fields from the display
- miner.php add version numbers to the summary page
- Update debian configs to v2.4.2
- Add API and FPGA READMEs into Makefile to be included in source distribution.
- Icarus - fix unit64_t printf warnings
|
|
|
bitcoind and Bitcoin-Qt version 0.5.6 release candidate 2 ( sigs) are now available for download at: bitcoind version 0.4.7 release candidate 2 ( sigs) is now available for download at: bitcoind and Bitcoin-Qt version 0.6.0.8rc2 is also tagged in git. These are bugfix-only releases. Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr. BUG FIXES- Fix BIP16 validation to not enforce non-standard size limit of 200 bytes. Fixes being stuck at block 177617 (0.4 and 0.5)
- Do not select first address automatically in the address book when sending (Bitcoin-Qt)
- Hopefully final fix for the stuck blockchain issue
- Fix various database crashes and improve error checking
- Properly escape double-quote character in strings when exporting CSV
- Fix #952 by checking if we have a new address or an updated label
- Don't call exit() in Shutdown() for Bitcoin-Qt (fixes a tray-icon issue)
- Filter out whitespace and zero-width non-breaking spaces in Bitcoin address validator
- Properly store source addresses in database
- Remove redundant tooltip on optional transaction fee. Fixes #1218 (Bitcoin-Qt)
- Change initial balance on Overview page from "123.456 BTC" to "0 BTC" to not confuse users, whom might see it before we initialize with the real wallet balance (Bitcoin-Qt)
- Fix various places where Bitcoin-Qt was being shutdown improperly
- Hide UI immediately after leaving the main loop (Bitcoin-Qt)
- Various documentation corrections and debugging fixes
Thanks to everybody who contributed code or helped test this release: Pieter Wuille Philip Kaufmann Luke Dashjr Wladimir J. van der Laan Matt Corallo Jeff Garzik R E Broadley Fordy Gavin Andresen Michael Hendricks Chris Moore Christian von Roques Peter Todd
|
|
|
When I run bfgminer on windows 7 64 with my single I get Icarus Detect: Failed to open bitforce://./COM4. Can anyone help me on this. You can ignore this mis-error. Also, the slashes should be backslashes. It will be fixed in the upcoming release.
|
|
|
I plan to release BFGMiner 2.4.3 soon, but I am hoping to address some reported problems with the modminer driver first. Apparently between the time I finished writing the driver (when it worked), and the time CGMiner 2.4.3 was released with it, something got broken.
|
|
|
Stats are back but it seems like I mined a whole day for naught. Is that so?
The DNS was redirected to wizkid's pool. He should be making PPS payments sometime today. KVMoIP crashed, and apparently that takes the entire server offline wat Is it a KVM with a PDU controller? Otherwise... which model is it so that I can avoid it? Or is it an integrated IPMI setup? Lantronix Spider. It seems to be external, which means you could always plug the server's ethernet into the switch instead of the KVMoIP if you want, I think.
|
|
|
So, what happened anyway?
KVMoIP crashed, and apparently that takes the entire server offline
|
|
|
|