But i think the mining proxy will connect to your pool with one worker account then, dont it?
No, it proxies usernames as well. Cant you just raise the allowed connections to 25? (-;
There's really no reason, 20+ workers is already pretty big operation and using Stratum proxy is logical step. It optimizes network usage. |
|
|
|
Oh that's disappointing  . So as a miner who also wants to support & collect namecoins I need to switch to another pool? Is there any chance Stratum can support merged mining? Maybe I'll implement merged mining again, but not in any near future. AFAIK there's no Stratum powered pool which do NMC merged mining. |
|
|
|
The first 20 Miners connect to the pool correctly with stratum, the last two does not!
There's firewall rule to not allow more than 20 connections from one subnet. Please install mining proxy ( http://mining.bitcoin.cz/mining-proxy-howto), it will take 5 minutes and you can add as many machines to your mining operation as you want. |
|
|
|
|
I'm sorry for short downtime of pool in recent 10 minutes. It was because of failed update, now is pool fully operating again.
|
|
|
|
1) if i split my worker to 10 workers - each 500Mh/s, will it make the accepted shares more stable ?
No, because your share submission rate will be still the same. 2) what will happened in the April when i will have worker 50 Gh/s ? should i think to split it to 100 workers each 500 Mh/s ?
no what speed is optimal for the pool now ?
More the better :-). ACtually, you don't need to care about hashrate *approximation* provided by the pool. It doesn't affect your income, it's just fancy feature, which is inaccurate by design. |
|
|
|
The problem is the target - when I connect to the pool using getwork protocol, the miner reports current target as:
Target = 00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffff
but when I use the Stratum proxy, the miner reports truncated target:
Target = 00000000ffff00000000000000000000000000000000000000000000000000
Yes, I know there's some miner who has such problem. The easier solution is just to rewrite target in the proxy to 00000000fff...fffff . Then it should work good enough. Of course the cleanest solution is to fix that miner. My question for Slush's Stratum proxy therefore is - why is the pool returning full (untruncated) target in "getwork" response, but Stratum proxy is returning different target (truncated) in "getwork" response. Is this possible to fix, so that my miner does not see any difference, whether connecting to the pool directly, or via the proxy?
To be honest, that "full" target used by getwork pools was my mistake introduced two years ago, which everybody copy&pasted into their pool implementations. Real diff1 is 00000000ffff00000000000000000000000000000000000000000000000000, which I fixed in Stratum protocol. Fortunately normal getwork miners works with this without a problem, except your one... |
|
|
|
BUT, observed that when the round is over and a new started - for about the first 5-10 minutes, shows the performance drop to 4000-4500 Gh/s and later, after the period - shows again about 5200-5400.
"* The calculation is based on the number of shares so far, which may not be accurate for slow workers." I should add: "it is inaccurate on the beginning of the round also for fast workers". |
|
|
|
There was a quick discussion on IRC about how to handle the case where malicious software sends a super high fee transaction to the device for signing and then uses the fees to steal the money. The difficulty of verifying the fee without having the host send all depended-upon transactions was mentioned.
Device stores variable of highest acceptable fee per kB, so transaction with higher fee will be rejected. This will have some reasonable amount pre-setted from factory, but there'll be an API to change it's value if bitcoin fees become bigger than this limit (of course the change will show warning message on the display and will ask for confirmation by hw buttons). Does the device have any internal storage? What you could do is integrate the block chain sync process with talking to the device. As relevant transactions are discovered they are sent to the device which strips out the values of the outputs and stores them in its internal storage alongside the tx hash. Once all tx outputs have been spent the data can be deleted.
Unfortunately device won't have enough memory to store tx hashes and some other metadata. We're designing the device to have no arbitrary limits for transaction amounts and sizes. However we're planning to do SPV validation of tx inputs (and storing fixed amounts of checkpoints in the device to speedup the process for next time), so maybe we can somehow use fees from these transactions to approximate this maximum acceptable fee for the future. Thanks for the idea, I'll think about it a bit more. |
|
|
|
No one cares if ntime is exact to the second, as long as it's roughly right.
ntime should reflect current time. If there's another way of creating unique data header for hashing, it should be prioritized over ntime rolling. However ntime rolling is still possible, so don't worry, everything will be fine :-). |
|
|
|
Stratum does not need ntime rolling because a single stratum work unit is 4.2 billion times larger than a standard getwork unit (by default, it can be increased and the spec supports it very easily). However, Stratum also does support ntime rolling, the official spec is that ntime should not be increased faster than real-time.
nTime rolling is a hack solution to extend getworks, and if used improperly can be extremely bad for the network if a large number of blocks were produced and pushed the mean-time of recent blocks into the future.
Stratum protocol don't need to mention ntime rolling, because block header for hashing is produced directly on the miner, not by the pool. But re: Roy's concern about ASIC miners - yes, ntime rolling in ASICs will be still possible with Stratum. |
|
|
|
|
Jim, I really like your checklist. I was thinking about something similar for Electrum as well and now I finally decided to compose it, too.
|
|
|
|
|
Today I finally disabled port 8332 on URL mining.bitcoin.cz. Mining is now officially available on api.bitcoin.cz:8332, api2.bitcoin.cz:8332 (getwork) and stratum.bitcoin.cz:3333 (stratum).
URL mining.bitcoin.cz:8332 is deprecated over one and half year, so people had a lot of time to upgrade. If you still have connection issues, please upgrade your miner (old GUIminer had "mining.bitcoin.cz" hardcoded) or update your configs.
|
|
|
|
I just set up generating nightly builds for Windows! Binaries are compiled every day at 00:30 UTC. Now you can use latest version of Electrum on Windows without installing any dependencies. http://electrum.bitcoin.cz/ |
|
|
|
Oink was used from Kevin Rose ,the app (name Oink) was shutting down
I know it was also some bittorrent tracker or so. It actually doesn't matter, because almost any combination of common letters has been already used for something... |
|
|
|
This thread is already pretty long, so we decided to close the contest and announce winners! We're still not sure if we can use these names, but I and Stick like both Piglet and Oink. caffeinewriter, Mushroomized, can you send me your bitcoin addresses to PM? I'll send you both 1 BTC. Oink (Like a piggy bank)
Why Not piggy or piglet (raspberry pi general wallet
|
|
|
|
Few updates in this area: a) Sierrachart is working on version, which don't require .NET framework, which runs perfectly on Linux (under Wine). Please visit http://www.sierrachart.com/index.php?l=doc/download.php and download "NoCLR" version. This no-.NET version is still under development, so it doesn't support all charting studies and fancy features, but it works well for basic charting. b) I migrated sierrachart feed to github: https://github.com/slush0/sierrachartfeedc) I also fixed one endianess issue, so sierrachartfeed runs under Linux natively. |
|
|
|
|
Please note that latest Sierrachart doesn't require .NET libraries, so it run under Wine without any issues (just download installer and run in wine).
|
|
|
|
i think a many files will better than 1 file, the file per block (with the worker shares ) will reasonable ?
new block started - new file created? block found - file closed.
csv (or json) format for the stored data will great
This is completely outside of the project scope. It's more like job for miner itself. Please check documentation of your miner, some of them (cgminer) has some statistics and reporting already implemented. |
|
|
|
ps aux via crontab every few mins?
That will work, because crash of the proxy won't affect the watchdog itself. |
|
|
|
|
Show Posts
