|
It most likely means the pool's clock is wrong. Setup ntpd.
|
|
|
|
Invalid block on eu?
Yeah, that sucks. At least it was the 2nd today... |
|
|
|
|
This subforum further propagates the "one true client" myth/control-method. If the Development forum is too cluttered (which I'd agree it is), it should be split among the different projects equally, not by giving preference to one over all the others. The current split also doesn't help the clutter at all, as the new subforum has a tiny minority of all the threads. I also think it would be a good idea to add subforums for all the mining pools (which don't have their own). Currently, most "alternative" clients and pools have a single very-long thread, due to the cluttering of the forums. Giving them each a subforum I expect would yield a proper thread per topic/issue.
|
|
|
|
This is missing too many options to be worthwhile. If the common unit is to be changed, UBC is ideal, not μBTC. Thanks again for posting this chart that will make 99% of non programmers click x immediately  ) If someone would have to come up with a system to slow down the general acceptance of BTC, "UBC" would come really close  You have dozens of totally new terms, you have terms for random numbers that only make mathematically sense and are horrible to grasp for non programmers. If bitcoin wants to move beyond "nerdsphere" UBC is certainly a disaster choice. Most non-programmers will only ever see the cyan SI units and the base unit, and will naturally figure out the other white binary divisions of it. They don't need to know how many Satoshis there are in a UBC. |
|
|
|
This is missing too many options to be worthwhile. If the common unit is to be changed, UBC is ideal, not μBTC. |
|
|
|
A real "UBC" has existed since March: https://en.bitcoin.it/wiki/Universal_BitcoinIf an actual new unit is desired, this UBC would make more sense. But if people just want to "move" the decimal point, μBTC already exists. Since it remains decimal-specific, the obvious three-letter code would be DBC (Decimal Bitcoin). |
|
|
|
How often do you have to update the timestamp [and reset your nonce iteration]? Is it every second, such as the above implies, or are the timestamp tolerances broader than that? It's complicated, but sticking to the current time is usually a safe bet. |
|
|
|
Why has my payout been withheld?
"Unpaid reward : 1.82903769 BTC
This is the reward you earned by contributing to the previous blocks. This amount will be paid to you when it reaches 1 BTC or after one week of inactivity, when the pool finds a block." Sometimes, the miners earning less than 1 BTC reach their minimum payout at the same time, which can result in a total should-be-paid over the 50 BTC available. When that happens, the pool prioritizes people who have been waiting longer, and leaves the rest to catchup in the next block(s). |
|
|
|
Please add this project to BitGit, and enable CIA notification  |
|
|
|
FYI, after a week of testing on Europe, I have calculated that a patch I wrote decreases duplicate work by 0.7%. could it be this patch causing trouble with phoenix? No. Does us.mining.eligius.st work as a "normal" bitcoin node? Is there any reason I shouldn't specify it via bitcoin.conf as a node I want to connect to every start up? The pool nodes are not publicly accessible for security reasons. You can use relay.eligius.st if you want to use Eligius's lower fees. Any consideration of going to a score based system? I really like the operation of this pool, but it is too susceptible to pool hopping right now. Score-based is also susceptible, and is unfair to miners who aren't 24/7. There has been discussion of moving to a PPS-like scheme on IRC (which is where most of the discussion tends to be in general). Do you have to specify a receive address on the local machine? Currently I keep my wallet totally separate from my miners. Will this work with eligius? Eligius doesn't know/care about where it's sending to. Disclaimer - I'm not eligius staff, just a hobbyist. Everyone is "just a hobbyist"; that's the point of this being a community pool: we all get to hobby-run the pool I like that you can just put your address in the commandline and your ready to go.
If I understand this correctly, it should provide better results longterm than a pps pool? All pools can provide more or less the same results over time. The difference here is in fees: PPS pools tend to take large fees (eg, 10% for Deepbit) to cover the extremely high risk taken by the pool operator. And why is the EU Server so small (20 Gh/s) compared to the US one (120 Gh/s). Common european people, bring it on, the EU server needs more power!  People seem to prefer larger pools for some reason, despite them not having any practical advantage (over a certain threshold). Eligius Europe has also been having some rather bad luck (5% chance to have as bad luck as we've had lately), so some of the miners on it gave up and moved to USA. |
|
|
|
Luke, please press Ctrl+F4, I'm talking about testnet coins. Hmm? TBTC is Tera-Bitcoins, which AFAIK is impossible. |
|
|
|
|
Eligius accepts "non-standard" transactions.
|
|
|
|
The IRC code seems to already detect if it's firewalled and change its nick if so... Could just skip those nicks, if it doesn't already. Or better yet, if the client can't accept a connection, just have it QUIT?  |
|
|
|
So how does it help the pool at all, or "contribute to the pool" as you said? Since the fee can only be spent by Eligius, it is in effect a donation that the pool also accepts in lieu a transaction fee. |
|
|
|
Can you explain how only Eligius can benefit? It seems like anybody can modify a bitcoin client to redeem that txout, as long as they have the bitcoin address which it's being sent to? Then any miner will accept their transaction, right? Only Eligius benefits from the fee for this transaction. Since it is non-standard, and requires a special Eligius fee key (1A2UnusrwYr7DbiFbFesRKrbQMiYkj6E84) to get the "fee", other miners don't have any reason to accept it. What the recipient does is their own business. Sorry, I still don't understand. Which part of that transaction represents the "special fee"? Index 2 of the txouts? Correct |
|
|
|
Can you explain how only Eligius can benefit? It seems like anybody can modify a bitcoin client to redeem that txout, as long as they have the bitcoin address which it's being sent to? Then any miner will accept their transaction, right? Only Eligius benefits from the fee for this transaction. Since it is non-standard, and requires a special Eligius fee key (1A2UnusrwYr7DbiFbFesRKrbQMiYkj6E84) to get the "fee", other miners don't have any reason to accept it. What the recipient does is their own business. |
|
|
|
|
Can we increase the amount to generate too? I think it's perfectly reasonable to keep a buffer of 1000+ keys. Maybe a warning to backup when more are created, too?
|
|
|
|
Or just make a GUI as a front-end for bitcoind, no need to edit the original code at all, just send API commands to the daemon. This isn't practical. Spesmilo does it, but it's retardedly inefficient due to the poor design of JSON-RPC. I dislike the thread title, because I am but one of a herd of core devs under our lead dev, Gavin. It's either "Satoshi's client" or "the People's FOSS client" or "Gavin's client" or "Gavin/tcatm/sipa/BlueMat/jgarzik's client"........ bitcoind and wxBitcoin are sensible names.  As a core developer of Spesmilo, I'd be interested to see more node/wallet implementations |
|
|
|
|
Show Posts
