forked from alexbarrett/freshgarlicblocks-website
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
968 lines (948 loc) · 54.2 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<link href="https://fonts.googleapis.com/css?family=Karla:400,400i,700|Space+Mono:400,700" rel="stylesheet">
<link rel="stylesheet" href="/css/styles.css" />
<link rel="shortcut icon" type="image/png" href="/favicon.png" />
<title>FreshGRLC.NET – The 0% fee, instant payout, Garlicoin mining pool</title>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js"></script>
<script src="/js/highcharts.js"></script>
<script src="/js/main.js"></script>
</head>
<body>
<div class="discord">
<a href="#">
Join us on
<img src="https://assets-global.website-files.com/6257adef93867e50d84d30e2/636e0b5493894cf60b300587_full_logo_white_RGB.svg">
</a>
</div>
<div id="banner">
<h1>FreshGRLC.NET</h1>
<h2>freshgarlicblocks.net</h2>
<div>
The 0% fee, <span data-tooltip="Different to many other pools, we send mining rewards
directly to your wallet the instant they are mined. Your
coins never touch a wallet outside of your control.">instant payout</span>, Garlicoin mining pool
</div>
</div>
<nav>
<ul>
<li class="active"><a href="#poolnews">Pool news</a></li>
<li><a href="#howtomine">How to mine</a></li>
<li><a href="#stats">Pool stats</a></li>
<li><a href="#workers">Workers list</a></li>
<li><a href="#curblock">Current block</a></li>
<li><a href="#myworker">My worker</a></li>
</ul>
</nav>
<div class="nav-flow"></div>
<div id="content">
<div id="content-poolnews" class="contentdiv active">
<article>
<time datetime="2021-05-24" class="date">May 24, 2021</time>
<h3>Update on workers, share management and payout method</h3>
<p>
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.
</p>
<p>
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 <a href="#howtomine"><i>How to mine</i></a>).
</p>
<p>
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.
</p>
<p>
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!
</p>
<p>
Which brings me to this update. Various alterations have been made today to the way the pool handles shares and workers:
</p>
<ul>
<li>
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.
</li>
<li>
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.
</li>
<li>
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.
</li>
<li>
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. <br />
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. <br />
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.
</li>
</ul>
<p>
This is also summarized in the note at the bottom of the <a href="#curblock"><i>Current block</i> section</a>.
</p>
</article>
<article>
<time datetime="2021-04-23" class="date">Apr 23, 2021</time>
<h3>We're back! (+ daily payout system migration)</h3>
<p>
We are back, and how!
</p>
<p>
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 <a href="https://explorer.freshgrlc.net/grlc/difficultygraphs?period=week" target="_blank">increasing by a factor
4</a> as well!<br />
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 href="https://explorer.freshgrlc.net/grlc/pooldistribution?period=day" target="_blank">a quarter of the network hashrate</a> on this pool!
</p>
<p>
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.
</p>
<p>
In the early hours of this morning I migrated the pool to use the new <a href="https://github.com/freshgrlc/freshgrlc-wallet" target="_blank">
FreshGRLC.net Managed Wallet API</a>, 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 <strong>W</strong>.
</p>
<p>
These W-addresses are very similar to normal <strong>G</strong>-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 <a href="https://explorer.freshgrlc.net/grlc/address/GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxC" target="_blank">
on the explorer</a>.<br />
They are also the same as the longer type of addresses that start with <strong>grlc1</strong>. 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.
<br />
But again, you can easily convert them using the explorer as shown above.
</p>
<p>
For more information about W-addresses, see my <a href="https://www.reddit.com/r/garlicoin/comments/8prtxp/as_part_of_my_ongoing_effort_to_develop_stupid/" target="_blank">
original post</a> from back in the day.<br />
Note by the way that <a href="https://insight.garli.co.in/" target="_blank">Insight</a> doesn't support either the W-address format nor the grlc1-address
format and these type of addresses will instead show up as <strong>Unparsed address</strong>.
</p>
<p>
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.
</p>
</article>
<article>
<time datetime="2018-03-24" class="date">Mar 24, 2018</time>
<h3>Service disruption</h3>
<p>
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.
</p>
<p>
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.<br />
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.
</p>
<p>
At about 20:50 UTC all issues had been resolved and the pool did come up.<br />
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 <a href="https://explorer.freshgrlc.net/grlc/address/GgXkk6Y6tMBC5E1zeAw15MpgFiPbDpngHG" target="_blank">reserved address</a>. I will manually pay out this block using the ratios of the next block we found as soon as it matures.
</p>
<p>
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.
</p>
</article>
<article>
<time datetime="2018-03-07" class="date">Mar 07, 2018</time>
<h3>Second major website update</h3>
<p>
As you might have noticed, we have made some major improvements to both the style as well as the general usability of the website.
</p>
<p>
Whereas previously I had just randomly thrown some stuff together, we now actually have someone working on the website who knows what he does.
</p>
<p>
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 :-).
</p>
<p>
We will probably keep making minor modifications in the coming days or weeks and possibly further improving usability and adding features.
</p>
<p>
Finally, I would like to thank <strong>@Antiger#4943</strong> for his voluntary work to make this happen.
Feel free to show your appreciation if you like it!
</p>
<p>
<code>GN3ZqKpUR1h9xvdywQfxyEYZE8oarK2Efp</code>
</p>
</article>
<article>
<time datetime="2018-03-02" class="date">Mar 02, 2018</time>
<h3>Pool unavailable for about 80 minutes</h3>
<p>
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.
</p>
<p>
I did contemplate temporary moving the pool to another server, but decided against it as it would probably take longer to get that up <i>and</i>
get all the miners to move over than it would take to wait for the problem to be resolved.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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 <a href="https://garlicpool.org/index.php?page=gettingstarted" target="_blank">nice example</a> on how you can configure failover in your miner command line (/bat file).
This might actually be useful for everyone mining here.
</p>
</article>
<article>
<time datetime="2018-02-28" class="date">Feb 28, 2018</time>
<h3>Per-worker hashrates</h3>
<p>
For people that have multiple individual mining rigs: we do now support per-worker hashrates on the <a href="#myworker">my worker</a> page.
</p>
<p>
This means that if you use the common format of appending a period ('<em>.</em>') followed by a nickname for you worker
to your username/mining address, you will find it listed by its name on the <a href="#myworker">my worker</a> page,
together with its current and average hashrate.
</p>
<p>
The same information is now also available via the <em>workerinfo</em> API, allowing you to monitor individual workers.
</p>
<div class="card code">
<div class="card-header">
Example formats
</div>
<div class="card-body">
<code>-u GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxB<strong>.GTX1060</strong></code>
<code>-u daily-GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxB<strong>.My_PC</strong></code>
</div>
</div>
</article>
<article>
<time datetime="2018-02-20" class="date">Feb 20, 2018</time>
<h3>Glitch in daily payout processing</h3>
<p>
As a lot of people are probably aware of by now, last night we experienced a glitch in the daily payout processor.
</p>
<p>
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.
</p>
<p>
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).
</p>
<p>
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.
</p>
</article>
<article>
<time datetime="2018-02-16" class="date">Feb 16, 2018</time>
<h3>Daily payments are here!</h3>
<p>
While everyone is anxiously waiting for the hard-fork to occur, we have other big news: By popular demand, we bring you daily
payments!
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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!
</p>
<p>
Want to know more? You will find all the information in the How to mine tab.
</p>
</article>
<article>
<time datetime="2018-02-13" class="date">Feb 13, 2018</time>
<h3>Advised to add --submit-stale to ccminer-tpruvot command</h3>
<p>
From now on we advice any miners on this pool to add
<strong>--submit-stale</strong> 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.
</p>
<p>
Note that changing this setting might decrease your valid share ratio, but you will find more valid shares overall, therefore
receive higher payouts.
</p>
<p>
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.
</p>
<p>
Note that if you are using other mining software or are using the
<i>nanashi</i> ccminer fork, you do not have to change anything.
</p>
</article>
<article>
<time datetime="2018-02-13" class="date">Feb 13, 2018</time>
<h3>Ready for the hard-fork</h3>
<p>
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
<strong>58670</strong>, expected around
<em>19:00 GMT on the 16th</em>.
</p>
<p>
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.
</p>
<p>
We are planning to take the pool offline after block
<strong>58660</strong> 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
<em>
<i>Allium</i>
</em> as soon as block
<strong>58670</strong> is found.
</p>
<p>
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.
</p>
</article>
<article>
<time datetime="2018-02-12" class="date">Feb 12, 2018</time>
<h3>Testnet pool available in preparation for hard-fork</h3>
<p>
In order to allow miners to prepare for the upcoming Garlicoin hard-fork, we made a
<a href="https://testnet.freshgarlicblocks.net">testnet pool</a> available. The testnet has already forked to the new
<strong>Allium</strong> hashing algorithm, so as soon as mining software becomes available you can connect to this pool and test
your new setup.
</p>
<p>
The testnet pool's stratum server is at:
</p>
<code>stratum+tcp://testnet.freshgarlicblocks.net:3032</code>
<p>
Note that sources for
<a href="https://github.com/lenis0012/ccminer/">ccminer</a>
and
<a href="https://github.com/GarlicoinOrg/cpuminer-multi">cpuminer</a> can already be obtained via their respecive github repositories.
</p>
<p>
More information regarding the hard-fork, and how this pool will prepare for and handle the fork, will be announced later
this week.
</p>
</article>
<article>
<time datetime="2018-02-11" class="date">Feb 11, 2018</time>
<h3>More information with regards to hashrate issues</h3>
<p>
This is just a quick heads-up to say I wrote a
<a href="https://www.reddit.com/r/garlicoin/comments/7wvrxx/psa_when_is_a_hash_not_a_hash_or_how_you_should/" target="_blank">reddit post</a>
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.
</p>
<p>
See the post itself for more info.
</p>
</article>
<article>
<time datetime="2018-02-08" class="date">Feb 8, 2018</time>
<h3>Pool hashrate verification test available</h3>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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).
</p>
<p>
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:
<ul>
<li>Your miner is fine, but the pool had a period of bad luck (this is now verifiable using the new luck
graphs).</li>
<li>Your miner is fine, but it itself had a peiod of bad luck (hence it was sending in less shares than
expected).</li>
<li>There is an actual issue with your mining setup and you might be able to tweak it by changing (for
example) intensity settings.</li>
</ul>
</p>
<p>
The page is available through the <a href="#myworker">my worker</a> 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 <em>typically</em>
can't do this remotely), as you will need to verify the pool's share counter using the share counter
within your miner software.
</p>
</article>
<article>
<time datetime="2018-02-07" class="date">Feb 7, 2018</time>
<h3>Pool luck graph fix</h3>
<p>
The pool has been restarted to apply a small fix to the pool's luck data gathering.
</p>
<p>
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.
</p>
<p>
Note that this does not make the luck graphs incorrect, just somewhat imprecise.
</p>
<p>
This issue has now been fixed and new data should no longer have this flaw.
</p>
</article>
<article>
<time datetime="2018-02-06" class="date">Feb 6, 2018</time>
<h3>New website</h3>
<p>
We have a new website layout!
</p>
<p>
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.
</p>
<p>
One of the final changes, and overhaul of this website, is now complete: Have a look around!
</p>
<p>
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.
</p>
</article>
</div>
<div id="content-howtomine" class="contentdiv">
<h3>How to mine on the FreshGRLC.net pool</h3>
<p>
Right now we offer two ways of mining at this pool. Or rather, we offer two types of payment:
</p>
<ul>
<li>Instant payout</li>
<li>Daily payout</li>
</ul>
<p>
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 <a href="https://bitcoin.org/en/glossary/coinbase-transaction" target="_blank">
<i>coinbase transaction</i></a>.<br />
Basically, you are "solo-mining together" and that against 0% fee! Simple and no bamboozle.
</p>
<p>
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.
</p>
<p>
You can choose whichever payment method you like most and configure your worker to use it using the instructions below.
</p>
<div class="card note">
<div class="card-header">
Note
</div>
<div class="card-body">
<p>
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.
</p>
<p>
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.
</p>
</div>
</div>
<h3>Our bread and (garlic-) butter: Instant payout</h3>
<p>
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.
</p>
<p>
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.
</p>
<div class="card note">
<div class="card-header">
Warning
</div>
<div class="card-body">
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</div>
</div>
<p>
This method is also easiest to set up. For the 3 most popular miners,
<em>ccminer</em>,
<em>sgminer</em> and
<em>cpuminer</em>, you would use a command (or BAT file line) that looks something like this:
</p>
<div class="card code">
<div class="card-header">
ccminer
</div>
<div class="card-body">
<code>ccminer-x64 --algo=allium -o stratum+tcp://freshgarlicblocks.net:3032 -u GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxB --max-temp=85 --submit-stale</code>
</div>
</div>
<div class="card code">
<div class="card-header">
sgminer
</div>
<div class="card-body">
<code>sgminer --algorithm allium -o stratum+tcp://freshgarlicblocks.net:3032 -u GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxB -p x -I 15</code>
</div>
</div>
<div class="card code">
<div class="card-header">
cpuminer
</div>
<div class="card-body">
<code>cpuminer --algo=allium -o stratum+tcp://freshgarlicblocks.net:3032 -u GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxB -p x</code>
</div>
</div>
<p>
Once you are connected and see your first accepted share, your miner should pop up in the
<em>Worker list</em> tab and
<em>Current block</em> estimated payout tab within a minute.
</p>
<div class="card note">
<div class="card-header">
Note
</div>
<div class="card-body">
<p>
Don't forget to replace <em>GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxB</em>
in the above examples with your own mainnet wallet address
<br>
(34 characters long and starting with a <em>G</em>). The example address
is fake and will cause authentication failures if you try to use it.
</p>
</div>
</div>
<h3>Yesterday's Garlic: Daily payout</h3>
<p>
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).
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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 <a href="#myworker">my worker</a> tab.
</p>
<p>
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
<em>daily-</em>.
</p>
<p>
If we apply this to the examples listed above under instant payout, they would become:
</p>
<div class="card code">
<div class="card-header">
ccminer
</div>
<div class="card-body">
<code>ccminer-x64 --algo=allium -o stratum+tcp://freshgarlicblocks.net:3032 -u daily-GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxB --max-temp=85 --submit-stale</code>
</div>
</div>
<div class="card code">
<div class="card-header">
sgminer
</div>
<div class="card-body">
<code>sgminer --algorithm allium -o stratum+tcp://freshgarlicblocks.net:3032 -u daily-GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxB -p x -I 15</code>
</div>
</div>
<div class="card code">
<div class="card-header">
cpuminer
</div>
<div class="card-body">
<code>cpuminer --algo=allium -o stratum+tcp://freshgarlicblocks.net:3032 -u daily-GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxB -p x</code>
</div>
</div>
<div class="card note">
<div class="card-header">
Tip
</div>
<div class="card-body">
<p>
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'.
</p>
<p>
To do this, go to the <a href="#myworker">my worker</a>a 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:
<code>importaddress <address></code>, where <code><address></code> is the
consolidation address you copied from the <a href="#myworker">my worker</a> tab.
</p>
</div>
</div>
<h3>Static stratum difficulty</h3>
<p>
First of all: if you don't know what this is, don't worry. The examples above should be both sufficient
<i>and</i> optimal in almost all scenarios.
</p>
<p>
Apart from the stratum server on port
<em>3032</em>, 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.
</p>
<table>
<thead>
<tr>
<th>URL</th>
<th>Type</th>
<th>Used for</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<span class="stratumurl" id="stratumurl1">stratum+tcp://freshgarlicblocks.net:3032</span>
</td>
<td>Vardiff</td>
<td>Generic purpose, works for any miner</td>
</tr>
<tr>
<td>
<span class="stratumurl" id="stratumurl2">stratum+tcp://freshgarlicblocks.net:3033</span>
</td>
<td>Vardiff</td>
<td>Also vardiff, but starts out with diff 4 instead of diff 1</td>
</tr>
<tr>
<td>
<span class="stratumurl" id="stratumurl3">stratum+tcp://freshgarlicblocks.net:3034</span>
</td>
<td>Diff 2</td>
<td>GPU mining users that can't use/have
<br />problems with vardiff</td>
</tr>
<tr>
<td>
<span class="stratumurl" id="stratumurl4">stratum+tcp://freshgarlicblocks.net:3035</span>
</td>
<td>Diff 16</td>
<td>Higher hashrate mining rigs (up to ~ 50 MH/s)
<br /> that can't use/have problems with vardiff</td>
</td>
</tr>
<tr>
<td>
<span class="stratumurl" id="stratumurl5">stratum+tcp://freshgarlicblocks.net:3036</span>
</td>
<td>Diff 128</td>
<td>High-end mining rigs.
<br />You typically want to use this port instead of vardiff</td>
</td>
</tr>
</tbody>
</table>
</div>
<div id="content-stats" class="contentdiv">
<div class="stats">
<div>
<h3>Pool stats</h3>
<table>
<tr>
<th>Current block being mined:</th>
<td class="currentblock"></td>
</tr>
<tr>
<th>Number of workers:</th>
<td class="workers"></td>
</tr>
<tr>
<th>Estimated current pool hashrate:</th>
<td class="poolhashrate"></td>
</tr>
<tr>
<th>Global Garlicoin network hashrate:</th>
<td class="globalhashrate"></td>
</tr>
<tr>
<th>Pool's hashrate as percentage:</th>
<td class="poolhashratepercent"></td>
</tr>
<tr>
<th>Pool's luck over last 48 hours:</th>
<td class="poolluck"></td>
</tr>
</table>
</div>
<div>
<h3>Blocks vs Hashrate</h3>
<div id="graph_blkhash"></div>
</div>
<div>
<h3>Pool's luck</h3>
<div id="graph_luck"></div>
</div>
<div>
<h3>
Latest blocks mined by the pool
</h3>
<table id="blks">
<thead>
<tr>
<th>Height</th>
<th>Miner</th>
<th>Status</th>
</tr>
</thead>
</table>
</div>
</div>
</div>
<div id="content-workers" class="contentdiv">
<h3>Workers</h3>
<table id="workerslist">
<thead>
<tr>
<th>Address</th>
<th class="numeric">Hashrate</th>
</tr>
</thead>
</table>
</div>
<div id="content-curblock" class="contentdiv">
<header>
<h3>Coinbase tx outputs for current block</h3>
<p class="subtitle">If a block was found right now, this would be everyone's rewards</p>
</header>
<table id="cbout">
<thead>
<tr>
<th>Address</th>
<th class="numeric">Reward</th>
<th class="numeric">Percentage</th>
<th class="numeric">Shares</th>
<th class="numeric">Hashrate</th>
</tr>
</thead>
</table>
<h3>Note on share management</h3>
<p>
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.
</p>
<p>
This is part of the payout management logic in order to keep payout fair
and reduce pool switching.
</p>
<p>
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.
</p>
<p>
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.
</p>
</div>
<div id="content-myworker" class="contentdiv">
<div id="genericworkerheader">
<h3>Worker <span class="currentworker"></span></h3>
<ul class="actions">
<li><a href="#" onclick="event.preventDefault(); refreshWorker();">Refresh</a></li>
<li><a href="#myworker" onclick="setAsMyWorker()">Set as my worker</a></li>
</ul>
</div>
<div id="myworkerheader">
<h3>My worker</h3>
<ul class="actions">
<li><a href="#" onclick="event.preventDefault(); refreshWorker();">Refresh</a></li>
</ul>
</div>
<div id="nomyworker">
You have not yet selected a worker as your own. Click on your worker address in the
<em>Workers list</em> tab and select
<em>Select as my worker</em>.
</div>
<div id="workerinfo">
<table>
<tr>
<th>Payout type:</th>
<td id="workerinfo_payout_type"></td>
</tr>
<tr>
<th>Payout address:</th>
<td>
<a href="#" target="_blank" id="workerinfo_address"></a>
</td>
</tr>
<tr>
<th>Consolidation address:</th>
<td>
<span class="dailypayoutworker">
<a href="#" target="_blank" id="workerinfo_consolidationaddress"></a>
</span>
<span class="na instantpayoutworker"></span>
</td>
</tr>
<tr>
<th>Next mining reward:</th>
<td id="workerinfo_payout"></td>
</tr>
<tr>
<th>GRLC waiting for payout:</th>
<td>
<span class="workerinfo-info dailypayoutworker" id="workerinfo_consolidated"></span>
<span class="na instantpayoutworker"></span>
</td>
</tr>
<tr>
<th>Estimated payout fee:</th>
<td>
<span class="workerinfo-info dailypayoutworker" id="workerinfo_consolidatefee"></span>
<span class="na instantpayoutworker"></span>
</td>
</tr>
<tr>
<th>Hashrate (average):</th>
<td>
<span id="workerinfo_hashrate_avg"></span>
<span id="workerinfo_check_hashrate_cont">
<br>
<a id="workerinfo_check_hashrate" href="#" target="_blank"> Run hashrate verification test</a>
</span>
</td>
</tr>
<tr>
<th>Hashrate (current):</th>
<td id="workerinfo_hashrate_cur"></td>
</tr>
<tr>
<th>Valid shares percentage:</th>
<td id="workerinfo_validsharepercent"></td>
</tr>
<tr>
<th>Last seen:</th>
<td id="workerinfo_lastseen"></td>
</tr>
<tr>
<th>Blocks solved:</th>
<td id="workerinfo_blocks"></td>
</tr>
</table>
<h3>Hashrate by worker name</h3>
<table id="workerinfo_workerslist">
<thead>
<tr>
<th>Worker name</th>
<th>Current</th>
<th>Average</th>
</tr>
</thead>
</table>
<div id="workerinfo_blockslist">
<h3>Solved blocks list</h3>
<ul></ul>
</div>
</div>
</div>
</div>
<div id="footer">
<ul>
<li>
<span class="label">Network:</span>
<span class="value globalhashrate"></span>
</li>
<li>
<span class="label">Pool:</span>
<span class="value">
<span class="poolhashrate">-</span>
<span class="muted">/</span>
<span class="poolhashratepercent">-</span>
</span>
</li>
<li>
<span class="label">Workers:</span>
<span class="value workers"></span>
</li>
<li>
<span class="label">48-hour luck:</span>
<span class="value poolluck"></span>
</li>
</ul>
</div>
<div class="overlay" style="display: none;">
<iframe src="https://discordapp.com/widget?id=404767431685308417&theme=dark" width="350" height="500" allowtransparency="true"
frameborder="0"></iframe>
</div>
</body>
</html>