I noticed nothing in a scan of the README (though I was looking for 'arm' and not 'mips' which was a mistake since I've not done this kinds of stuff in a while) and noticed no assembly for anything but x86's. But it is not unheard of for people to optimize for an architecture with assembly while supporting other architectures with compiled code. And also common to build a sub-set of functionality on less well supported architectures. That's why I said 'or at least not fully. Assembly is only used (optionally) for CPU mining, though that does support both x86 (SSE) and PowerPC (Altivec). CPU mining is mostly pointless, though, so I wouldn't consider other platforms really "less" supported. But, since you are here, is it known that the code should work on his platform, or is he blazing trails in trying to get it going? I know a number of users have had success on Raspberry Pi, at least. |
|
|
|
My vote is for the Thai Baht. It's clean, elegant and standard.
This isn't a vote; B⃦ has been the standard symbol since the beginning, and there is no good reason to change that. This is just Atlas trying to turn Bitcoin into mere "Silk Road currency". |
|
|
|
Luke-Jr keeps changing it to some weird Russian symbol nobody uses on Wikipedia. It probably shows up as the Baht for him or something. Um, no, I changed it to the symbol every major Bitcoin website uses - including bitcoin.org, bitcoincharts, and these forums - at least in their favicon: B⃦ This is the standard Unicode symbol used for the B with double vertical strokes.  The forum has BTC using some CSS (embedded fonts) to workaround the fact that major fonts don't render it as nice, but it is the same symbol. Anyways, we generally use the Thai Baht for Bitcoins, right?
฿ <- that right there You must be confusing Bitcoin with Silk Road. |
|
|
|
First though I would also suggest that you verify that the software you are trying to build has a hope of compiling under ARM else you might end up spending a lot of time on something which will be very difficult to achieve. It is not at all uncommon for source code to need significant porting to run on different architectures (i.e., ARM vs. x86) and it not to have been done. A cursory glance at the project indicates to me that it probably does not, or at least not fully. What makes you think that? ARM isn't all that different from x86, and I've put some effort into ensuring it's portable even to big-endian architectures like MIPS. |
|
|
|
Sorry but don't understand, wrong software? measures are differents if bfgminer is used with GPU or FPGA? Kano is a troll, just ignore him. I've noticed the change of bfg by cow. Huh? |
|
|
|
|
Not having all the blocks? run: bitcoind getblocktemplate
|
|
|
|
How do i do that, i downloaded the dependencies including the python-bitcoinjsonrpc, its currently in the opt folder together with the eloipool folder.
What is to then?
Symlink the directory with authproxy.py as eloipool/jsonrpc |
|
|
|
Per the README, you need python-bitcoinrpc ( not jsonrpc) |
|
|
|
Any plan for Stratum mining ? The pool already supports the standard GBT protocol. There's no need for Stratum, which just does basically the same thing (except in a way that is more harmful to Bitcoin), despite a couple of big pools throwing around their weight on it. |
|
|
|
The certificate program is a very good idea. Thinking otherwise is just stupid. Bitcoin block chain can be used in many different ways in just 2-3 years that are hard to imagine right now. Why limit bitcoin protocol to medium of exchange or measure of value? Certification is enemy of innovation! Who said certification would restrict innovation? There's no current known legitimate reason for non-monetary data in the blockchain, but I'm sure if someone came up with one and followed the proper standardization procedures it wouldn't be a problem for certification. |
|
|
|
Our Goals for 2013
...
Create an opt-in certification process for Bitcoin businesses should be removed from your goals at all! Certification is a bad idea and doesn't correspond to bitcoin spirit. Many of the problems with Bitcoin today are due to poor security practices and misunderstandings about Bitcoin. Certification allows people to see a "Bitcoin Foundation Security Certified" logo and rest assured that the site has a reasonable chance of not losing all their bitcoins. |
|
|
|
Prevention of double voting can be accomplished using name ID only. It is perfectly legal in some States, including every member of the United States (per US Constitution), to have multiple legal names, and in some cases multiple IDs for each of those. Using an address to overcome this, however, may not be the best solution, since many people have multiple homes. |
|
|
|
I wouldn't care about it either. If one is implementing Stratum in the first place, including difficulty in each job really doesn't help any. Does that indicate you won't be copying ("merging") ckolivas' stratum code into your spork? or Will you'll be developing your own code or waiting for someone else to copy ("merge") from? I was responding to Kano's request to change the Stratum protocol in a stupid way because of some implementation problem he imagines exists. As I said before, if someone else writes the code, I will (probably - ie, if the code is reasonable) merge it into BFGMiner. Con is capable of producing reasonable code, so I expect that when he finishes it, I will accept it into BFGMiner. It will be interesting to see how you alter his code when you copy it into your cgmerge branch to suit your needs. I agree. |
|
|
|
I wouldn't care about it either. If one is implementing Stratum in the first place, including difficulty in each job really doesn't help any. Does that indicate you won't be copying ("merging") ckolivas' stratum code into your spork? or Will you'll be developing your own code or waiting for someone else to copy ("merge") from? I was responding to Kano's request to change the Stratum protocol in a stupid way because of some implementation problem he imagines exists. As I said before, if someone else writes the code, I will (probably - ie, if the code is reasonable) merge it into BFGMiner. Con is capable of producing reasonable code, so I expect that when he finishes it, I will accept it into BFGMiner. |
|
|
|
Any update on the #112 Event system ticket? It was meant for 2.9.0 if i read it correctly  Perhaps I should change the milestone labels I use Right now, anything that's a bugfix or trivial is milestone'd for 2.8.2, any minor enhancements are 2.9.0, and major stuff is 3.0.0. When I get to releasing 2.8.2, I'll then move anything that didn't make it to a new 2.8.3 milestone, etc. |
|
|
|
|
I wouldn't care about it either. If one is implementing Stratum in the first place, including difficulty in each job really doesn't help any.
|
|
|
|
midstatemodule.c:5:20: error: Python.h: Datei oder Verzeichnis nicht gefunden Looks like it can't find Python.h. It's probably under /usr/local/... ? Maybe edit the Makefile as needed :/ |
|
|
|
Isn't there a way to just "pause" the GPU mining and still mining with the FPGA's so we don't have to close BFGMiner and restart it with only FPGA's?
You can do that from the GPU menu as well... Thanx! Is there a way for BFGMiner to do all the queued work (and not pulling more work) and then quit when done? Not right now... open an Issue with a use case if this is important to you It's not important to me, but maybe to pool operators that are maybe waiting (I dunno for how long till it sends the work to another miner) for the queued work while the miner is using the gpu for gaming or other stuff. I don't think any pools have any expectation that all work issued will be used... |
|
|
|
Isn't there a way to just "pause" the GPU mining and still mining with the FPGA's so we don't have to close BFGMiner and restart it with only FPGA's?
You can do that from the GPU menu as well... Thanx! Is there a way for BFGMiner to do all the queued work (and not pulling more work) and then quit when done? Not right now... open an Issue with a use case if this is important to you |
|
|
|
|
Show Posts
