Goatpig, I see what you mean; not _so_ bad idea, but still worse from side of performance and scalability. I'll think about it little more. When your miners hit a full difficulty solution, you upload the whole thing to the pool, transactions and all.
Pool still need to know all transactions to validate single share, so those information must be known by pool in time of share submit. |
|
|
|
somethings going on  Looked like issues of provider; pool itself performed well, just traffic went a little down (but not too much, so majority of users were still mining). It recovered after ~45 minutes to original throughput, now is traffic fine again. |
|
|
|
Rewards are not confirmed until 120100 new blocks have been generated.
Pool is waiting 100 confirmations, which is minimum required by bitcoin network. Next 20 blocks on top are required by bitcoin client itself, but it can be changed (as I did for the pool). |
|
|
|
Other options: Just send transaction IDs to the pool for verification, along with the header. 2. Get Bitcoin address for the pool.
The pool should give you N addresses: One for D=1 work, one for D=6 work, one for D=12 work. etc. D=6 work pays 6 shares. Etc. The reason for this is because your scheme uses a lot more bandwidth to transmit shares, but this is trivially corrected by increasing difficulty. But that would increase variance to unacceptable levels for slow miners. By changing the address they pre-commit to a target difficulty and the shares will be credited accordingly. The miner software can then bet setup so that it picks the diff that gets it close to 1 share per minute...which should end up being less bandwidth than currently used. Better, but not good, as load is not driven by pool, but by miners. I see thousands of CPU miners on my pool even with current difficulty, which is - from economical point of view - nonsense. So how to solve problem where hundreds CPU miners can shut down your pool with sending 1diff blocks, 1MB in size each?  With rising difficulty (expect diff over milion soon!), one share will be amost worthless. By increasing basic difficulty, you can make it better, but will people accept minimum difficulty @ 1000? Btw it's not only transfer problem, calculating complete block for every share is pretty hard, too. Forgot that pool can calculate tens of hundreds shares per second... Basically I like the idea, but those are reasons why I leaved it long time ago. |
|
|
|
1. Register for a pool.
2. Get Bitcoin address for the pool.
3. You run miner on your own local bitcoind.
4. Miner calls getwork on your bitcoind, gets block template YOU create locally! However, it gets the difficulty and generation address from the pool (to allow share-based mining, and to make sure the pool gets paid.)
5. Miner tries random nonces.
6. Miner finds share! Sends it to pool. If the share turns out to be a valid block, pool distributes winnings.
Ta-da. Now, all block generation is done by miners, not by pools, as Satoshi intended. In other words, the pool has /no/ control over the content of blocks! But pools still get block/share based mining, as pools want.
This is not new idea, I thought about that months before, too. There is one huge problem - performance. It does not look so on first view, but client need transfer _complete block data_ to central server for _every share_, because pool have to validate that share is correct (by user intention or by bug). So sending short hash to server with filled nonce is NOT enough. I calculated this and needed performance (for pool with tens or hundreds Ghash/s) would be enormous. Even worse - it is rising with more transactions in the block. So this scale even worse than standard centralized pool. In case that bitcoin will grow massively, this is show stopper. |
|
|
|
If I may ask what did this update constitute? LP support  lol ? Hehe, yes, it is preparation for LP |
|
|
|
Fun statistics time - my Google Nexus S runs at a rate of 43 Mhash/day if I just leave it sitting on my websites home page  Really Mhash? Edit: Oh, per _day_, I see |
|
|
|
Fuuu... done |
|
|
|
|
Well, I need to migrate database, so we're going down for a moment. Stay tuned!
|
|
|
|
Annnnnddddd.... we're back. Excellent!  I'm doing upgrade right now (as I wrote today), short outages like this one are expected . |
|
|
|
(50 BTC - 1 BTC fee) * (shares found by user's workers) / (total shares in current round)
Well, this is not absolutely correct, because that describes share-based pool, not score based; but it is correct *enough* for brief information how it works. I still didn't found a way how to describe score based system in few lines for absolute beginners and don't cook their heads . |
|
|
|
To further answer this question... our server refreshes the getwork on a fixed interval, and client requests to us return that cached work in addition to a nonce range. The refresh interval and nonce range width are chosen to provide enough work to the clients (which is not hard, since they're pretty slow) and to not exhaust the space of nonces.
We also check the validity of work submissions ourselves before passing them on.
Well, thats good solution. I was just affraid of getwork-per-pageview thing . Currently we're only pinging your pool once or twice per minute. We certainly don't want to abuse the privelege, so let us know if you have any concerns or comments.
Well, if getwork ping are in constant rate (as it obviously is), you can ask for getwork more frequently to avoid stale shares (by crunching hashes from outdated block). Generally I like the idea and I wish you success. It really can replace stupid flash ads (which is btw also taking one cpu core for itself . Also consider flash mining; flash itself is compiled and much faster than javascript, so you can incredibly improve hashrate even on CPUs (my Intel Atom can make 500khash/s per one CPU core, instead of 300 hash/s in JS). Newest flash has also limited support for GPU, but from my teoretical knowledge it should be enough to implement GPU mining in browser... |
|
|
|
Well, how this works _technically_? I hope that it does NOT call pool for every pageview... So how is work distributed? We have an independent loop pulling getworks from your pool on a fixed interval, so definitely not on every pageview. Great. Can you tell me what browser got you 275 hashes? On chrome/safari we get more like 9000 hashes.
Firefox 4 on Intel (ehm) Atom |
|
|
|
Any word on when long polling is coming to slush pool?
I'm coding right now . I know that LP is most wanted feature so far... |
|
|
|
|
Well, how this works _technically_? I hope that it does NOT call pool for every pageview... So how is work distributed?
Btw I partially implemented that, too. Many months ago. Then I realized that buying one more ati 5970 is better than managing network of zilions slow workers.
Actually bitp.it shows me "275 hashes per second", but I my code (which I don't have anymore, unfortunately) derived from some public sha256 js cruncher made few thousands of hashes per second on same machine...
|
|
|
|
I'm using GUIminer, so no command line. Is that what I'm doing wrong?
No, it should work. GUIminer has 'console window' somewhere, there you can find used parameters for the miner, please post them here (except password, of course). |
|
|
|
Question: what happens when i switch off my miner for a sec to change the 'f' setting and then switch it back on?
Do all the shares i processed for the current block go wasted?
No, it is basically same as when gpu does not find a share for few seconds. |
|
|
|
I actually like Deepbit's system a lot better. It's a lot easier to keep track of earnings.
Well, main difference that on my pool you see your income in *realtime*, deepbit has all stats delayed for one hour. You just have to wait until block is confirmed to withdraw bitcoins to your wallet, but this is mechanism how bitcoin network was designed. Yes, there were invalid blocks yesterday, those were technical issues and I believe that everything is fine now. Corrupted GPU cannot affect pool itself. |
|
|
|
I'm running Win7 64-bit with GTX 470 with guiminer. Guiminer is reporting about 82Mh/s, I installed the greasemonkey script and the site is reporting only ~40 Mh/s for that worker... Is this a problem with the site, the script or my end? Does anybody else have this problem? I'm also running the command line miner for my cpu and the sit is reporting the same as the client ~17Mh/s.
There is no problem. Site hashrate is just aproximation, miner does not report his real hash rate. That's exactly why hashrate is hidden by default. |
|
|
|
I've noticed that it isn't in real time the data feed, there is an average lag of 4-7 minutes, is it possible to fix it slush?
You're using old version (0.1), right? websocket library used in this release was really bad, 0.2 fixes this and I see everything in real time now (usually even faster than #bitcoin-market). |
|
|
|
|
Show Posts
