This will address #886. Long rounds can cause a system to become
very unresponsive due to high SQL/IO load when doing cleanups of
shares and archived tables.
* Run DELETE from shares with LIMIT
* Run DELETE from shares_archive with LIMIT
* Configure DELETE behaviour via config file
* Only archive shares that are really required (PROP, PPS)
Should greatly improve round ends on PROP and PPS after large rounds,
also improves PPLNS though archving will still take some time unless
we limit the share amount artificially. Shares could be needed though,
so we don't.
This will lock a user account if a password or PIN has been entered
wrong for multiple times in a row. When unlocking the account via admin
panel, both counters are reset so the user can log in again.
This should fix issues with brute force attacks to access user accounts.
Please see configuration dist file for new config options.
Please import SQL upgrade 007 to add new column to user accounts table.
Addresses #670 and should be merged once tested.
This will suspend any dashboard updates if the system load exceeds a
configurable threshold. Graphs will not update until the system load is
again below the threshold.
See dist config for new option.
Should help those pools suffering from too many live update users.
* [ADDED] New Config Option: Algorithm
* scrypt and sha256d supported right now
* might add SHA coin support across MPOS
* Compatible with previous implementation
* [REMOVED] config option: pps_target
* Replaced by config option: algorithm
* Please update your config, defaults to srypt now!
* [ADDED] Unpaid Shares in Dashboard
* [MODIFIED] User estshares from DB query instead template math
* Adjusted mmcfe-ng occurences in code
* Adjusted Database strucutre to only supply the full structure
* Adjusted default template to MPOS
Addresses #643
* Added new configuration option `$config['network_confirmations']` to
dist config
* Default to 120 if not set
This will allow us to define a different confirmation level for user
transactions but still display blocks at their approriate unconfirmed
value when displaying them in the wallet information for admins. Risky
for pool owners but still a viable option.
Fixes#610
* Migrated configuration options to admin panel
* Removed configuration options from config file
* Added help text for each configuration option into panel
Addresses #622 and needs extensive testing by pools. A lot has changed
so pool owners might have to adjust their own templates to match this
new system.
* Changed blockexplorer URL to use Blockhash instead of height
* Added calls to find current networks blocks blockhash
* Propagated changes onto temmplate
* Added new dist configuration for new blockexplorer URL
Fixes#446
Invitations can now be configured through admin panel settings. By
default, invitations are enabled. Invitation system is also available if
registrations are disabled. To completely remove the ability of new
users to sign up, disable both registration and invitations.
Fixes#330
This will allow users to send invitations to other people via email.
Each account will still need to confirm the email address if the option
is enabled.
Addresses #330, will need to allow pool operators to enable this feature
even with registrations turned off.
* Adding mail verification during account registration
* Added new dist file option for mail verification
* Added account confirmation page using tokens
* Added mail class into user class for password resets
* Moved password reset template
* Adjusted account registration page
* Adjusted user class for email confirmation
Also fixed a bug with smarty_cache_key not being used properly if smarty
is disabled. Key still needs to be available even if caching is disabled
Addresses #330 and prepare the ticket for invitation only system.
Instead of just making it availble document the smarty cache feature.
It might work for users, but it's advised to rely on the memcache
instead.
Fixes#309
* Renamed configuration array to `smarty` => `cache`
* Added `smarty` => `cache_lifetime` to expire cache files properly
This should be safe to use, be aware that each page request is cached!
That includes any POST/GET calls to the site.
It does help in speeding up the site, up to 100% on some requests. For a
high traffic site it probably makes sense to enable this option with a
low cache lifetime to ensure most recent data.
Addresses #309
Instead of just making it availble document the smarty cache feature.
It might work for users, but it's advised to rely on the memcache
instead.
Fixes#309
* Rebased with next to add logging functions
* Added block method to fetch specific block
* Modified getArchive shares method to be more constistent
* Added new global configuration
* Adjusted smarty globals with new configuration
* More verbose pplns cron with logging
* Re-target the round in case of PPLNS not being matched by archive
Fixes#143
