forked from w0utje/WavesLPoSDistributer
-
Notifications
You must be signed in to change notification settings - Fork 7
/
CHANGELOG.txt
832 lines (653 loc) · 32.8 KB
/
CHANGELOG.txt
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
/* =====WAVES====WAVES====WAVES====WAVES====WAVES====WAVES====WAVES====WAVES====WAVES====WAVES===WAVES====WAVES====
*
* This is Plukkie's version of the LPoSDistributor script, a revenue sharing application for the WAVES blockchain
* Many thanks to original version of Marc Jansen and the fork of W0utje.
*
* I call this version "The lazy one', due to the automated nature. Only edit once when you install , no more.
*
* I do not have any worth mentioning coding experience. In my daily job, I am a hardcore network architect.
* But I was always inspired by application programming and network automation. I am lazy and like to automate.
* With my analytic skills I decided to put some effort in javascript and figure out how the original script works.
* And came to the conclusion that it is worth to make it more 'lazy' style of paying out transaction fees.
* I am a strong believer of decentralized banking and I like blockchain and you're never to old to learn stuff.
* Hope you forgers enjoy my contribution to the community.
*
* Donations are welcome if you like this version of the script: 'The lazy one'
* - you can DONATE Waves to alias 'donatewaves@plukkie' or address '3PKQKCw6DdqCvuVgKtZMhNtwzf2aTZygPu6'
* - you can LEASE your Waves to alias 'plukkieforger' or 'plukkieleasing' or address '3P7ajba4wWLXq6t1G8VaoaVqbUb1dDp8fm4'
*
* Thank you and Enjoy!
*
/* =====WAVES====WAVES====WAVES====WAVES====WAVES====WAVES====WAVES====WAVES====WAVES====WAVES===WAVES====WAVES====
Version 4.1.4
---------------
- date 16 march 2022
- NEW FEATURES
- Added support for one asset of choice to be payed by masstx.js tool
The asset can be added to the wavesleaserpayoutX.json file as below example;
[
{
"amount": 1000000,
"fee": 100000,
"assetId": "Atqv59EYzjFGuitKVnMRk6H8FukjoV3ktPorbEys25on",
"sender": "3P7ajba4wWLXq6t1G8VaoaVqbUb1dDp8nm9",
"attachment": "USkz6M7kM8X2vR89LHm48WnUK3YdBWV55W4RJ92y8jbV1XviPSzbTCdXWxtx",
"recipient": "3P1zdekqXGZ5zokGroupT42L6jV7t9ixBNM",
"pay" : "yes"
}
]
This feature was requested and funded by [WavesFunnnyNode](https://wavesfunnynode.com/).
Allthough this code was not maintained anymore, I decided to help out and I implemented
the feature. They also want the change to be merged into the master branch.
NOTE
Allthough masstx.js uses the asset that is configured in config.json, you need to
deliver yourself on the wavesleaserpayoutsX.json file with the amounts for the recipients.
There was no need for WavesFunnyNode to have it added to appng.js tool, to have the
assetid amounts automatically added.
- File changes (+ added, - removed, * updated)
* masstx.js
* config.json
* CHANGELOG.txt
* README.md
Version 4.1.3
---------------
- date 4 aug 2021
- Added some Q/A's to FAQ chapter
- Changed textual output in wavesleasingreport.html from node name to service name
- FIXES
- masstx validation of transactions failed.
Cause:
node.js module sync-request did not honor web port used in the GET request.
It always used port 80, allthough another port was configured in "querynode_api"
solved: migrated away from sync-request to module axios
- ROADMAP
- Migrate deferred library 'request' to a new library
- incorporate airdrop tool
- Release docker container version of WavesLPOSdistributer
- Developing WLDaaS
- Add manual option 'signing' of failed mass transaction which is not send within the
expiry interval (currently 12 mins)
- File changes (+ added, - removed, * updated)
* masstx.js
* package.json
* CHANGELOG.txt
* README.md
Version 4.1.2
---------------
- date 11 Jul 2021
- Added FAQ chapter in README
This answers most asked questions and problems that could occur
- FIXES
- masstx only send the first payment succesfully of a masstransaction that had more
the 100 recipients. The subsequent signing requests were rejected. This was because
the maximum of 100 was not subtracted from the subsequent transfers.
This applied to v3.2.1.1 - v4.1
- Added node package 'readline-sync' in package.json
This is used in masstx and was not installed with npm install.
Needed manual install with 'npm install readline-sync'
- ROADMAP
- Migrate deferred library 'request' to a new library
- incorporate airdrop tool
- Release docker container version of WavesLPOSdistributer
- Developing WLDaaS
- Add manual option 'signing' of failed mass transaction which is not send within the
expiry interval (currently 12 mins)
- File changes (+ added, - removed, * updated)
* masstx.js
* package.json
* CHANGELOG.txt
* README.md
Version 4.1
---------------
- date 07 Jul 2021
- OPTIMIZED MEMORY USAGE, HUGE IMPROVEMENT !
------------------------------------------
This version has a huge improvement in the way the collector appng.js consumes the available memory.
In previous versions if your VM is low on memory (like 4GB),
the appng.js would crash if you would collect to much blocks in one run.
With this release, the collector requests and analyzes in batches of 100 blocks and
then only stores the relevant blocks. In previous versions if you would collect 20000 blocks
then the collector would store all 20000 blocks, analyze them and add some relevant data.
The memory usage would increase if the blockwindowsize increased and if the VM is
low on memory the collector would crash.
While this was solved by lowering the blockwindowsize in the config.json file and spreading
your collector sessions over multiple, it wasn't optimal.
With this release you can run collector runs with large blockwindowsizes. I succesfully collected
150000 (150k !!) blocks in one run on a VM with only 8GB of memory.
usage:
Set your desired value in config.json for key : "blockwindowsize" : "Your desired value".
I.e, set to 15000 and appng.js will collect 15000 blocks in one go without problems! :-)
NOTE
If you change it in the config.json file, the next collector run will still use
the value of 'paystopblock' in the batchinfo.json file. Subsequent runs use config.json value.
- NEW FEATURES
------------
1. Recovery option for partly failed masstransactions (masstx.js)
Added option to do a manual resend of a failed masstransaction.
It can happen that a masstransaction fails.
A payment works as follows;
The payment processor masstx, does a signing request for a transaction.
The node signs the request and sends the signed respons to the masstx script.
This data is saved in masstx-signed-<batch>-<subid>.json in the event of failure.
If a transaction fails, an alert is raised and the signed file name is reported to
screen and social meda (if turned on in config.json).
Now you can start the payment as follows: node masstx <signed file>
This will resend the specific masstx transaction that failed.
NOTE
Be sure to resend within 12 mins else the node will reject based on the timedstamp.
2. Added telegram alerting when payments fail
3. Added key "servicename" : "value" in config.json
This value is used in reports and logging. Use a meaningfull name of your waves service.
4. config key "nodename" : "value" is used in alerts
If you have multiple waves nodes, it becomes clear which node send the alert
- ROADMAP
- Migrate deferred library 'request' to a new library
- incorporate airdrop tool
- Release docker container version of WavesLPOSdistributer
- Developing WLDaaS
- Add manual option 'signing' of failed mass transaction which is not send within the
expiry interval (currently 12 mins)
- File changes (+ added, - removed, * updated)
* appng.js
* masstx.js
* txoptimizer.py
* config.json
* CHANGELOG.txt
* README.md
Version 3.2.1.3
---------------
- date 30 June 2021
- OPTIMIZED LOGGING OUTPUT OF VARIOUS ELEMENTS
------------------------------------------------------
1. appng,js adds type8, type9 and type16 keys to json output file of the collector run
If the collector finds a type16 lease or leaseCancel transaction,
it will add JSON info to collector file : "type" : 16
Now you can see if a lease or leasecancel was initiated by its transaction type.
2. appng.js adds node generating balance to logfile of the collector run
3. txoptimizer.py adds node generating balance to logfile of the collector run
4. appng.js adds total # of leasers to logfile of the collector run
5. txoptimizer.py adds total # of leasers to logfile of the collector run
- UPDATED README.md
------------------------------------------------------
Explanation of "paymentnode_apikey" updated.
Old explanation: "The API key of your forging node. This key is"
"also configured in the configuration file of your"
"Waves node configurtion file."
New explanation: "The API password of your forging node."
"Put it as PLAINTEXT in the config.json file!"
"Else the payments will fail."
"NOTE"
"This is the same password you need to use in the"
"configfile of your Waves forging node, but needs to"
"be coded as base58 string in the node config."
- NOTES
- In Waves fullnode release 1.3.5 were some major changes introduced.
Some API's were changed and this caused payment failures.
Use waves fullnode release >= 1.3.6 and WavesLPOSdistributer works
again without failures.
The errors were caused by waves node changes and not by WavesLPOSdistributer.
- ROADMAP
1. Optimizing appng.js collector code to use less memory while collecting
2. Release docker container version of WavesLPOSdistributer
3. Developing WLDaaS
- File changes (+ added, - removed, * updated)
* appng.js
* txoptimizer.py
* CHANGELOG.txt
* README.md
Version 3.2.1.2
---------------
- Merged to release 3.2.1.3
Version 3.2.1.1
---------------
- data 4 June 2021
- BUGS solved
------------------------------------------------------
- Waves full node software had some API changes.
/leasing/active/{address} returns an array of structures containing lease parameters instead of array of Lease transactions.
This impacted informational tool nodeinfo.py
- File changes (+ added, - removed, * updated)
* nodeinfo.py
* CHANGELOG.txt
* README.md
* config.json
Version 3.2.1
-------------
- date 31 May 2021
- Change on collector appng
------------------------------------------------------
- you can start appng.js now with argument /now or now: "node appng now"
If will force the collector to lower the "paystopblock" from the
batchinfo.json file to the current blockheight of the blockchain, minus 1.
This is only done if the paystopblock lies in the future.
Now you don't have to wait till the blockchain reached your original
paystopblock.
If you do not add argument 'now', the behavior is just the same as
before, that is, report how long to wait before paystopblock is reached
and exit.
kudos to user ddaqua6 for the usefull request!
I make use of it thankfully myself :-)
- Change on start_collector.sh
------------------------------------------------------
- Added argument option to start collector with:: start_collector.sh /now
see above explanation at collector change.
- File changes (+ added, - removed, * updated)
* appng.js
* CHANGELOG.txt
* README.md
* start_collector.sh
Version 3.2
-------------
- data 14 may 2021
- Changes on core functionality collector script appng.js
-------------------------------------------------------
In waves full node version 1.3 the developers added stateChanges;
In this version, after activation of feature #16 “Ride V5, dApp-to-dApp invocations”,
the Lease and LeaseCancels script actions are added.
Therefore, a lease can be created and canceled as a result of an Invoke Script transaction.
The appng.js module has been modified to incorporate this functionality in the collection
of the lease and leasecancel transactions.
In this version of the lpos toolset the transaction type 8, 9 and 16 are analyzed.
- Some minor changes for key/values that moved out of appng.js into config.json
- File changes (+ added, - removed, * updated)
* appng.js
* config.json
* CHANGELOG.txt
* README.md
Version 3.1.1
--------------
- date 1 may 2021
- Changes
1. Masspayment tool 'masstx.js'
- The tool now requests signing for every transaction. This will return a signed json body with a proof.
Previous versions has a fixed proof string.
- The tool now dumps the payment data for every mass transaction in JSON format to a file.
This is a failsave if the payment crashes.
Reason for this is if a crash or payment failure occurs, it is easier to check and resend the payment.
First a 'sign' file is logged with the json data that needs to signed by the node. This is a POST request.
The body respons is the 'signed' data and is logged to the 'signed' file.
The log is as follows:
Suppose the batchid of the payment is 50. There are 250 leasers. At max 100 transactions currently are
supported in a mass transaction. The payment for this batch will be spread over 3 mass transactions.
Masstx will log six files in the paymentsdone directory (default paymentsDone/ ) :
- masstx-sign-50-1.json
- masstx-signed-50-1.json
- masstx-sign-50-2.json
- masstx-signed-50-2.json
- masstx-sign-50-3.json
- masstx-signed-50-3.json
If for some reason a mass transfer fails, you can resend it manually with curl or postman.
The JSON for the body would be the masstx-signed file. The anatomy of the POST request would have
the following details;
- POST url : http://localhost:6869/assets/masstransfer
- json: the masstx-signed-<failed (sub)batch>.json
- headers: { "Accept": "application/json", "Content-Type": "application/json", "api_key": <your API key> }
2. Config.json
- Added key/values for mass transaction signing and transaction broadcasting API urls
- "txsbroadcast" : "/transactions/broadcast",
- "masstxsignapisuffix" : "/transactions/sign",
3. Forktester.py
- Checks if a control node unreachable alert is already send to telegram.
Previous versions keep on sending alerts after every forktest.
Now a file for node-unreachable is logged and only one alert is send.
When the node is reachable again, the file is removed and a clear message is send.
- File changes (+ added, - removed, * updated)
* config.json
* CHANGELOG.txt
* README.md
* masstx.js
* forktester.py
Version 3.1
-------------
- date 7 feb 2021
- New features
1. Added tool nodeinfo.py
This tool shows information about your node and wallet;
- overview or detailed info (--help for more info)
- node software version
- leasers
- peer connections
- Waves balances
- Top leasers
- Block with the oldest active leaser
- Changes
1. Payreport layout changed.
The date and time of the startblock and stopblock is now shown.
2. Config.json file has api_uris added for the new nopeinfo.py
utility.
- File changes (+ added, - removed, * updated)
+ nodeinfo.py
* config.json
* txoptimizer.py
* CHANGELOG.txt
* README.md
Version 3.0.1
-------------
- date 17 january 2021
- Bug fixes
1. forktester.py
The function to automatically rollback was commented out. This does not result in rollback, allthough
the config option "auto_rollback" was possibly set to 'yes' in the config.json file.
2. README.md
Textual changes and optimizations after review the file.
- File changes (+ added, - removed, * updated)
* forktester.py
* CHANGELOG.txt
* README.md
Version 3.0
-------------
- date 16 january 2021
- New features
1.Added tool Forktester (forktester.py)
Forktester can be used to manage if your node is on fork.
It uses controlnodes which are used to compare block headers between your node and the control nodes.
Forktester requests 5 blocks (counting from lastblock-2) and compared these blocks between your node
and the controlnodes defines in the config.json file.
Forktester integrates alerting via Telegram. If problems are found (like a fork), alerting is send
to your telegram account. Rollback can be activated also via forktester.
Forktester uses settings from config.json.
For best fork control, execute forktester.py periodically from a job sceduler, like crontab.
For more help, execute : forktester.py --help
2.Added tool Open API node discovery (openapinodes.py)
This tool will try for all your connected peer nodes, if they have a reachable API server.
The purpose of openapinodes.py script is to reveal nodes which can be used by the forktester.py
script. Open nodes can be added to the config.json file. The Forktester tool (new feature 1.)
is an optional extension to use to forktester.py. Both tools can work independently.
openapinodes.py only needs to be used if you want to find nodes that are open for an API call.
If you selected some controlnodes and pushed them into the config.json, you only need to run
the node discovery tool if control nodes disappear from the blockchain or you receive alerts
from Forktester that control nodes are often out of sync with your node.
- File changes (+ added, - removed, * updated)
+ forktester.py
+ openapinodes.py
* CHANGELOG.txt
* config.json
* README.md
Version 2.3.6
-------------
- date 4 october 2020
- fixed sharing percentage calculation
In previous version you could set sharing percentages as follows;
- "feedistributionpercentage" = F%
- "blockrewarddistributionpercentage" = B%
This would set the % that would be shared for the transactions fees and for the blockreward separately.
However, it turned out that the feedsitribution percentage would also be calculated on top of the blockreward percentage.
This would give undesired percentage and to low sharing results. In this release that is fixed.
Suppose, you would set in the config file 80% for fee sharing and 90% for blockreward sharing and
you had 2 blocks forged and the fees in total were 0.5 waves and the blockreward at current is 6 Waves per block.
The waves amount what would be shared amongst all leasers would be:
Waves to share : ( 0.5 x 0.8 ) + ( 12 x 0.9 ) = 11.2 Waves
- Changed some textual output in reports and stio on screen
- Files updated
- config.json
- appng.js
- CHANGELOG.txt
Version 2.3.5
-------------
- date 24 august 2020
- Added blockreward sharing percentage
In config.json you can now set percentage you want to share with your leasers from the blockreward value.
The blockreward was added to the Waves blockchain as an added incentive op top of the fee sharing from
the transaction. Blockreward can be changed by voting from the miners and currently is 6 Waves.
- Files updated
- appng.js
- txoptimizer.py
- README.md
- config.json
- CHANGELOG.txt
Version 2.3.4
-------------
- date 05 december 2019
- After payments have been executed by masstx tool, it creates a socialmedia update file.
This is a summary of the payments, forged blocks and the url where to pickup the html report.
The file can be used by other tools to post on media like facebook, twitter or
telegram.
- The social media file can be copied to a local folder or to Cloud provider AWS.
The settings you need to fill out in the config.json file.
See README file for explanation
- Files updated
- masstx.js
- CHANGELOG.txt
- README.md
- config.json
Version 2.3.3
-------------
- date 28 november 2019
- appng and masstx now create a .run file at start. At succesfull termination files are deleted by the tools
At startup the tools check existence of the runtime locks and alert that they existed abnormally.
- Files updated
- appng.js
- masstx.js
- CHANGELOG.txt
Enjoy!
Version 2.3.2
-------------
- date 24 november 2019
- checkPaymentsFile.js now notifies when it is usefull to use txoptimizer.py tool before payment
- masstx.js now is protected against abormal termination. It will notify when started next time
- README.md is updated with a full automatic crontab to collect, validate, optimize and pay.
See README.md for details.
- Files updated
- masstx.js
- CHANGELOG.txt
- README.md
- checkPaymentsFile.js
Enjoy!
Version 2.3
-----------
- date 16 november 2019
- For a fresh install, please refer to README.md for all necessary steps to get you up and running.
It will take you about 1 hour to set parameters and get you started!
This version introduces some nice enhancements and Cloud integration!
- added automatic html report upload to an AWS s3 bucket or a local file destination.
This way you can present your reports automatically to your users.
See README.md for details how to setup the config.json values
- html report enhancements;
- The reports now shows the date when it was created by the appng tool.
- now shows total of no payout recipients and amounts not payed
- The fee sharing percentage is visible on top of the reports
- logfiles extended with fee sharing percentage
- Files updated
- appng.js
- masstx.js
- CHANGELOG.txt
- README.md
- config.json
- txoptimizer.py
Version 2.2
-----------
- date 10 november 2019
- For a fresh install, please refer to README.md for all necessary steps to get you up and running.
It will take you about 1 hour to set parameters and get you started!
- This version introduces two major changes and some minor textual changes.
1. collector tool (appng.js) adds new json data key 'pay'
When the collector session has finished, the payout data for all recipients
is saved to a json file. If there are 'nopayoutaddresses' defined in the configfile,
then these recpients are not saved in the json file and their statistics are lost.
This release adds a new json key 'pay' to the data for every recipient.
Its value will be 'yes' if recipient gets payed and 'no' if it's a 'nopayout' address.
Default it will be 'yes' for every recipient written to file.
With this change, the 'nopayout' will be kept per job. It also shows more statistics
when the other tools run (total amounts and 'nopayout' amount).
Below a sniplet of the json data with the new key 'pay':
{
"amount": 2117004766,
"attachment": "USkz6M7kM8X2vR89LHm48WnUK3YdBWV55W4RJ92y8jbV1XviPSzbTCdXWxtx",
"fee": 100000,
"pay": "no",
"recipient": "3PVBCT68cGMgodHuuXu3qftDx8M8s8mgOhj",
"sender": "3P6qjba4wWLXq6t1G8VaoaVqbUb1dDp8mf1"
},
NOTE
The change is backwards compatible with older json files, that do not have the 'pay' key.
All recpients found in the json data without the 'pay' key, will be assumed 'yes'.
2. Added new tool 'txoptimizer.py' to optimize multiple pending payment jobs
When a collector run has finished, the payment data is written to file,
waiting in the queue to get payed by the masstx tool.
However, if you execute more collector runs before you do your payments, you will
have multiple pending payment jobs in the queue. Allthough you can perfectly
execute the payments with masstx, you will execute a masstransaction for every job
in the queue. This is inefficient and more costly. This can be optimized by using
the 'txoptimizer.py' tool before you do you your payments.
Just start the 'txoptimizer.py' tool and it will merge all the json data of the
pending payments in one json file. It automatically backups original data and writes
new data and logfiles. It also shows old and new statistics for the pending job.
NOTE
- runtime python3
- Files updated
- appng.js
- checkPaymentsFile.js
- massPayment.js
- masstx.js
- CHANGELOG.txt
- README.md
- config.json
- Files added
- txoptimizer.py
Version 2.1
-----------
- date 12 october 2019
- Please refer to README.md which necessary steps to take to get you up and running.
It will take you about 1 hour to set parameters and get you started!
- This version is adapted to the feature 14 activation (Block Rewards and Community Driven Monetary Policy)
Feature 14 has been activated at block 1740000 in the Waves blockchain.
This change increases currently the block rewards with 6 Waves (initial voted by Miners).
The rewards of Mrt (miner reward token) is therefore deprecated due to this policy change.
- Changes in configurationfile 'config.json'
- added separate variable for paymentnode "paymentnode_api". This is the node which is used by the payment scripts.
Now you can use a different node to for payment transactions and another one for collector requests. The latter is
used by the appng.js script.
You can also use the same node offcourse.
- changed variable 'querynodeapikey' to 'paymentnode_apikey'.
Pay attention if you upgrade to this new version, to map your current configfile values according this change!!
- changed README.md file accordingly and optimized some text
- Files updated
- config.json
- appng.js
- massPayment.js
- masstx.js
- CHANGELOG.txt
- README.md
Version 2.0
-----------
- date 01 februari 2019
- Please refer to README.md which necessary steps to take to get you up and running.
It will take you about 1 hour to set parameters and get you started!
- Added centralized configuration file 'config.json'
Now you only have to change values once if you want to change behaviour.
See README.md for a description of all variables.
All script files consume these values when started by reading this file.
- If the collector script starts for the first time and hence, it does not find the file 'batchinfo.json',
then it uses the blockvalues that you configured in the config.json file.
After the first run, the batchinfo.json file is created and periodically updated and used for subsequent runs.
- added bash script 'start_checker.sh' as simplified starter for your 'node checkPaymentsFile.js'
The script will just execute 'node checkPaymentsFile.js' for you. That's why this is the 'lazy' version
- changed README.md file accordingly and optimized some text
- Files updated
- appng.js
- checkPaymentsFile.js
- massPayment.js
- masstx.js
- CHANGELOG.txt
- README.md
- Files added
- config.json
- start_checker.sh
Version 1.2
-----------
- date 28 december 2018
- Added masstransfer support with script 'masstx.js'
You can now choose to do payments with masstransfers, which optimizes your transfer costs for the payments.
Masstransfer is a type 11 transaction which can be done for one asset at once (like Waves or Mrt). It adds
up to 100 recipients and their fee amounts in one massive transaction. The cost depends on the total transactions
added, but is already benefitial if you have only a couple of transactions. The exact amount depends if you only pay
Waves or also Mrt and depends on the number of transactions. But no worries, if you run the payment checker
with the 'node checkPaymentsFile.js', you get a nice overview of the payments to do and the cost involved if
you were to pay with single transaction or with masstransfers.
You can interchangelly keep on using single transactions or mass transfers. Use payment check tool to calculate
for you which is cheapest.
- If masstransfer is used for payments, it appends the transactionlog to the logfile of the current batch, which
was created earlier by the collector tool 'appng.js'
NOTE:
This is not the case for single transactions. Sorry for that, but my time is scarse and it seems that 9 out of
10 times masstransfer will be used. Maybe in future updates I'll append it also for single transactions. Anyway
it's only handy for reference in a later stage and not really needed.
- Possibility to start masstransfers after a crash or after payment disruption is not ported for now.
With the existing single transaction tool (massPayment.js), every transaction is printed on the screen with
a number. After a crash, you have the option to start it, just from where it crashed. However, with masstransfers
you have a duration optimization. Imagine you have 128 transactions to do. If you were to pay with the single
transaction tool (massPayment.js), it would take 128 txs, 1 sec per txs, total 2 minutes and 8 secs.
If you would pay with masstransfers (masstx.js), it would take 2 masstxs, 1 sec per masstxs, totals 2 secs :-)
Chances of a crash at this perticular short moment is low.
- checkPaymentsFile.js tool now shows costs for single transactions and for mass transfers
- Files updated
- CHANGELOG.txt
- checkPaymentsFile.js
- README.md
- Files added
- masstx.js
Version 1.1
-----------
- date 8 november 2018
- Added queueing mechanism, that stores a batchID for every collection session when finished
Collector sessions ('node appng.js OR start_collector.sh') are added to a payment queue file (payqueue.dat) when finished.
This way you can run session after session, without doing immediate checks or payments if you like. Every session
is written with it's batchID to the queue file and the payoutinfo is logged to payoutfiles with it's batchID added
to the filenames.
The checkPaymentsFile.js script for checking and the massPayment.js for actual payments automatically scans the
queue file and sequentially do their respective jobs with a nice screen print of results
- Checking payments with checkPaymentsFile.js now automatically scans the payqueue.dat file and ends with the sum of
all payment jobs. This way you get an idea of the total payments that will be done
- Removed the fee calulation for tokens rbx, mer and bearwaves from the script (sorry w0utje).
Due to the feature 'sponsored coins' this is obsolete.
- Added various error handlers, to avoid script crashes or detect when people would edit files by hand
- like no payqueue.dat file
- duplicate batchIDs would be detected (this only happens if you would modify the batchinfo.json by hand,
which normally is not needed at all)
- missing batchinfo.json file
- missing directory where succesfull payout files will be stored (it's autmatically created then)
- detect when the payment stop block is larger then the current blockheight of the blockchain
- and more...
- MassPayment.js is now modified to handle a crashed session, if the payqueue has multiple jobs.
If a massPayment session crashed, just make note of the batchID and the last succesfull transaction counter,
and edit the variables const crashconfig = {
=> batchidstart: '0',
=> transactionstart: '0' }
Change the numbers in the massPayment.js file and start the massPayment session again and you should be fine.
NOTE: The transactionstart nr should be the last succesfull number + 1
- MassPayment.js:
- After succesfull ending of all transactions of a batch, the batchID is removed
from the payqueue.dat
- After succesfull ending of all transactions of a batch, the leaserpayout and logfiles are moved
to the folder paymentDone/
This gives you the possibility to check afterwards payment jobs with logs.
- automatically created a backup of the payqueue.dat file, which holds all payment batches
- Added CHANGELOG.txt to track changes to the versions of the script
- Added various minor cosmetic errors of the script
================================================================================================================
* V 1.0
* Plukkie's edit of W0utjes's LPoSDistributor V 2.0.3
*
* CHANGES
* - Created seperate batchinfo.json for initial key/value pairs, which are updated after a successfull run
* After each succesfull run the following XXXXX values are updated;
* "paymentid": "XXXX",
* "paystartblock": "XXXXX",
* "paystopblock": "XXXX",
* The difference between paystart/paystop block will be the blockwindowsize setting
*
* - Possibility to set blockwindowsize = X, where X defines how many blocks will be scanned for payments
*
* - Possibility to set wallet addresses in the variable 'nofeearray [ ];' which will NOT get revenue sharing.
* This can be used if you are rewarded with leases, which do not expect payout from you
* Default it's empty, so all incoming leasers get revenue sharing
*
* - Added paymentid which complements the '<leaserpayoutfilename> + <paymentid>' to make the payoutfiles unique to every session.
* All files are stored now and actual payouts with masspayment script can be done for every unique payout files
*
* - Added logfile creation after a succesfull session which summarizes relevant info, which can be used for reference or analysis
* This is the '<leaserpayoutfilename>.log'
*
* - Added bash script 'start_collector.sh' which optimizes some runtime variables of 'node' binary
* This can be used if regular execution of the appng.js script gives problems and terminates with errors
* ================================================================================================================= */