Just an update... Eligius-3 seems to be running stable now.  |
|
|
|
I'm running windows and I want to send a non-standard transaction to Eligius because it would be cheaper
what's the easiest way to do this? Right now, your best bet is to add mining.eligius.st as a node. |
|
|
|
Ok, new efficient PPLNS pool is running on s3.mining.eligius.st. Use at your own risk-- it's obviously quite untested so far. Until we find the first block, both stats and time-based fee are known to be broken (that means you get less basically-no-fee-anyway until then!)  Primary DNS names will remain pointed at Europe until it finds its last block... |
|
|
|
|
Working hard on getting Eligius upgraded. Will need to drop some planned features, though. Main goal right now is optimization and SMPPS.
The Europe pool's SSD has finally nearly run out of space, so I plan to shut it down as soon as it finds its next block or the new pool is ready, whichever is later. That block's coinbase is hard-coded to pay out the smallest 901 balances, and I will be making a manual payout or transferring balances to the new pool for the rest later. If Europe finds a block before the new pool is ready, it will keep running, just to not waste hashing power, but it will probably never find another block after that one, so any work after the next block on Europe will be wasted unless we're extremely lucky. In short, do not expect payment on future Europe-pool work after this next block.
Stay tuned on IRC. I will probably also post an update to Artefact2's stats site when things change over.
|
|
|
|
As far as I know, the actual value of the X-Roll-Ntime header is presently undefined. I would like to suggest that if it contains expire=N, then the work is valid for up to N seconds. This can allow miners to know precisely when to give up on it and get new work.
Thoughts?
N seconds or ntime incremented by N? There shouldn't be a difference... |
|
|
|
|
Well, Shared Maximum Pay Per Share has obviously won by a landslide... now it's up to me to code it!
|
|
|
|
|
Is it possible to make the pubkeys separately deterministic from the private keys, and have multiple chains of them? My thought is that this would be nice to allow receive-only bitcoinds for services-- they can call getnewaddress to get a unique destination address, and listtransactions can still show what they received, but they don't have the private keys to send the funds. The other servers could have the "root keys" needed to track all the other servers' transactions, so listtransations on any server would show the data for all the servers. Finally, only the super-secure wallet would have the data needed to generate the private keys and actually spend the funds.
I presume multiple chains is merely a simple matter of implementation, but I'm not sure whether deterministic pubkeys matching privkeys is possible?
|
|
|
|
Just a friendly reminder that the "Satoshi client" is switching from wxWidgets to Qt4 soon, so it may make sense to wait until that is done before putting effort into new dialogs. I would personally welcome a fork of the "Satoshi client" with other improvements (such as proper URI support), to shake the monopoly the mainline currently holds.  |
|
|
|
|
As far as I know, the actual value of the X-Roll-Ntime header is presently undefined. I would like to suggest that if it contains expire=N, then the work is valid for up to N seconds. This can allow miners to know precisely when to give up on it and get new work.
Thoughts?
|
|
|
|
I just wish I didn't have to wait until 1 BTC for payout. I moved to another pool because they will payout above 0.01 BTC. That works better for me because I'm doing low end mining just for fun. Having to wait for 1 BTC is like having to wait for $100 on Google Adsense. Lots of small ops never get there. The new version should support requesting a payout with signmessage. |
|
|
|
What's the drawback of geometric? It seems completely reasonable For me, the main drawbacks are that I can't understand it, and if I simply implement it as-is, Python errors because of insane exponents. |
|
|
|
Why does the poll have fewer options than are presented on that Payout Methods screen? - Slush Score -- rejected because arguably copyrighted, and unfair to legitimate miners
- Daily Proportional -- rejected because it doesn't solve the problem (just changes the hopping algorithm)
- Proportional -- rejected because it has the problem
- Pay Per Share -- rejected because I'm not willing to run a pool at negative income
|
|
|
|
The problem with Shared Maximum Pay Per Share is that in short lucky runds you get payed per share , instead if you get a long rounds streak there is the possibility that the credit isn't enough to pay all the shares and it switches to proportional method !!
This goes in favour to the pool hopping cheat!! 1. Pool hopping isn't cheating. 2. SMPPS never switches to proportional. |
|
|
|
Ok, new difficulty is here way too soon... let's get this over with ASAP! Please vote your preference(s) for Eligius's new payout method. Please only vote if you at least intend to use Eligius after the upgrade (assume your vote is chosen for payout method). Please only vote if you understand the payout methods, and shortcomings of each method. Note that you can vote for more than one option, if you want. Notable misconceptions: - MaxPPS: While you do lose "credit" if you change addresses, you do not lose out on being paid for mining work you did.
- MaxPPS: Both variables converge on average of once per day based on graphing real-world data, which means you can reasonably time an address change to not lose even any "credit"
- PPLNS: If a block is shorter than diff*2 shares, it will go back and pay shares from the previous round(s) again
Summaries: See also: Real-world example graphs for most payout methods |
|
|
|
Why not Meni Rosenfeld's algo (a la continuum pool)? It doesn't seem to work sanely. At least, Python can't handle the huge numbers it wants for score... |
|
|
|
and why didn't it prevail? Globally, SI/metric prevailed, mainly because it was illegal to use anything but SI/metric. Any other suggestions for payout methods to consider? We're running out of time fast, so I need to get the poll options finished soon... |
|
|
|
|
Show Posts
