That's old and doesn't cover fglrx :/ Actually, with Radeons using GDDR5, I'd want it to be the MAIN memory, not swap...  |
|
|
|
Hmm, is it possible to hijack the unused video RAM for swap?  |
|
|
|
Also the information you provided was quite helpful. Is there any way you could have your server put together a file for each address with content like you put above. It would make it easier to track earnings and possibly save some confusion in the future. Just an idea / suggestion. I might if I have some time today, put together a script to do it using the json you have provided already. I looked into doing this, but it would be fairly complex. Right now, replaying the entire history (to get the details I showed you above) takes almost 10 seconds already, and I would need to maintain an open file for every address throughout. That would be 10 seconds during which miners would be running out of data, idle. I keep it low by caching the balances, but that wouldn't work for the format above. |
|
|
|
I would like to know how invalid blocks get handled. If a block is invalid, it is completely ignored by future block generation, as if it never happened: shares contributed toward that block are "reinstated" toward the currently-in-progress block, and payouts are as if they never happened. Also, I think that if all of us, who have external IP, connect our clients to his pool to receive newly found blocks we will a bit decrease the chance of invalid blocks - because solved blocks will spread faster in p2p network.
luke, is it enough to "-addnode pool.bitcoin.dashjr.org" upon our bitcoind start? or "-addnode 173.242.112.53" ? You can try it, but longpolling should be just as effective, if not more. Do note that the public peer on my server is used for #bitcoin-watch, NOT the pool. For security reasons, the pool's node is not externally accessible at all, and only communicates with the #bitcoin-watch node. |
|
|
|
Could you please investigate this. Something seems odd with the payout system and as well as how it keeps track of earned rewards. 0000000000001058cc4b850fc2f1f906f3ad4a2a276cc326f1811fb4d1b74ec4: You earned 1.63719062 BTC, and were immediately paid 1.63617631 BTC. 000000000000186bfede5c3e9d599a1aec8a6fb37854f8d30aa1536e0c81557d: You earned 1.61041198 BTC, and were immediately (over)paid 1.61243335 BTC. 000000000000560b1ffd8af896cd5b0ed668f03aa9a7728a5fa2182c5ee76e2e: You earned 0.10549032 BTC, and were not paid due to balance being under 1 BTC. 0000000000001a2585f316f81b20623e693845515f216f3ecb787583f4b79874: You earned 0.88415731 BTC, and were not paid due to balance being under 1 BTC. 00000000000038e334a9c559b7f49cd76fb8f2d99537be7fc8d1cf69ed01bfdb: You earned 0.32138317 BTC, and were immediately paid 1.30396680 BTC. 0000000000004d8ce1babf4fdbf153f813ec4776ea53f7e36cd4897886349f0d: You earned 1.04322469 BTC, and were immediately paid 1.04706787 BTC. 0000000000000415d30f8bc59fc4ed45f2bd7661c2ef3f89aed2e2c9cd2023a8: You earned 0.32683516 BTC, and were not paid due to balance being under 1 BTC. 000000000000279a59e47b514a7064f0d177642f978cc5e5a425505a0dab06c5: You earned 0.59436705 BTC, and were not paid due to balance being under 1 BTC. 000000000000198ed4cb0586b718bc901865d1e94cb859cd1c4af043379d9aa8: You earned 0.77644269 BTC, and were immediately paid 1.68449708 BTC. You have an outstanding balance of 0.01536158 which will be paid as soon as you either earn a total of over 1 BTC, or don't mine on the pool for a full week. |
|
|
|
|
It ended up being 1QDs3u4NawCmPBfMxWzZARbwjWwEQdTFTd who was shorted 1.68134587 BTC. Unfortunately, there is a flaw in my payout code which has chosen this same poor fellow to be shorted again this block, if it doesn't cover everything. I need to rethink the payout weighing code. Hopefully before this block is found, but in any case he will be paid in full eventually.
|
|
|
|
- Transactions are included in blocks based on my policies: non-standard transactions accepted, but a flat transaction fee required of 0.00004096 BTC per 512 bytes
Can you please explain this to a newbie ? What does it mean and why do you need it ... Do I need to change some setting on my rpcminer-cpu client ? This is no effect on mining. Basically, it means the pool won't participate/confirm transactions without a (tiny) fee, so it is immune to transaction spam.[/list] |
|
|
|
|
Just an advance notice: the current block is overbilled; a total of 52.8665594 BTC is due to be paid out, but most likely the reward won't be that much.
As a result, the address 15syQPo3NadEtD4UVv34ixjkZvztCHCcX1 has been chosen (more or less randomly) to be paid only ~1.56 BTC out of his due ~4.43 BTC. The remainder will be paid at the next block. Since this is random, it's quite possible some factor may end up in another address being the one delayed. So if you happen to receive unexpectedly less and your balance has over 1 BTC remaining, this is why.
|
|
|
|
I don't think it needs any stats other than perhaps how much you've paid yourself. I consider my own pool output to be just as private as anyone else mining on it. I only posted my earnings above to promote the pool, and confirm that it isn't just me receiving above-expected earnings. As far as fees, the address receiving the 0.00000001 BTC per second is 1LGiiiQF6EW8Eoop5KyGmkSDGnYZRd94EE. With the new 1 BTC minimum, it will probably not show up very often. The first address in a transaction is the "leftovers", generally due to the non-payouts of earnings under 1 BTC. It will obviously be filled by the payouts later on when those members reach their 1 BTC minimum. These funds remain in Eligius's client. If there ever becomes a problem with it consistently delaying payouts, I can manually do a sendmany with them to "catch up" (although I don't have anything written to offset such a send in the payout code yet). |
|
|
|
Your problem with Ufasoft is that it does not send an authentication header on the first request.
You have to respond to it with a 401 WWW-Authenticate string, and then once it replies with the auth, return a getwork. If I omit the authentication in a request manually, I get a 401 just fine... |
|
|
|
The pool overpaid. Usually due to shares not factored into the final generation reward (meaning the pool underpaid someone else). I just put a 1 BTC buffer into the script, so 1 BTC (spread equally across all miners) will be delayed until the next block. Hopefully that will mitigate the vulnerability. |
|
|
|
|
BTW, whoever is username "135dgT3qkdzac3DWMQfwwSeq2cH" needs to fix their miner to send the full address or it can't pay you...
|
|
|
|
|
I want to make one thing clear, in hopes of explaining where I am coming from personally: I have no interest in running a pool for-profit. Until this difficulty, I was perfectly happy mining on my own. The only reason I have a pool, is because I can no longer get a block within a single standard difficulty period of 2 weeks by myself. Therefore, my operating this pool will be under that assumption, particularly with regard to the lack of a fancy webpage or stats. Please note that actually useful stats, like the ones I have thrown together so far, are not included in that.
That being said, if the pool members wish to pay me for making fancy stats, I could perhaps setup some kind of optional "pool development fund" donation thing. But writing the code for that would also be non-trivial and incur a cost to me. So it would only work off-the-bat as a pool-wide fee, or a simple Bitcoin address those who desire such features can manually send to. As not everyone necessarily cares about such things, I have decided the better is a superior method. Therefore, if you want to contribute funds toward fancy statistical stuff, please send your contribution to 16yREn3ixJuPLP1RaLgTjVERsQDhUJgZg
In the meantime, I would appreciate all comparisons between "expected' earnings (eg, the ";;bc,gen" command on IRC) and actual earnings from my pool.
I personally have received 15.73 BTC, while my "expected" is only 8.51 BTC. I hope you all have similar results.
|
|
|
|
But we want anarchy and autoregulation? This is it is. Don't assume everyone has the same goals for Bitcoin that you do. I am a monarchist, and accept that regulation is good and necessary. Also, your DDoS may be anarchy, but you will soon see the effects of autoregulation: it seems everyone is going to boycott BTCex over this. |
|
|
|
Where my shares gone? balance: 0.827431 This is < 1 BTC If the pool hash rate goes up significantly and you use the latest bitcoind (which allows sending payments to multiple recipients at once among other things), then it will probably will be useful. Just my thought on the matter. I haven't looked into what it would take to build a pool. I would have to dabble in solo mining with multiple machines [and one master] to get closer to deciding to do so. However, I think there will be enough pools by then that a new pool won't be useful. I think a pool with a great website and lots of features while sticking to the 2% rate would be a winner! Maybe I and a couple of buddies should whip something up [nah ... won't happen  ]. You don't seem to understand how my pool pays out. There are no payout sends, you get original coins direct from the coinbase. |
|
|
|
|
dishwara and jkminkov please take it somewhere else. It has nothing to do with this thread.
|
|
|
|
A quick question luke, I've just joined your pool and mining at 1.2GHash , got like 500 shares at the moment for 4 miners, but have yet received any BTC in my client, so I just want to know how to check my total share for the pool, and what is the ETA for the first btc payout from your pool ? Or its just pure luck for the whole pool like when a block is found, everybody get the shares, none found = nothing ? There's been a couple scripts posted in this thread (page 3) that read your own address's balance from the pool. Payouts occur out of the generated blocks. At the current hash rate, the pool gets a block on average every 12 hours. |
|
|
|
|
Please note the pool no longer pays out until you reach 1 BTC minimum.
|
|
|
|
|
Show Posts
