DiabloMiner users please read this post on the Eligius forum. Run the new DiabloMiner with Eligius for 3 hours, From DiabloMiner: mhash: 87.9/87.2 | accept: 223 | reject: 12 From Artefact2's graph: | 3 hour average | 15 minute average | | Hashrate | 85.10 MH/s | 62.04 MH/s | | Submitted valid shares | 214 | 13 | | Submitted 'stale' shares | 9 | 2 | | Submitted 'unknown work' shares | 3 | 0 | | Total submitted invalid shares | 12 (5.31 %) | 2 (13.33 %) |
Setup: Radeon HD 6570 + Ubuntu Natty 11.04 + Catalyst 11.9 + AMD APP SDK 2.5 DiabloMiner commit: ec9e6640dbc83711b10a78881c6db1bd08debaf1 DiabloMiner options: -v 2 -w 128 -f 15 What were your results with the older version? What ping do you have to the pool? |
|
|
|
When you see "l", how do you choose whether to change it to "L" or "1" and why? It always uses "1", because "l" looks like "1", not "L". I'm assuming the error is in reading it off some print. When you see "O", how do you choose whether to change it to "0" or "o" and why? "0" is not valid. Both "O" and "0" are interpreted as "o". |
|
|
|
Link to coinbaser pull requestMy coinbaser branch adds a "setworkaux" method to allow miners to add arbitrary coinbase data to their blocks. This is mainly useful to implement merged mining (mining for both bitcoins and namecoins concurrently), but could also be used for miner voting in the future. As with any JSON-RPC change, adding this requires some kind of consensus. Please vote in support.  This is a backward compatible change. Unrelated to this poll: In addition to "setworkaux", coinbaser also adds (non-Windows only!) a "-coinbaser=<cmd>" command line option to specify a command to execute during "getwork" calls; the command may output data specifying where to assign the generated coins (this is how I do generated payouts on Eligius). It also adds a minor internal restructure of coinbase-creation code, which can be used to more easily implement automatic feature upgrades (OP_EVAL, for example) by miner adoption. These changes are also backward-compatible, and provide useful functionality.
|
|
|
|
Link to pull requestThis patch disables automatically adding "minimum" fees for JSON-RPC methods-- instead, it returns an error (stating how much fee is "required") or, iff the user sets the new second parameter "force" to the 'settxfee' JSON-RPC method, sends the transaction with the user-specified fee. There are two ways to use this: - Read the error, optionally prompt your user to approve the fee, and use "settxfee" to retry the send with the fee.
- Use "settxfee" with the "force" option to send it with a lower fee than "required", because you know a miner who will accept it.
This only affects JSON-RPC users, who should be assumed to understand the risk of sending with insufficient fees.
|
|
|
|
If the correction function only results in the replacement of an invalid character with the corresponding valid character then the problem is not relevant. This is correct. |
|
|
|
Link to pull requestThese changes are 100% backward compatible. Adds to "getinfo" output: "pooledtx" (number of transactions in memory pool), "currentblocktx" (number of txns in the last block created), and "currentblocksize" Adds to "listtransactions" and similar output: "block_hash" and "block_index"
|
|
|
|
Per the old bitcoin: URI scheme, amounts should specify a unit. The current implementation of bitcoin-qt, however, only correctly handles amounts as BTC without a unit. What would be the ideal behaviour, in the community consensus, when encountering a URI that does specify a unit? (recall that the user opening these URIs is not the same person who created them) Example URIs with units: |
|
|
|
I voted no but send people a warning. If you've ever used an iphone you'd understand how retarded autocorrect is.  That doesn't apply here. If the correction is wrong, it still won't work. That's what the checksum is for. |
|
|
|
Please take a moment to help get the changes mainlined: |
|
|
|
One of my pull requests for bitcoin{d,-qt} makes it tolerate typo'd base58 data-- specifically, zero and uppercase 'o' are treated as a lowercase 'o'; and lowercase 'L', pipe, and exclamation point are treated as a one. Gavin thinks such a change needs a consensus, so please vote. Edit: Please note: this would only tolerate typos when it is certain to be correct. It does not make guesses that could be wrong. There is a checksum to prevent that.
|
|
|
|
Any block chain fork should be avoided as long as feasibly possible. When it happens, we should have a large list of housekeeping changes to make at once.
Is anyone maintaining a branch with these sort of housekeeping changes? A block chain fork may be years in the future, but it might be worth maintaining such a branch to keep such long-term changes in mind. I was thinking that would be a good idea. I can help, but I don't think I have time to maintain such a branch by myself. |
|
|
|
DiabloMiner users please read this post on the Eligius forum. |
|
|
|
It's not dishonest, just imprecise.
You should post this in your FAQ. Many people are wondering whats wrong with your clock. If you happen to live in a country with an adversarial legal system, you will be invited to the court to explain this to the judge and the jury why the timestamps on your blocks are messing up the accounting ledgers of other people. Anyone using block times for anything important is quite simply a fool. It's not meant to be precise, and never will be. Even if I didn't (ab)use it for improved efficiency, it would be the time that (many) miners began work on the block, not the time it was found. And even if it were precise, it has no relevance. |
|
|
|
I did some simulation of blocktime variance (assuming honest nodes,
It is my understanding that at least Eligius pool isn't a "honest node" and intentionally produces acausal blocks (or at least as close to acausal as they deem practical). Eligius varies ntime to optimize getting work out to miners at a longpoll. Otherwise it could take many more seconds to generate work for all of them. It's not dishonest, just imprecise. The current variation allowances are not a problem, either. Any change to how difficulty is calculated means a block chain fork. Any block chain fork should be avoided as long as feasibly possible. When it happens, we should have a large list of housekeeping changes to make at once. |
|
|
|
Enable 0.5% donation by default. I plan on maintaining a patch to remove all of the donation code from the project starting in the near future. I think people who want to donate (such as myself) are capable of choosing to on their own through the normal channels. Don't forget to not use any pools that have a % donation option ... I think that leaves only Eligius, though when I get around to rewriting the codebase, I do plan to offer it as an option... |
|
|
|
I just installed 2.0.5 from git, running smoothly as always.
I guess that I will start the features-for-donations requests:
1) The ability to pause/unpause mining. Ideally this would be easily done by another program (without sending keystrokes). I am thinking perhaps a SIGINT or SIGCONT could stop and start mining respectively.
I recently switched to hourly based electricity pricing and plan on evaluating the feasibility of mining every hour. That is what inspires this request to be able to pause mining during peak electricity demand.
Thoughts?
SIGSTOP/SIGCONT don't work? |
|
|
|
I would not make donation mandatory. The intent would be for --donate 0 to be no donation. Human nature tends to accept defaults, and if I set zero by default, I'd say no one will donate. On the other hand, I don't like forcing people to donate by making the default on. So I'm torn on this issue too.
people also don't like upgrading and finding out they're donating because they didn't read the forum and have to add extra shit to the command line So he can put a UI element "Thanks for your N% donation" (or "Please donate  " if disabled) somewhere, and do his % last (ie, if donating 0.5%, do his work after 199 of theirs). |
|
|
|
|
I agree there are optimizations that could be made by reusing the getwork HTTP connection for subsequent share submissions, but it is also a server bug if it can't handle clients changing to another IP on the same DNS entry. There are header-based getwork extensions to allow pools to control where future getworks go (either failover or "please change to this server _now_") that CGminer might (or might not) implement.
|
|
|
|
|
Show Posts
