Is there any support for the x6500 with cgminer? I know bfgminer has it but I really prefer cgminer. Why do you prefer cgminer? |
|
|
|
Any estimate for the shares price once the mining starts?
Since all* the shares are owned, that really depends on what price people are willing to sell them to you at... |
|
|
|
Wait, so you're saying that a single entity controlling a large amount of hashrate is better for Bitcoin than many individuals receiving units and having that large amount of ASIC hashpower distributed across many people?
Huh?
It is for ASICMINER shareholders  Not if it brings the value of Bitcoin down so our dividends are worthless... I, too, have not received an email regarding my shares of ASICMINER. |
|
|
|
NEW VERSION 2.10.2, DECEMBER 27 2012- The current block target diff is now shown in the status line like so:
Block: 00000599115b83cd... Diff:2.98M Started: [11:15:11] Best share: 7.73k
I noticed on many occassions that network next diff is shown 1 block before anywhere else, including blockchain explorers. On one occassion, correct next difficulty was shown over 5 minutes in advance! Magic or what? Those "anywhere else" are probably showing the difficulty of the last found block, while BFGMiner is showing the difficulty of the block you're trying to find now. |
|
|
|
Well, GZ guys.
At the same time, I must admit, IMO bitcoin developers (Gavin and CO) should have forced a hard fork with a new alg, not allowing ASIC taking over BTC. Right now, it seems, 51% of hashing power will be in short time in the hands of few individuals which will mine for themselves. I bet this wasn't the original idea behind BTC..
Well since it is possible some people would eventually do it for any alog. IMO this is the best scenario for it to actually happen. Several groups working on their own designs and a community willing to buy such hardware to decentralize as much as possible and secure the network. The first horse advantage? Now how would you prevent that in any scenario? Just be glad the first horse is not planning on shitting all over us!  Algorithm change and fork. As I said, it seems to me, BTC creator thought it as a decentralized currency to be hashed on peoples around the world computers. We are now in worst case scenario, with one very small group able to control more than 51% of hashing power. Ofc, nothing can be done now and we should congrats the guys which put so much effort and won this race. But again, I cant stop noticing where BTC started and where it ended today.. With consumer-available ASICs literally right around the corner, hopefully this concern will go away as quick as Deepbit's majority did. Changing the algorithm would only make sense IMO if it was a long-term risk. There is no need to fork anything. There already exists an ASIC resilient altchain that is almost identical to Bitcoin except for the algorithm: Litecoin. While there might be real (short-term) concerns posed by this, it's no excuse to scam. Litecoin is not ASIC-resilient. The only reason scrypt ASICs don't exist is because there's no value in it. If Litecoin were to ever become of significant value, it would be just as simple to make a scrypt ASIC - and unlike with Bitcoin's SHA256d, a scrypt-based PoW would be taken over completely by it. |
|
|
|
Looks like I made the right choice in which miner to support... socat stdio tcp-connect:127.0.0.1:4028 <<<'pgaset|0,clock,210' Luke, I see this as a commandstring, but I have no idea what to use to send that command, as I've said. Should I just open a terminal? I doubt windows has socat and stdio, but I can connect over the network with my mac. Will this persist on restart, or would I need to resend the command? If I do need to re-send it, why can't this be a persistent change with the config file? After playing all day with the RPC API, I don't see it being much more beneficial than teamviewer and the terminal interface. Thanks for the help over the months I've been using your software. Much appreciated, I've never had a problem with you refusing to help. Thanks. Yeah, socat is a Linux CLI tool... A quick Google suggested there was no native Windows port, and I have no idea if it works on Mac. However, a similar netcat command should work, and maybe even telnet. nc localhost 4028 <<<'pgaset|0,clock,210' |
|
|
|
kano: I understand you wrote the RPC API. The API-Readme is quite confusing, how is one to execute the commands listed? there are some example files referenced in the documentation, but they aren't supplied(api-example.php, etc). I think I understand how to format a command, but how to send that command to the software escapes me. I want to be able to use the pgaset command for my MMQ(I hate having it start at 200mhz when I know each chip will easily do 215. Starting at 210 each time would save a lot of waiting for it to clock up) socat stdio tcp-connect:127.0.0.1:4028 <<<'pgaset|0,clock,210' |
|
|
|
|
I guess this build is getting stale by now, so maybe I should make an updated next-test sometime soon.
I've had enough problems with the latest master code that I went back to the 2012-09 next-test myself...
|
|
|
|
i hate ppl who do lie It's not healthy to hate yourself. BTW, I don't lie. |
|
|
|
TL;DR: intentional lieing and stealing isnt nice and drives honest ppl mad after some time. So why are you spreading all these lies? Trying to earn a place on the troll top 10? |
|
|
|
Which has been extensively rewritten coz it was coded so badly and got unnecessary rejects ... that you have since copied a lot of that code to your clone miner (that you also stole the name of from me) Which is a bit worrying because Luke and THESEVEN have been chosen to work on the bASIC software, as experts in their field....... Don't mind kanoi, he is a liar as usual. |
|
|
|
The next halving is in a little under 4 years, right? Isn't that plenty of time to figure this out?  Yes, I was just explaining the background behind "transaction fees are required" (in the long term). In theory, we should have some time left with free-of-charge transactions. In practice, DoS attacks like SatoshiDice (which don't help Bitcoin adoption) are abusing the network and current fee rules to crowd out more legitimate transactions (which makes Bitcoin adoption more difficult, since now people need fees before we've reached critical mass). |
|
|
|
Where can I locate the function in one of the old miners source code to add interface to fpga processing? Or which mining software is the easiest to use as reference design (learning purposes)?
BFGMiner's device API is pretty straightforward. u mean cgminer's lol Yes, cgminer also uses the device API that I created for BFGMiner - though an older version. is there proof that you did this API and not ckolvias? and a4d1fe1e are the original commits (in cgminer's repository) which took the GPU mining code (and unconnected CPU mining code), and replaced it with a mining device framework. A few days later, I had the first working FPGA driver for the new device API. ckolivas merged all of these into cgminer, so I had no need to release BFGMiner separately at the time, but he had nothing to do with the FPGA code until he forked it. |
|
|
|
Where can I locate the function in one of the old miners source code to add interface to fpga processing? Or which mining software is the easiest to use as reference design (learning purposes)?
BFGMiner's device API is pretty straightforward. u mean cgminer's lol Yes, cgminer also uses the device API that I created for BFGMiner - though an older version. |
|
|
|
It's hard to give a real world example, but you'll have a very hard time ever sending 13 BTC with 325 different inputs. In that kind of situation, you'd be better off sending your inputs into a separate wallet with larger chunks (keeping the transactions small while doing so). Do that a few times, then wait for those to mature, then use those to make even larger chunks (keeping transaction size small while doing so) again once they've matured enough to not require a fee. Note: This will not work if your initial inputs aren't big/old enough to avoid transaction fees. Each 0.04 input would have to be 25 days (I think) old prior to being merged.
The "bag of pennies" scenario is a significant problem for small miners on p2pool. Not so bad for larger ones. But the larger p2pool becomes, the worse this problem is. It's a hidden fee for using p2pool. You get your money faster than some pools, though there are many pools that don't require waiting for blocks to mature (or PPS where you don't even have to wait for a block). However, the larger p2pool becomes, the more frequently you'll be forced to pay txfees when spending coins.
p2pool's concept is great, but the payment method and share chain prevent it from becoming a major "pool". Unless it gets turned into a series of supernodes which people mine through, which would end up being worse than the current pool system due to high stale rates using a remote node that has longpolls every 10 seconds.
Hmm. If transaction fees are required, why does the client default to not providing any? I know more than once I've accidentally sent a payment, all from p2pool, without a transaction fee because that setting wasn't on. Never had a problem with them going through quickly or getting confirmations either. Not that I'm advocating sending transactions without fees, just stating they aren't as required as people make them out to be. They're optional right now because blocks have subsidies; Bitcoin also benefits from being the cheapest way to spend money online, which encourages its adoption and drives the market price upward (which is beneficial to the miners of course too). As designed, Bitcoin block subsidies will eventually drop below the break-even point for miners, at which point mining will be dependent on the transaction fees more immediately - though the longer we can afford to provide confirmations without a fee, the more likely Bitcoin's successful adoption is. |
|
|
|
With bitcoin 0.8, it'll be even more important (bitcoin nodes can download only a list of unspent tx, which reduces the blockchain size to something like 200MB). This is not a planned feature of 0.8. While it will only use an unspent tx database, it still needs to download (and at present, store) the full blockchain. Just FYI. |
|
|
|
Well, bummer, system rebooted even with bfgminer 2.10.2 after 9 hours of uptime  Is it possible your Pi isn't getting enough power itself? An ordinary USB charger won't have enough, it has to be able to provide 1A (on the one port, not across all N ports). |
|
|
|
Where can I locate the function in one of the old miners source code to add interface to fpga processing? Or which mining software is the easiest to use as reference design (learning purposes)?
BFGMiner's device API is pretty straightforward. |
|
|
|
Luke do you think that the fact that I have both Icarus and Bitforce miners is somehow relevant? It shouldn't be, but I can try it I guess... Only have 1 Icarus though - what's your environment like? 4 Icarus boards and 3 BFL singles. All connected to a 10 port USB (powered) hub. USB Hub is one of those generic ones you find everywhere - got it off of ebay: http://i.ebayimg.com/00/s/NjAwWDYwMA==/$(KGrHqN,!h0FBI9ToPqkBQVurqwerg~~60_3.JPG My own experience with USB hubs has been that 99% of them are crap, and the remaining 1% cannot be uniquely identified before plugging them in. I'm running bfgminer with the following argument (all pretty standard from what I'm aware):
bfgminer -c /home/btc/cgminer.conf -S /dev/ttyUSB0 -S /dev/ttyUSB1 -S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB4 -S /dev/ttyUSB5 -S /dev/ttyUSB6 If you build bfgminer with libudev support (install libudev-dev and re-run configure), you can drop all the -S options and let it autodetect. Could you also try cgminer 2.10.4 to see if you get any Comm errors from one of your Bitforce singles? That definitely happens for me with the latest cgminer build - the whole reason that caused me to look for an alternative to see if the same thing happens (ie to bfgminer). cgminer's Bitforce driver is based on bfgminer's, except they've added a bunch of bugs. I could try it next, but as long as bfgminer works, I don't see a point... Surprisingly bfgminer 2.10.2 has been running for 8 hours now without any issues. Lol maybe I should just leave it alone. Still I'm really curious to at least know with a reasonable amount of certainty what was causing these instability issues for me. If 2.10.2 proves stable (give it a few days, just to be sure?), you could easily debug the problem further using git bisect in reverse: you tell it the known-working version is "bad", the known-problematic version is "good", and it will give you a series of commits between the bad and good ones (it's smart about minimizing how many of these) to test and report back on (remember to invert the bad/good, since bisect was designed for looking for regressions, not fixes); you'd also need to be careful to run autogen for each commit and note whether it builds bfgminer or cgminer. Eventually, bisect will tell you which commit fixed your problem. Hmm, if you say there are bugs in cgminer's bitforce driver that could explain the comm errors me and the OP have been getting. However 2.9.4 causing a system reboot (or causing a system even like large cpu load or something that is causing this mining distro's watchdog daemon to reboot the system) is bizzare. I would be nice if someone else can verify my experience. Perhaps the OP will give 2.9.4 a try and see if the same thing happens for him. Numerous fixes have been added to 2.9.x between 2.9.4 and 2.9.7, so I would focus on the latter (if not 2.10.x). In my experience, usually watchdog resets triggered by software are caused by excessive swapping - which would suggest a memory leak. I do test for memory leaks most releases, but it's possible 2.9.4 was one of the times I forgot to check before releasing. |
|
|
|
|
Show Posts
