Luke, what did I tell you about trolling on the forum? Did you confess to doing it too much? |
|
|
|
The reason I switched from cgminer to bfgminer was for --coinbase-sig "DobZombi" I wanted some blocks named after me! but... I just tried using Stratum with BFGminer, and fuck-a-duck It CHEWED through 1GB of download in 10hrs! That's ridiculous! I've switched back to cgminer for the use of stratum. It's only using a few hundred bytes per second  Use GBT. Not only will it work better, but it's also required for --coinbase-sig to work at all. |
|
|
|
The question is also irrelevant. [...] constantly spreading FUD and other lies, with utter disregard for the truth. So, how are we stupid beings supposed to know the "truth" if you don't tell it to us? My point was that it doesn't matter whether pools support miners adding/removing transactions yet. Even without that, miners can obviously control the blocks by choosing which ones to mine since it's transparent. |
|
|
|
I think luke-jr must have stopped looking in that thread. No, I just continued ignoring known trolls such as yourself. The question is also irrelevant. Uhm, a "little" over the top. Don't you think? I'd say Graet is pretty well-respected. Calling him a troll brings your credibility into question. A few months ago, I might have agreed. But he's been getting pretty deep into Kano/Con's troll camp for a while now, constantly spreading FUD and other lies, with utter disregard for the truth. |
|
|
|
I think luke-jr must have stopped looking in that thread. No, I just continued ignoring known trolls such as yourself. The question is also irrelevant. |
|
|
|
Before I allow miners to modify the transactions I hope bitcoind will get a JSON-RPC method that allows you to send it a block (or just prevblockhash + list of transactions) and get back whether this would be a valid or invalid block. I would like to not have to duplicate all those checks that bitcoind does. BIP 23 Proposals will hopefully be supported in bitcoind soon. Even without that, miners could implement checking for double-spend attempts across multiple pools. But the only reaction available would be to stop mining in all pools with conflicting transactions. Not a very good solution. Or just compare with their own bitcoind and mine on the pool in the most agreement. |
|
|
|
Note that BFGMiner 2.9.x and cgminer have diverged: cgminers recent changes are not included here unless they fix a bug.
How do you plan on remaining competitive in the future with this sudden change? 2.10.0 (or 3.0 if ASICs hit first) will have the latest cgminer changes. I just wasn't comfortable with them being bug-free and they didn't seem to provide much (if anything) of value. |
|
|
|
NEW VERSION 2.9.4, DECEMBER 4 2012I hope 2.9.4 will be the first stable 2.9.x version, but I've also bumped the stable release to 2.8.7 just in case. Note that BFGMiner 2.9.x and cgminer have diverged: cgminers recent changes are not included here unless they fix a bug. BFGMiner git is pre-2.10.0, and does include those changes if you really want them (there was nothing that stood out as particularly useful or important). The pre-2.10.0 in git also includes a new feature to limit stratum bandwidth use at the expense of Bitcoin security, per request of slush (why his fee pool can't handle the bandwidth many no-fee pools do, I don't know). Human readable changelog:- Documented solo mining in README.
- Lots of small bugfixes everywhere.
Full changelog- Update libblkmaker to 0.2.1
- Count template number, and append it to the coinbase of templates without any cbtxn
- Bugfix: bitforce: Always increment global hw error counter when incrementing device hwe
- Bugfix: Correct order of printf-style arguments in cbappend fail
- Bugfix: Capitalize "MHz" correctly
- ztex: Correctly release mutex and reset FPGA if configuration fails
- ztex: Harmonize low-speed FPGA configuration code with high-speed code
- libztex: Silence warning: comparison between signed and unsigned
- Count longpoll decodes as queued work since the count otherwise remains static.
- Bugfix: Assign header-based rolltime before decoding work, so GBT expires overrides it properly
- Look for libusb_init in -lusb, since FreeBSD has it there
- Bugfix: Use pkgconfig for libusb when available, and try to guess the include path if not
- Bugfix: FPGA-README: Correct idVendor in example MMQ udev rule
- fixes target calc for mips openwrt
- Bugfix: clear_work: Whether the template is in fact being freed or not, the work reference to it needs to be
- libztex: Work around ZTEX USB firmware bug exposed by the FreeBSD libusb
- README: Document solo mining usage
- README: Update dependencies
- Bugfix: We should never roll stale work
- Ubuntu: Removing erroneous libssl dep again. GITHUB#94
- Bugfix: Clear out stratum share work before freeing it
- Provide rudimentary support for literal ipv6 addresses when parsing stratum URLs.
- Do not attempt to remove the stratum share hash after unsuccessful submission since it may already be removed by clear_stratum_shares.
|
|
|
|
Kano's just trolling, as usual.
LP and GBT take up significantly more bandwidth and resources than stratum. Why would anyone NOT want to use stratum, aside from personal aka non logical reasons? This simply isn't true. The only case where stratum uses noticably less bandwidth is the case where it is harmful to the Bitcoin network. Using it in a secure fashon uses about as much bandwidth as GBT. On the other hand, GBT is far more miner-friendly in general, since it allows miners more control over the blocks they are mining. |
|
|
|
Obviously none of those apply to MPEx (which DOES work as a wallet, among many other things it does for which it is much more famous). Isn't MPEx a website? gmaxwell's point 0 is completely unavoidable for anything web-based. |
|
|
|
|
Kano's just trolling, as usual.
|
|
|
|
When, someday, the ASIC may see the light, what will happen if a lot of this new computational power goes to the same pool? Which is quite feasible
Hope the pool supports GBT so the control remains with the miners. |
|
|
|
I have an x6500 with serial number AH01A895. I see it on COM4. What is the correct syntax to recognize the fpga in Windows? If you see it on COM4, then you don't have the driver installed. X6500s aren't serial-based. |
|
|
|
i strongly believe that BTC cgminer for GPU will be dead in a matter of weeks. Thus, all the efforts now for cgminer development should be in the direction of LTC (scrypt) be·lieve [bih-leev], be·lieved, be·liev·ing. verb (used without object) 1. to have confidence in the truth, the existence, or the reliability of something, although without absolute proof that one is right in doing so. Your dictionary is wrong. Belief does not imply either evidence or lack thereof. |
|
|
|
Are the Transaction-Longpoll warnings also a failure from you? I search the whole time for the fix  No, that was (if it's what I think you're referring to) a bugfix; it wasn't actually doing what it needed to be doing. |
|
|
|
Prior to 0.7.1 Bitcoin client actualy had LP support but than it's removed? LOL, what's next = disable ability to mine solo completely? bitcoind has never supported LP. 0.8 might if enough people care to test/review the code. |
|
|
|
Yeah, that's what happens when I try to fix a rare edge race condition when I have a fever over 39 C/103 F.  Just ignore that top commit for now and I'll fix it when I get better |
|
|
|
The OTC website should display a field in the web of trust database that indicates if the enforce setting is enabled. What would be even better, is if gribble scanned for unauthenticated users on any nicknames that looked remotely like the one being show on the website and gave a warning about anything possibly fishy. In all fairness, the only time I think a negative rating can be justified is when a user has breached the terms of a trade (ie. scammed). In all other instances, imo, there should never be a negative rating. Well, that's the only time I give a real human a -10 rating. But I use -1 to -3 for minor things that I'll want to note if I were to ever consider trading in the future (such as having absurd ideas about the obligation to repay debts, even if they've not failed to yet). |
|
|
|
If I put GBT on main port now then users with cgminer with GBT support but earlier version than 2.9.4 will get 100% rejects. I need to add a workaround for this bug before enabling GBT on the main port, otherwise it could be pretty painful for some users. Ah, that makes sense. The solution I've used in the past with older bugger miner versions is the check the User-Agent.  Why not keep them on separate ports :3333 for stratum seems to be the default port chosen by pools using it. Yeah, it will be GBT and getwork on the regular port and Stratum on a different one. But the GBT/getwork responses will have an HTTP header informing the miner where to find the Stratum port. BFGMiner interprets the Stratum header as "prefer Stratum over the current protocol", so IMO it would be better if it were only offered to getwork requests. |
|
|
|
All three of my miners on cgminer are complaining that bitminter isn't providing work fast enough. Stratum is coming soon, right? "Isn't providing work fast enough" (even with BFGMiner) is most likely a problem with your miner, not the protocol. Con intentionally designed GBT support in cgminer to work inefficiently, but as a side-effect of this particular inefficiency, there is no excuse it should ever be starving for more work. This isn't GBT, this is a LP. And I don't recall seeing the message anywhere else. It is starving and is sending work to backup pools. Well, why aren't you using GBT? Then you'd definitely have work ready to go as soon as the LP comes in (GBT uses LP too). |
|
|
|
|
Show Posts
