@tnkflx make: *** No targets specified and no makefile found. Stop. Strange..  That's almost surely a result of some error in the previous steps. Can you pastebin the output from those? |
|
|
|
I make this comment in all seriousness. That just makes you a liar. As usual. |
|
|
|
I can see how you ... now try to convince others that cgminer would not even exist if it were not for you. I never claimed anything of the sort, so you are obviously trolling. |
|
|
|
Quick question: Luke-Jr just undone changes I made in the P2Pool wiki page, saying: cgminer is pretty much deprecated at this point Why would he say that? You cut the quote off: cgminer is pretty much deprecated at this point, and the commands added here don't even work with it |
|
|
|
I don't have dialup, but still saving bandwidth is important so the new mining hardware doesn't DDOS your shiny pool by saturating the pools line. Sure, but GBT does save bandwidth. It just doesn't save as much as StratumMP, because it doesn't keep the miner in the dark. If the GBT thing has been around since February, why aren't all pools and miners already using it? Probably the main (only?) incentive for most pools is surviving when ASICs arrive. There's also the problem of Eloipool being the only (publicly available) maintained poolserver (though p2k plans to update ecoinpool when he gets time), and most pools seem to still be using pushpool or PSJ. Technically speaking, pools running older versions of Eloipool should have an older GBT available, but now that BIP 22 is final, it seemed inappropriate to list them until they are running a compatible version. |
|
|
|
About CPU resources - as usual, Luke is mixing all stuff together. GBT is quite complex specs, so:
a) You can achieve quite similar result as stratum with GBT, which is *almost* as effective on validating shares as stratum (i don't want to dig into differences for this moment), but it is *not* decentralized. No, GBT is always decentralized; while a centralized extension would be possible, there isn't one (yet?). b) You can achieve decentralization, by leave tx selection and block creation to the miners, but then validating of shares became real hell on the pool side and bandwidth usage and I'm almost sure that no major pool is going to support *this* possibility, because it's insanely difficult to validate everything properly. There are other easier ways to cheat the pool out of blocks than including phony transactions, so if your pool is really so strained you could simply skip validating them. The only risk is a miner who is accidentally making invalid blocks - that can likely be countered by doing a full check only occasionally. Bandwidth use is mostly unchanged, if you use workids (or similar) to cache the templates being mined. b) We (at least me and other pool ops and miners) want some very optimized protocol which will minimize usage of all resources to minimum. This was missing until now, but with Stratum it is DONE. Hindsight is always better, but... it would have been nice if you had worked with us and brought up your concerns sometime between February and July so GBT could have taken them into consideratoin. It's a shame to need two totally unrelated protocols for almost identical use cases. I also don't see why miner software authors (whose development is mostly made up of donations) should be expected to have to deal with it simply because a few big pools (with fees and income) demand yet even more savings on top of what GBT already gets them. It makes sense for some individual miners (who run their rigs off cellular modems or something?) might need to reduce bandwidth, but there's no reason they couldn't run a private proxy that does a Stratum-like centralization on their own non-limited connection somewhere. I'm not here to say that everybody HAVE TO mine on centralized pool. I just give a possibility to do centralized mining as easy as possible, replacing current non-optimized, but widely supported getwork on the pools. Why not to have such option? Option implies miners have a choice to mine decentralized on your pool. Are you saying that will be possible? Actually decentralization was a problem in times when only my pool and maybe deepbit were available. Now with tens of pools it ends up with *almost* decentralized network, which is still very effective (or can be, after replacing getwork to any better solution). "Almost" decentralized network only protects against 51% attacks (and then, only if the few people making up 51% aren't compromised); there are other attacks that can be done with less. ...my bfl asic... Looks like you care about decentralized mining, but don't care about centralized manufacturing of miners, which is much bigger risk for bitcoin network  <sarcasm/> I'm sure you're aware since you noted sarcasm, but just to clarify explicitly: there is no risk at all to the Bitcoin network from "centralized" manufacturing provided the distribution/use is indiscriminate (which BFL has promised, although other ASIC vendor(s) aren't so Bitcoin-friendly apparently). |
|
|
|
|
Looks like I accidentally built 2.8.0 using some AVX instructions, so it crashes in some cases on older (pre-Sandy Bridge) CPUs.
I've rebuilt it as 2.8.0-1 and updated the download links on the main post.
|
|
|
|
b) Validating custom-built PoW on pool side is *insanely* difficult, from the view of CPU resources. b) yes its more load on the server. but how much more? maybe luke-jr should eloberate on this. It's not been a problem, nor does it use any more CPU resources than StratumMP would to do the same thing (limiting changes to just a fixed-size extranonce does not improve the situation). |
|
|
|
Hey guys,
Just received my Quad XC6SLX150 Board. How should I do for setup it with my GPU and BLF single(x1) Linux minning rig? I use cgminer 2.7.5 and have no idea what's the next step after connected Quad XC6SLX150 to the minning rig. Most appreciate for any help!
https://en.bitcoin.it/wiki/CM1QuickstartRecommend upgrading to BFGMiner 2.8.0 tho |
|
|
|
The stratum approach is working right now with the current installed based of miners. Just point to the proxy intermediary the 'stratum proxy', simple. Been testing this on a miner I have with BTCGuilds stratum test and it's doing great. GBT has been working with a proxy since February, and is easily added to existing miners. |
|
|
|
...and the stales rates... FWIW, after 3+ days of use, I can safely say the stale rate is not significantly higher using GBT. ...And if miner is suspicious about poolop activity, he can just switch the pool to another.
I mean - there's no reason to make mining protocol less effective (from any point of view, including CPU resources and used bandwidth, and more difficult implementation in the miners) just because decentralization itself. Market of mining pools is great example of free market and miners can achieve the same level of "decentralization" just by switching to the pool which fits their needs.
Except miners can't viably choose to switch when they are deprived of the information needed to know when to act. |
|
|
|
bfgminer version 2.8.0 - Started: [2012-09-18 08:24:01] - [ 0 days 00:21:36]
--------------------------------------------------------------------------------
5s:559.2 avg:795.6 u:258.4 Mh/s | A:78 R:0 HW:0 E:229% U:3.6/m
TQ: 0 ST: 3 SS: 0 DW: 0 NB: 1 GW: 34 LW: 744 GF: 0 RF: 0
Connected to http://x.x.x.x:8777 with LP as user x
Block: 00000040412b763328116fea4b69a1f3... Started: [08:24:01]
--------------------------------------------------------------------------------
[P]ool management Settings Display options Quit
ECM 0: | 399.1/398.4/ 59.6Mh/s | A:18 R:0 HW:0 U:0.83/m
ECM 1: | 399.0/397.2/198.7Mh/s | A:60 R:0 HW:0 U:2.78/m
-------------------------------------------------------------------------------- This probably isn't specifically related to the cairnsmore.. but what is the 'u:' field here? Any idea as to why it's so low? The speed at the mining pool is currently showing as around 250Mh too. Utility hashrate: your mining speed calculated from shares accepted, for the entire runtime and across all pools. In other words, while your Cairnsmore is reporting* 795 Mh/s on average, it's only finding 258 Mh/s worth of shares. That could be due to a number of factors, including (but not only) both clocking too high and/or poor luck. As you only have 78 shares accepted in this case, I'd suspect it's probably luck unless it keeps up for a long while. If your pool uses higher difficulty shares, it will take even longer to average out. |
|
|
|
So, anyone actually got any coiledcoins left?
Luke-Jr, how about you? Presumably you racked up quite a few of them during your attack?
Since dirt cheap cryptocurrencies are really fun for gamers to have fun with, players are interested in how much these things go for nowadays...
-MarkM- Testnet works. |
|
|
|
StratumMP work payloads increase 67 bytes per power of 2 transactions. GBT work payloads increase by the size of the transactions being included in a block (roughly 250 bytes for a normal tx with 1 input, 1 payout address, and 1 change address). Yes, I forgot the exponential factor involved here. However, with a local bitcoind, GBT can shrink far smaller than StratumMP. If bandwidth is a real practical concern for BTCGuild (or anyone else), someone (possibly me, if someone needs and plans to use it) could easily write a "Centralized Mining" extension for GBT providing the same bandwidth savings. Of course, keep in mind that GBT is already going to use far less bandwidth than getwork, so this really shouldn't be a problem. Remember that centralized mining moves the miner's authority blindly to the pool operator, and thus creates a greater risk to the Bitcoin network. Health of the Bitcoin network is IMO far more important than saving a few KB of bandwidth here and there. So... as long as there isn't a practical problem involved, it would seem a shame to keep centralized mining going unnecessarily. The biggest hurdle on implementing StratumMP is changing from constant HTTP connections and inefficient longpolling, to a static TCP connection. Beyond that change, StratumMP is a simpler protocol to work with and implement. Yes, the biggest hurdle is rewriting all the miner code actually relevant to the protocol at all. GBT is more full featured, but your arguments imply that most mining software wouldn't bother implementing the full feature set to begin with. Hopefully mining software will grow closer to full-featured over time. It's pretty important that mining become decentralized, at least. |
|
|
|
it's a linux embedded system. which is running cgminer or something like that. FWIW, BFGMiner already supports the standard ASIC-ready getblocktemplate mining protocol. |
|
|
|
it'd just far require more bandwidth and every piece of mining software would need code to parse and serialize Bitcoin transactions and blocks and to implement a whole bunch of different cases. This isn't correct. Plus, I suspect most mining software would end up requiring a different subset of the GBT protocol than the one bitcoind supports This isn't a problem. |
|
|
|
I've mostly finished a more friendly writeup on getblocktemplate on the Bitcoin Wiki, covering (almost?) everything StratumMP's page covered. Take a look and let me know what you think, or how it might be improved! Feel free to edit it directly too, of course |
|
|
|
Now that 0.7.0 is tested and out the door, please help test some of the stable maintenance versions 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. Also note that CVE-2012-4682 and CVE-2012-4683 are not fixed in 0.4.8: 0.4.x did not have any anti-DoS system at all, and that is not changed with this release. If you want to be secure against this class of DoS attacks (network flooding of invalid data to verify), upgrade to a newer version! bitcoind and Bitcoin-Qt version 0.6.4 release candidate 3 ( sigs) are now available for download at: bitcoind and Bitcoin-Qt version 0.6.0.10 release candidate 3 ( sigs) are now available for download at: bitcoind and Bitcoin-Qt version 0.5.7 release candidate 3 ( sigs) are now available for download at: bitcoind version 0.4.8 release candidate 3 ( sigs) is now available for download at: PROTOCOL UPDATES- BIP 34: Block height in coinbase as a new block rule (includes minimal adaptations to getmemorypool in 0.5+)
- Support for sending to script (P2SH) addresses (BIP 13 + BIP 16)
BUG FIXES- Fix DoS vulnerabilities in alert system (CVE-2012-4682 and CVE-2012-4683; (0.5+ only).
- Do not consider inbound peers for outbound network group exclusion.
- Apply BIP 30 checks to all blocks except the two historic violations.
- Special-case the last alert to protect against the alert key ever being compromised.
- Bitcoin-Qt: Ensure changes to preferred Bitcoin unit is immediately reflected in the GUI.
- Bitcoin-Qt: Make sort and filters for transactions and labels case-insensitive.
- Bitcoin-Qt: Override progress bar on platforms with segmented progress bars.
- Bitcoin-Qt: Updated all translations from Transifex.
- Fixed numerous typos and grammatical errors.
- Resized the address book page to fix issue #1062 (0.6.0.10 and 0.6.4).
- bitcoind: Fix building on MingW/OSX with USE_UPNP=- option (0.5+).
- Fix build version generation failure when compiling on Windows (0.6.4).
- Various other minor bug fixes, including test suite fixes and workaround for distcc build problems.
Thanks to everybody who contributed code or helped test this release: Luke Dashjr Sergio Lerner Gavin Andresen Philip Kaufmann fanquake xanatos Wladimir J. van der Laan Gregory Maxwell Matt Corallo Ricardo M. Correia Michael Ford Jeff Garzik Pieter Wuille Rune K. Svendsen Stephane Glondu |
|
|
|
|
Show Posts
