All I need is an address, so I can get some Devcoins at Bitparking pool. I'm not planning to solo-mine Devoins yet.
DeVCoin addresses are deliberately identical to BiTCoin addresses, so peopl;e can simply use a bitcoin address until some future day when they choose to export the address from a bitcoin wallet and import it into a devcoin wallet to access their coins. So you can just go ahead and use your bitcoin address for now, to have your coins safely wait for some day when you do get a devcoin wallet. This is misleading. It is impossible to import Bitcoins to the Devcoin blockchain, even if the addresses are the same... |
|
|
|
So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?
I'm getting 1% stale on EMC, and 0.1 on Ozcoin. This is the issue I've been discussing at length on this thread with Inaba. Yes it's just submitting shares below target after diff rises. That wouldn't make them stale... and EMC accepts shares at the lower target for work issued before it changed... |
|
|
|
Any chance for devcoin client win32 installer or .zip package? Is in work... By now i sugesst you an account at https://cryptostocks.com it allows you 0 fee withdrawals. Registered an account an got DVC address, but page says "Do not use these addresses for mining purposes."  Yeah, for mining you should run a real Devcoin client... |
|
|
|
next-test is a branch of the master bitcoind & Bitcoin-Qt code with as many pull requests merged as possible, to aid in testing them. This branch can be used to test many pull requests in your daily Bitcoin use. The goal is to help pull requests get the testing they need to be merged into the main tree, so once you test a change, please comment in the relevant pull request (ideally with details). Due to Coin Control's poor design and abandonment, it has begun to bitrot rapidly. This will probably be the last next-test supporting it, unless someone steps up to maintain it. Please note these might possibly corrupt your wallet. No warranty of any kind of provided. BACKUP YOUR WALLETAlso note that this is based on code that will become 0.8 including the "ultraprune" block storage rewrite. The master code does not support upgrading from older versions yet, but this next-test includes a HACKY upgrader if it detects such a condition. Note that in any case, the block chain of both your old client and this new one will be saved on your disk. That means about 5 GB for the old one and about 5 GB for the new one (unless your OS supports hard links, which the HACK will use if possible). Wallet is currently considered to be forward and backward compatible, but please still back it up!Today's next-test includes the following pull requests (green are merged now; red are disputed): |
|
|
|
So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something? cgminer isn't switching to new work right away. Here's the fix in bfgminer 2.9.3, though I'm not sure it will work as-is in cgminer without some other changes too. |
|
|
|
It has sufficient to store private keys and generate signatures. That's the important part. Where will you store the private keys? The EEPROM says not there, and I presume the SoC flash is for code... For something like this, it really makes sense to use a HD wallet. The EEPROM is an external chip. Not ideal for storing keys that are not encrypted. It's good for storing small chunks of data regarding addresses and transactions. The Chip can self write to the Flash and is as good as EEPROM other than the write time is a little longer. What's an HD Wallet? But there isn't much flash available. I suppose you could easily set aside room for a single private key (which is fine for a HD wallet). Is there a reason for using EEPROM over flash memory? Who is writing the software for this? 512 kB is probably smaller than the smallest MIPS program I can easily write (eg, standard C). A HD (hierarchial deterministic) wallet is easily the ideal design for a device like this where you only have space for a single private key. You can build multiple chains of basically unlimited addresses from just that one key. BIP 32 is the specification. |
|
|
|
A Raspberry Pi is cheaper and far more powerful.
In Raspbery Pi a closed source GPU boots and controls the CPU. It is going to be a new frontier for hacking the gullible. Score for Broadcom. It's my understanding that the GPU and bootloader were opened. Besides, this device doesn't need to use a GPU. |
|
|
|
It has sufficient to store private keys and generate signatures. That's the important part. Where will you store the private keys? The EEPROM says not there, and I presume the SoC flash is for code... For something like this, it really makes sense to use a HD wallet. |
|
|
|
|
I for one would prefer to see all this back-and-forth spent improving stratum or some new protocol.
How goes preparing the first BIP draft, slush?
|
|
|
|
|
This sounds very memory/storage constrained. A Raspberry Pi is cheaper and far more powerful. Surely there should be some way to improve?
|
|
|
|
No, it's an acknowledged problem with Stratum. The original Stratum design is flawed. Difficulty is decoupled from work and that is simply an incorrect way to handle mining. Difficulty and work are inseparable from a mining perspective. The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.
My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.
I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right. EMC's implementation will NEVER throw away valid work. So tell me which would you prefer? Shares going POOF magically on your Stratum server of choice or you getting paid for your work? Excuse me but 99.99% of the stratum code in bfgminer is from cgminer Yes, but as with other code that BFGMiner inherited from cgminer, I've fixed numerous bugs in it. |
|
|
|
Bitcoin users want stability, and they will likely object to making Bitcoin merge-mine-able since it gives no benefits, only potential problems. Bitcoin developers will do what users want. One of the many "planned" changes when the day comes that we must break compatibility, is to make Bitcoin merged-minable (though not compatible with the existing merged-mining system). But none of these changes so far has been deemed important enough by the developer group to even suggest (to users) breaking compatiblity with old clients. |
|
|
|
I have connected 8 BFL Singles. With bitminter I can mine without any problems. But if I use bfgminer, there will be only one of 8 used. Also I cant access the menu of bfgminer. any idea? running on ubuntu bfgminer -o http://pool -u user -p password Are you using the PPA, or did you build from source? If from source, did you ensure you had installed all the dependencies mentioned in README before running autogen.sh/configure? In particular, libudev-dev is needed for multiple FPGAs, and libncurses-dev is needed for the TUI (menu etc). |
|
|
|
|
Needless to say, this troll doesn't speak for me (including his falsified IRC quotes).
|
|
|
|
Do be careful though. That poison known as GBT may strike with unexpected bugs if one of your backup pools uses GBT. You mean the poison known as "conman implemented his own GBT from scratch and it's full of bugs because he never read the spec and made a lot of poor assumptions that don't hold true in practice". |
|
|
|
Abstract: getblocktemplate more wasteful than getwork
As a solo miner, I switched one of my FPGA hosts to bfgminer 2.9.3 in order to mine with getblocktemplate against bitcoind 0.7.1. This particular host has 37 FPGA devices (mixture of bfl singles, cm1's, icarus's) and I notice that bfgminer is sub-optimal: every 2-3 minutes, it does about 20-40 getblocktemplate calls in a row (1 for each FPGA device?). These 20-40 getblocktemplate calls amount to about 3-4MB total. So on average, getblocktemplate generates about 1-2 MB of network traffic per minute.
On the other hand, when mining with getwork, these 37 FPGA devices amount to about 15 Ghash/sec, so it generates about 4 getwork calls per second, or about 600 kB/minute as measured by a packet sniffer.
Bottom line, getblocktemplate as it is implemented in bfgminer causes my host to generate more network traffic than getwork (but fewer RPC calls). I haven't taken the time to read the code yet, but, Luke, isn't there something trivial to optimize to reduce the number of getblocktemplate calls?
bitcoind is not intended for use of slow networks, and doesn't even attempt to minimize traffic. It also does not currently implement long-polling (though next-test has a patch to support it), so the template needs to be refreshed regularly in case of the old one being stale. As you note, above matters with bitcoind aside, bfgminer does not implement GBT optimally at this time, since it is using code originally built around getwork; cgminer has bypassed the getwork paths for its GBT support, but also intentionally designed the GBT path to use more bandwidth (conman wants to make GBT look bad). Rewriting the pool networking code in bfgminer has been on my todo list for a while (mainly due to other problematic bugs in it), and hopefully I'll get to that before 3.0. But even without it, each template is still able to scale per device, so the problem of ASICs hashing much faster is still dealt with in practice. |
|
|
|
Been a while since I first announced Eloipool, so I'm updating the first post with new features  Most notable is support for dynamic share targetting in various modes (fractional, power-of-two (zero bit count), and bdiff rounded). Combined with GBT, this is what pools need to support ASICs. Additionally, Eloipool now supports the (pre-BIP draft) stratum mining protocol. These new features were sponsored by Inaba/EclipseMC. Also, a little background on the "loop" branch that's been sitting in the repository for a while: This branch is designed to increase Eloipool's support of the GBT protocol on the upstream side. Basically, you can run Eloipool as a "sub-pool" to any other GBT-enabled pool. As of tonight, it is up to date with the final GBT protocol specifications, and works somewhat with both Eligius and BitMinter upstreams. The main problems left to address are upstream longpolling support and properly dealing with upstreams when sending out the initial new block notifications (currently these produce and accept invalid work). If you'd like to try this branch out, create a fresh clone of Eloipool and use git checkout loop[/url] to get the loop branch.
Customize your configuration as follows:- CoinbasePrefix must be reasonably long to avoid collisions with upstream coinbase data.
- WorkQueueSizeLongpoll must be (0, 0) for now.
- It is a good idea to enable DelayLogForUpstream and use {upstreamResult} in your share log.
- Set ExpectedUpstreamLatency to a number of seconds of expected delay between your pool server and the upstream server.
I've been developing this on my own spare time. Donations, bounties, or outright hiring me to improve it is welcome. General "loop"-related donations can be sent to 14VUob11S77JmrnShEKXPWttg8s6FvW12W. |
|
|
|
Just a note that updating Eloipool within the next week or so is critical to surviving the subsidy halving.
Previous code had 50 BTC hard-coded in the "blank" coinbase. Shhh!  I predict at least some pools will have bugs and will continue to pay out as before the halving. Perhaps, but that won't be helped by pools producing invalid blocks |
|
|
|
|
Show Posts
