A long time ago someone (or may be it was you i can not even remeber ) told me that it will took you a week to patch and setup your own (solo) pool. Considering the fact  that you have significant portion of Litecoin's Hashrate i am wandering how many years have to pass before you setup your own pool
You can always consider the option to join my pool with SIGWIT. Besides, doing so with such significant portion of Litecoin's Hashrate you will have less variance in payments and you will get 99.5% of each LTC block + 95.0% of each DOGE block. The beauty of it is that your rewards are generated directly at your address..Any way this is just an option

Thanks again guys - had clam checker scan the wallet, and as suspected, it was worthless.

Hard drive can now get tossed with no doubts.

EDIT:  Found another older hard drive I was thinking about discarding with more wallets I had forgotten about....

This seems like a very reasonable deal? Is there some hidden catch? Also, can anyone explain to me the $500 difference between buying first batch and second? It it simply because they think the difficulty will rise substantially following second batch? Just wondering. Thanks. Anyone have suggestions on hosting options?

Im done with this snake-oil thread.

jstefanop Has not followed through with any promises of info.... which is the only reason I keep checking this thread for a honest answer.

Good troll my friend.   PM me if anything real hits the table, till then, I am done reading this garbage.

Im sure theres many others in the same boat as I am.

Before throwing away an old drive, I found an old litecoinqt file.

Also a .bat wallet backup, which I am unable to open.

It is currently synching - it is at 280 weeks, old stuff....

I believe it is empty, but when I put the addy into Litecoin Explorer it shows blank - no info at all.

Does the qt need to synch before the addy shows up with any balance?

(Again, most likely it has a zero balance, just wanted to check before throwing the disk away.)

You say that this is not fair because the variance is not the same as it would be in a solo mining situation. Drawing this conclusion actually requires you to make assumptions about the algorithm used by the pool to decide when (not) to signal, but for the sake of simplicity let's suppose that you are right, and that our system does result in lower variance for all its users. If anything, I would say that such a system increases fairness, as luck becomes less of a factor. But let's say that you disagree, and that your idea of fairness requires higher variance. Now, consider what would happen if this pool started signaling with 100% of its blocks, as you suggest: the users who do not want to signal would simply move to a non-signaling pool such as LTC1BTC, and the effective variance of their contribution would be even lower. For the remaining 99% of the pool, on the other hand, variance would remain practically the same.

There is also another important element to consider here, which has not been mentioned yet: the 75% goal needs to be reached over an 8064-block period. That is a lot of blocks, which significantly lessens the impact of variance.


I think you're confusing percentages of pool hash rate with percentages relative to the whole network. The pool miners voting "No" have about 2.5 GH/s, and that's less than 0.1% of the network's hash rate. The 75% threshold that would trigger a SegWit lock-in is currently about 6% away in terms of blocks mined since Batpool started signaling, and 6% of the network means about 170 GH/s. That is, the gap that needs to be filled is 68 times as large as the fraction of pool users who are voting "No".

The signaling ratio of the whole pool is proportional to the hashing power of the users voting "Yes" (or abstaining). Right now, this figure is around 98.8%, as about 1.2% of the hashing power of the pool belongs to users who have voted "No".
For technical reasons we cannot currently provide a guarantee that the blocks any given miner finds do or do not signal. In practice, however, this makes no difference, as the contribution towards SegWit activation would be the same.

You must have missed that last few news items. [1] [2] [3]


TL;DR: 1. We are just respecting our miners' preferences. 2. Moving your miners to another signaling pool changes nothing (unless you explicitly chose to vote 'No' in your settings, of course).

For me it's quite the opposite...using 2 threads gains additional +0.3/0.4 but too many hw errors.
As you can see in the picture 29.42(1 thread) does gg vs 29.8 on claymore vs 30 (2 threads gg).
EDIT: Did some timings mods and now hw errors are acceptable ~1/2 every minute.

The current version was working fine with Ubuntu, though. Strange, strange...
I just pushed a fix to the repo anyway.

The ASM version is only for Ellesmere for now. I will prepare binaries for other cards shortly.