Update on workers, share management and payout method
In the last month we've seen quite an influx of new miners on the pool. With so many new members, we've also seen a lot of people
wanting to switch to daily payout after initially starting mining using the (default) instant payout method.
Unfortunately, due to the way the pool is coded, it isn't possible to easily switch between the two methods while also preventing
abuse by third parties. Therefore, the only way to change payout method is to completely stop mining, wait for your address to be dropped
by the pool and start mining again using the correct payout prefix to your username (See How to mine).
This usually means waiting quite some time. An easy alternative would be to just generate a new address using your favorite wallet and
use that to mine to with whichever method you prefer. And this is indeed what most people do, as it means they don't have to wait for
the pool to make its final payment and drop the worker.
However, since most people were choosing this as a fast an easy solution, it meant that a bug in the share and worker management logic of
the pool went unnoticed for quite some time. It turns out that however long your waited, in a lot of cases the pool wasn't dropping workers
at all!
Which brings me to this update. Various alterations have been made today to the way the pool handles shares and workers:
The pool will now only take blocks found by the pool itself into account for share management. The old 1% decrease in shares whenever
anyone on the network finds a block is gone. The 20% decrease whenever the pool finds a block remains the same.
The pool will no longer ignore blocks found in rapid succession for share management. As this pool frequently counts for nearly 25% of
the total hashrate on the network, the chance of this happening increases and therefore this rule makes the share management less predicatable
instead of more predicatable.
Worker eviction from the pool is fixed. Workers are evicted whenever their shares drop to less than 5. This is a change from the old 0.02/0.08
shares, which means eviction will happen a lot faster and the pool will generate a lot less dust outputs. Eviction time depends on multiple factors,
including your hashrate and pool luck. However, for regular miners with a single, average GPU eviction time should be around 1.5 hours.
A new initial requirement of 15 shares has been introduced in order for a worker to qualify for payout in the first place. Until this requirement
is met a worker will just collect shares without being included in the block rewards transaction or subject to the 20% share reduction rule.
This is intended for very low hashrate workers that have difficulty keeping up with the requirement of submitting at least 1.25 shares within the
time it takes the pool to find a block to avoid early eviction.
Once this initial 15 shares requirement has been met, they will behave like any other worker until and including when they hit 5 shares or lower and
are removed from the pool. When this happens, they can start building again to the 15 initial shares from 0.
In the last week we not only saw the coin's value increase by a factor 10, with it it also suddenly got quite busy on the mining pools again,
with the network difficulty increasing by a factor
4 as well!
I would like to welcome all the new garlic bread bakers who have chosen to join this pool, it is quite a honor to still have around
a quarter of the network hashrate on this pool!
But that also means I should finally start fixing some of the long standing problems with it. And the first thing had to be the daily payout
system that was limping around on its last legs.
In the early hours of this morning I migrated the pool to use the new
FreshGRLC.net Managed Wallet API, which will in the future also serve as backend for an upcoming web-wallet. Some daily payout miners will
have already noticed their consolidation address has changed to a new one starting with a W.
These W-addresses are very similar to normal G-addresses, with the exception that they are cheaper to send coins from. Moreover,
every G-address has a corresponding W-address and they can be found
on the explorer.
They are also the same as the longer type of addresses that start with grlc1. Actually, both W-addresses and grlc1-addresses cointain
the exact same data, just written in a different form. Since W-addresses predate grlc1-addresses, all FreshGRLC.net services use the W-address format.
But again, you can easily convert them using the explorer as shown above.
For more information about W-addresses, see my
original post from back in the day.
Note by the way that Insight doesn't support either the W-address format nor the grlc1-address
format and these type of addresses will instead show up as Unparsed address.
As for the new daily payout backend? Everything seems to be working fine now, but their might be some early kinks in the new system that will have to
be ironed out, in which case I will try take care of them as fast and best as possble.
Service disruption
As most people will know at this point, we had another multi-hour service disruption today. Caused by a chain of events in the datacenter our pool facilities are hosted.
At about 17:50 UTC there was a major power failure in the datacenter. For some reason backup systems did not come up causing a major chunk of servers to go down, including the pool.
It took them till about 20:30 UTC to get every system back online. Unfortunately only at this point they discovered that the power failure did also break internal network routing.
At about 20:50 UTC all issues had been resolved and the pool did come up.
At this point we were unlucky (lucky?) enought to immediately find a block. Because the pool was not up long enough to get a view of the workers mining towards the block, the entire block reward was sent to a special reserved address. I will manually pay out this block using the ratios of the next block we found as soon as it matures.
I will also do some reevaluation regarding another pool server migration. Not only is the current hardware a bit overkill of the pool as it is now (we are using about 1/20th of the resources we did when we migrated to this server), this is now also the second time that issues in the datacenter caused the pool to go down.
Second major website update
As you might have noticed, we have made some major improvements to both the style as well as the general usability of the website.
Whereas previously I had just randomly thrown some stuff together, we now actually have someone working on the website who knows what he does.
The idea was to keep the same general style, but remove the eye-strain and headaches that were induced by browsing the site.
And I think we succeeded in that :-).
We will probably keep making minor modifications in the coming days or weeks and possibly further improving usability and adding features.
Finally, I would like to thank @Antiger#4943 for his voluntary work to make this happen.
Feel free to show your appreciation if you like it!
GN3ZqKpUR1h9xvdywQfxyEYZE8oarK2Efp
Pool unavailable for about 80 minutes
This morning the pool went down for about 80 minutes due to a networking infrastructure incident at the datacenter our pool is running from.
Unfortunately there was not much I could do during this time apart from waiting for the provider to fix this issue.
I did contemplate temporary moving the pool to another server, but decided against it as it would probably take longer to get that up and
get all the miners to move over than it would take to wait for the problem to be resolved.
I understand it if people will now move away to another pool because they consider this pool to be unreliable. And to be honest, I get it. This pool is not comparable to the big ones that have multiple geolocated servers, load-balancing and failover, such as Soup, Bakery or Org.
I am running this pool for fun and paying everything myself, without getting (or requesting) anything in return. This means unfortunately that I cannot pay for premium infra. I have the pool running on dedicated hardware, with a dedicated internet uplink. This to make sure we are fast (low-latency) and can handle the load and especially burst network traffic without compromise. However, this is where my budged stops.
If you have a large mining rig and cannot afford downtime, this pool is probably not for you. If you still want to mine at this pool, I would recommend you to use a failover configuration to another pool in case these types of events happen again. Org has a nice example on how you can configure failover in your miner command line (/bat file).
This might actually be useful for everyone mining here.
Per-worker hashrates
For people that have multiple individual mining rigs: we do now support per-worker hashrates on the my worker page.
This means that if you use the common format of appending a period ('.') followed by a nickname for you worker
to your username/mining address, you will find it listed by its name on the my worker page,
together with its current and average hashrate.
The same information is now also available via the workerinfo API, allowing you to monitor individual workers.
As a lot of people are probably aware of by now, last night we experienced a glitch in the daily payout processor.
Probably caused by a off-by-one error in the block maturity test (full investigation is still pending), more than 90% of
payouts got cancelled by the final verification and sanity checking code due to an incorrect transaction
amount.
In the mean time I have manually initiated another payment round, which executed successfully. This means a small amount
of miners received payment twice (where the second time only payout for the work since the last payout
was included).
More information will follow as soon as the root cause if the payout issue is found. I will keep a close eye on the daily
payouts and manually request another round in case we experience another failure.
Daily payments are here!
While everyone is anxiously waiting for the hard-fork to occur, we have other big news: By popular demand, we bring you daily
payments!
We have had a lot of people ask if it would be possible to set a certain treshold for payout, similar to how other pools
handle payout. However, we are not like other pools! The big thing that makes this pool different is
that it does not collect your block reward. Instead it crafts the blocks in such a way that your rewards
are sent to you without the pool ever even touching them.
With daily payout, we find a middle ground. Instead of directly sending you your part of the block reward, it gets collected
in a personal consolidation address managed by the pool. Once every day, all your rewards are then sent
to you in one transaction.
This last part will require a small fee. However, this fee should in almost all circumstances be (way) less than the fees
other pools ask for. Still too much? Just keep using the instant payout instead. All this is just another
option for miners who are interested!
Want to know more? You will find all the information in the How to mine tab.
Advised to add --submit-stale to ccminer-tpruvot command
From now on we advice any miners on this pool to add
--submit-stale to their ccminer-tpruvot / ccminer v2.2.5 command line. Since this pool sends out
more frequent work-updates, while only discarding old work when the network actually finds a new block,
it seems that ccminer's stale job checks prevent it from sending otherwise valid shares.
Note that changing this setting might decrease your valid share ratio, but you will find more valid shares overall, therefore
receive higher payouts.
This looks to be (one of) the main causes of the hashrate issues we have seen on this pool. It is unclear to me whether this
also affects mining on other pools, as I don't know the exact checks ccminer uses here. At any rate,
the effect of not using this option on this pool should be a lot higher than on others.
Note that if you are using other mining software or are using the
nanashi ccminer fork, you do not have to change anything.
Ready for the hard-fork
The is a quick update to make people aware that this pool is now ready for the upcoming hard-fork scheduled to occur after
block
58670, expected around
19:00 GMT on the 16th.
We are now running an a fork-enabled Garlicoin Core node and stand ready to switch the pool over to the new hashing algorithm
on a moments notice.
We are planning to take the pool offline after block
58660 and get the new pool up as soon as possible, expecting this to happen minutes before the
actual fork occurs. This should give everyone enough time to update their miners and re-connect, this
so we can start mining for
Allium as soon as block
58670 is found.
Miners that don't want to loose out on a chance to get the blocks in between should make sure they join another pool at that
time.
Testnet pool available in preparation for hard-fork
In order to allow miners to prepare for the upcoming Garlicoin hard-fork, we made a
testnet pool available. The testnet has already forked to the new
Allium hashing algorithm, so as soon as mining software becomes available you can connect to this pool and test
your new setup.
The testnet pool's stratum server is at:
stratum+tcp://testnet.freshgarlicblocks.net:3032
Note that sources for
ccminer
and
cpuminer can already be obtained via their respecive github repositories.
More information regarding the hard-fork, and how this pool will prepare for and handle the fork, will be announced later
this week.
More information with regards to hashrate issues
This is just a quick heads-up to say I wrote a
reddit post
with more information about tests I did with different versions of ccminer and how you should not trust the miner-reported
hashrate without also having a look at the hashrate the pool reports.
See the post itself for more info.
Pool hashrate verification test available
One of the complaints I still get from time to time is that the reported hashrate one this website is lower than it should
be. Some miners therefore decide to go to other pools.
Ever since the new rolling-average hashrate estimation has been implemented, I feel that the hashrate calculations should
be pretty precise (once they have fully stabilized after a few hours) and I have therefore also removed
the warning/disclaimer we used to have on the site.
That said, it is still true that the hashrate estimations are only used within the website's UI. Payout is 100% based on
shares sent to the pool. The main issue here however, is that if the reported hashrate is lower than
expected, it is probably being caused by the fact that less shares are being send to the pool than otherwise
would be the case, hence the pool's hashrate estimation (based on those shares), as well as miner reward
payout, is lower than expected.
Now, it is of course easy to say that the pool is somehow showing incorrect information or maybe even ignoring some shares
send by the miner, therefore reducing both the estimated hashrate as well as payouts.
To counter these claims, and in an attempt at full transparency, we do now have a special page that can be used to test and
verify the pool's processing of your submitted shares. That way, you can verify that the pool is correctly
processing all the shares you sent in and therefore rewarding you correctly based on the work you are
actually doing (i.e. if you are randomly hashing, but for example generating a lot of hardware errors,
therefore not doing a lot of actual work, there is no reason for the pool to reward you for the work
you did not do).
Hopefully, this page will clear things up and lead to one of the following conclusions with relation to why you are maybe
paid less than you thought you would:
Your miner is fine, but the pool had a period of bad luck (this is now verifiable using the new luck
graphs).
Your miner is fine, but it itself had a peiod of bad luck (hence it was sending in less shares than
expected).
There is an actual issue with your mining setup and you might be able to tweak it by changing (for
example) intensity settings.
The page is available through the my worker tab. You can run the test without having to stop mining at the pool, as it
just analyses pool worker data. You do however need access to your mining software (i.e. you typically
can't do this remotely), as you will need to verify the pool's share counter using the share counter
within your miner software.
Pool luck graph fix
The pool has been restarted to apply a small fix to the pool's luck data gathering.
You might have noticed that some datapoints are missing in the luck graphs. This was caused by the data gatherer sometimes
missing the end of the capture window, therefore combining multiple measurement windows into a single
datapoint.
Note that this does not make the luck graphs incorrect, just somewhat imprecise.
This issue has now been fixed and new data should no longer have this flaw.
New website
We have a new website layout!
The original website was only made with 20 - 30 workers in mind and a hardcoded limit of 100 workers.
When Garlicoin mainnet launched and both the network as a whole as well as this pool got a lot more
traction than expected, a lot of changes had to be made in a short time.
One of the final changes, and overhaul of this website, is now complete: Have a look around!
Apart from the overall design (and the same shitty style ;-) , the main features are pool luck graphs and an easier way to
view worker statistics.
How to mine on the FreshGRLC.net pool
Right now we offer two ways of mining at this pool. Or rather, we offer two types of payment:
Instant payout
Daily payout
Instant payout is what made this pool special from the very beginning. You directly get a part of the miners reward
(and transaction fees) via the block's coinbase transaction.
Basically, you are "solo-mining together" and that against 0% fee! Simple and no bamboozle.
Since mid-February, we also offer daily payouts. This is a way to reduce the amount of Unspent Transaction Outputs (UTXOs)
in your wallet, therefore making it cheaper to send coins to other people down the line. With daily payouts
you still get a part of the block's mining reward, but instead of directly sending it to your wallet
address, it is send to a personal consolidation address managed by the pool. Once a day, all your rewards
are consolidated using a special low fee (typically less than 0.1%, in a lot of cases only a fraction
of that) and sent to your payout address.
You can choose whichever payment method you like most and configure your worker to use it using the instructions below.
Note
Because of how the pool works and combines multiple workers together based on their address,
the pool will only set your chosen payment method when it first registers your worker.
This means that if you want to change payment method you either have to stop mining and wait
until your worker does no longer appear on the Workers list tab, or change your payout
address so your miner can register itself as a new worker.
Our bread and (garlic-) butter: Instant payout
You can mine at our pool by simply connecting with your mining software to our pool's stratum server, using your wallet address
as username. This will set up your worker for instant payout, in other words: you get paid whenever we
find a block. Instantaneous.
Using this method, the pool does not even touch your earnings once. Instead you get a part of the raw miners reward. Ideal
if you have difficulty trusting pool owners: You see the pool finding a block? You see a transaction
in your wallet. Usually (if you use a proper wallet), you will receive the transaction notification even
before the pool lists the block as found.
Warning
With the exceptions that the mining reward is split between workers on the pool and the fact
that the pool determines which transactions will be included, using instant payout is very similar
to solo-mining. Instead of mining for the pool's wallet and being compensated for your work afterwards,
(a part of) the mining reward is directly added to the address you are mining towards, using the block's
coinbase transaction. After this the new coins need to mature before you will be able to spend it.
If you are not mining towards a wallet where you control your own private keys and are instead using a
service that holds and manages the coins for you, make sure this service is fully compatible with Garlicoin,
as it seems that some of these services will ignore the fact that you mined coins for them and not properly
accredit these coins to your account.
If in doubt, use daily payout instead, as it will send your coins from a pool-managed P2WSH 'W' address
instead of using coinbase transactions.
This method is also easiest to set up. For the 3 most popular miners,
ccminer,
sgminer and
cpuminer, you would use a command (or BAT file line) that looks something like this:
cpuminer --algo=allium -o stratum+tcp://freshgarlicblocks.net:3032 -u GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxB -p x
Once you are connected and see your first accepted share, your miner should pop up in the
Worker list tab and
Current block estimated payout tab within a minute.
Note
Don't forget to replace GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxB
in the above examples with your own mainnet wallet address
(34 characters long and starting with a G). The example address
is fake and will cause authentication failures if you try to use it.
Yesterday's Garlic: Daily payout
As an alternative to instant payout, we offer daily payout. With daily payout all your mining rewards go to a special personal
consolidation address managed by the pool. Once a day, at 20:00 GMT, the pool will schedule a low-fee
payout from this address to your payout wallet address, thereby combining all your rewards into a single
transaction. The payout transaction will then be processed/confirmed in the next few blocks the pool
finds (typically within an hour).
The idea of this payout method is that it is fully transparent, since everything happens on the blockchain. You can check
your per-block mining reward using the pool's website and verify it to some extend based on your hashrate.
When the pool finds a block you can directly view your mining reward being sent to your consolidation
address on the blockchain. From there, you would notice if anyone (including the pool) tried to steal
it.
Note that all this requires a small fee. This fee is used for the actual consolidation transaction and does not go to the
pool owner. Instead it is handled as any other fee and therefore shared between all the miners on this
pool.
This fee is typically between 0.0% and 0.1%. Fees of 0.01% are normal for standard GPU mining. To get an idea of the consolidation
fee, check the my worker tab.
In order to use daily payouts, follow the same steps as for instant payout, but instead of just using your payout address
as username, prepend it with
daily-.
If we apply this to the examples listed above under instant payout, they would become:
cpuminer --algo=allium -o stratum+tcp://freshgarlicblocks.net:3032 -u daily-GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxB -p x
Tip
If you use the Garlicoin Core GUI (a.k.a. garlicoin-qt), you can import your personal consolidation
address as a watch-only address. That way you will still get a notification whenever the pool find
a block and immediately see your reward. It will also show the consolidation fees as the costs for
a 'Payment to yourself'.
To do this, go to the my workera tab and copy your personal consolidation address. Then go to
Garlicoin Core, choose 'Debug window' from the Help menu, switch to the Console tab and type:
importaddress <address>, where <address> is the
consolidation address you copied from the my worker tab.
Static stratum difficulty
First of all: if you don't know what this is, don't worry. The examples above should be both sufficient
and optimal in almost all scenarios.
Apart from the stratum server on port
3032, which is a vardiff (variable difficulty, tries to make workers send 1 share every 15 seconds
on average), there are a couple of other ports available as well.
URL
Type
Used for
stratum+tcp://freshgarlicblocks.net:3032
Vardiff
Generic purpose, works for any miner
stratum+tcp://freshgarlicblocks.net:3033
Vardiff
Also vardiff, but starts out with diff 4 instead of diff 1
stratum+tcp://freshgarlicblocks.net:3034
Diff 2
GPU mining users that can't use/have
problems with vardiff
stratum+tcp://freshgarlicblocks.net:3035
Diff 16
Higher hashrate mining rigs (up to ~ 50 MH/s)
that can't use/have problems with vardiff
stratum+tcp://freshgarlicblocks.net:3036
Diff 128
High-end mining rigs.
You typically want to use this port instead of vardiff
Pool stats
Current block being mined:
Number of workers:
Estimated current pool hashrate:
Global Garlicoin network hashrate:
Pool's hashrate as percentage:
Pool's luck over last 48 hours:
Blocks vs Hashrate
Pool's luck
Latest blocks mined by the pool
Height
Miner
Status
Workers
Address
Hashrate
Coinbase tx outputs for current block
If a block was found right now, this would be everyone's rewards
Address
Reward
Percentage
Shares
Hashrate
Note on share management
Everyone's shares will decrease by 20% whenever the pool finds a block.
When a worker's shares drops below 5, it will be evicted from the pool.
This is part of the payout management logic in order to keep payout fair
and reduce pool switching.
Workers will not get paid and are not affected by this rule until the
minimum share floor of 15 shares is reached. This is to both reduce dust
outputs and give (very) low hashrate workers a chance to get enough shares
for a proper payout.
Note that this does not mean that the pool takes a fee by decreasing worker shares,
as shares are the only thing on which block reward payout is based. Rather,
this is a way to get workers that stopped mining slowly out of the system
while still giving them something for their work.
It also helps new workers joining to pool to get a little bit extra in times
where the pool is unlucky and can't find a block for a while.
