decred/dcrstakepool

Stakepool for Decred.

dcrstakepool

⚠️ Deprecation Notice ⚠️

dcrstakepool is a deprecated project and support will soon be removed from wallets. All VSP operators should switch to vspd. Visit the Decred Blog to find out more about this change.

Overview

dcrstakepool is a web application which coordinates generating 1-of-2 multisig addresses on a pool of dcrwallet servers so users can purchase proof-of-stake tickets on the Decred network and have the pool of wallet servers vote on their behalf when the ticket is selected.

NB: In late 2018, a proposal was approved by stakeholders to rename "Stakepool" to "Voting Service Provider", a.k.a. "VSP". These names are used interchangably in this repository.

Architecture

• It is highly recommended to use at least 2 dcrd+dcrwallet+stakepoold nodes (backend servers) for production use on mainnet. One backend server can be used on testnet.
• Running dcrstakepool on mainnet is documented further at https://docs.decred.org.
• The architecture is subject to change in the future to lessen the dependence on MySQL.

Test Harness

A test harness is provided in ./harness.sh. The test harness uses tmux to start a dcrd node, multiple dcrwallet and stakepoold instances, and finally a dcrstakepool instance. It uses hard-coded wallet seeds and pubkeys, and as a result it is only suitable for use on testnet. Further documentation can be found in ./harness.sh.

Requirements

• Go 1.15 or newer.
• MySQL.
• A web server, such as nginx, to proxy to dcrstakepool.

Installation

Build from source

Building or updating from source requires the following build dependencies:

• Go 1.15 or newer

Building or updating from source requires only an installation of Go (instructions). It is recommended to add $GOPATH/bin to your PATH at this point.

To build and install from a checked-out repo, run go install . ./backend/stakepoold in the repo's root directory.

• Set the GO111MODULE=on environment variable if building from within GOPATH.

Updating

Please defer to the 1.5.0 release notes.

Setup

Pre-requisites

These instructions assume you are familiar with dcrd/dcrwallet.

• Create basic dcrd/dcrwallet/dcrctl config files with usernames, passwords, rpclisten, and network set appropriately within them or run example commands with additional flags as necessary.

• Build/install dcrd and dcrwallet from latest master.

• Run dcrd instances and let them fully sync.

Voting service fees/cold wallet

• Setup a new wallet for receiving payment for voting service fees. This should be completely separate from the voting service infrastructure.
• From your local machine...

$ dcrwallet --create
$ dcrwallet

• Get the master pubkey for the account you wish to use. This will be needed to configure dcrwallet and dcrstakepool.

$ dcrctl --wallet createnewaccount stakepoolfees
$ dcrctl --wallet getmasterpubkey stakepoolfees

• Mark 10000 addresses in use for the account so the wallet will recognize transactions to those addresses. Fees from UserId 1 will go to address 1, UserId 2 to address 2, and so on.

$ dcrctl --wallet accountsyncaddressindex stakepoolfees 0 10000

Voting service voting wallets

• Create the wallets. All wallets should have the same seed. Backup the seed for disaster recovery!
• Log into wallet servers separately and create wallets one at a time using the same seed.

$ ssh walletserver1
$ dcrwallet --create

• Start a properly configured dcrwallet and unlock it. See sample-dcrwallet.conf.
• From your local machine...

$ cp sample-dcrwallet.conf dcrwallet.conf
$ vim dcrwallet.conf
$ scp dcrwallet.conf walletserver1:~/.dcrwallet/
$ ssh walletserver1
$ dcrwallet

• Get the master pubkey from the default account. This will be used for votingwalletextpub in dcrstakepool.conf.

$ ssh walletserver1
$ dcrctl --wallet getmasterpubkey default

MySQL

• Log into your frontend
• Install, configure, and start MySQL
• Add stakepool user and create the stakepool database

$ ssh frontendserver
$ mysql -uroot -p

MySQL> CREATE USER 'stakepool'@'localhost' IDENTIFIED BY 'password';
MySQL> GRANT ALL PRIVILEGES ON *.* TO 'stakepool'@'localhost' WITH GRANT OPTION;
MySQL> FLUSH PRIVILEGES;
MySQL> CREATE DATABASE stakepool;

Nginx/web server

• Adapt sample-nginx.conf or setup a different web server in a proxy configuration. To prepare pre-zipped files to save the reverse proxy the trouble of compressing data on-the-fly, see the zipassets.sh script.

stakepoold setup

• Copy sample config and edit appropriately.
• From your local machine...

$ mkdir .stakepoold
$ cp sample-stakepoold.conf .stakepoold/stakepoold.conf
$ vim .stakepoold/stakepoold.conf
$ scp -r .stakepoold walletserver1:~/
$ scp -r .stakepoold walletserver2:~/

• Build and copy the stakepoold executable to each wallet server.
• From your local machine...

$ cd backend/stakepoold/
$ go build
$ scp stakepoold walletserver1:~/
$ scp stakepoold walletserver2:~/

dcrstakepool setup

• Create the .dcrstakepool directory and copy dcrwallet certs to it:

$ ssh frontendserver
$ mkdir ~/.dcrstakepool
$ cd ~/.dcrstakepool
$ scp walletserver1:~/.dcrwallet/rpc.cert wallet1.cert
$ scp walletserver2:~/.dcrwallet/rpc.cert wallet2.cert
$ scp walletserver1:~/.stakepoold/rpc.cert stakepoold1.cert
$ scp walletserver2:~/.stakepoold/rpc.cert stakepoold2.cert

• Copy sample config and edit appropriately.
• From your local machine...

$ cp sample-dcrstakepool.conf dcrstakepool.conf
$ vim dcrstakepool.conf
$ scp dcrstakepool.conf frontendserver:~/.dcrstakepool/

• Build and copy the entire dcrstakepool folder to your frontend.
• From your local machine...

$ go build
$ scp -r ../dcrstakepool frontendserver:~/

Running

stakepoold

Log into all servers and run stakepoold one at a time.

$ ssh walletserver1
$ ./stakepoold

dcrstakepool

Log into your frontend and run dcrstakepool

$ ssh frontendserver
$ cd dcrstakepool
$ ./dcrstakepool

To run dcrstakepool from another folder, such as /opt/dcrstakepool, it is necessary to copy (1) the dcrstakepool executable generated by go build, (2) the public folder, and (3) the views folder into the other folder.

By default, dcrstakepool looks for the public and views folders in the same parent directory as the dcrstakepool executable. If you wish to run dcrstakepool from a different directory you will need to change publicpath and templatepath from their relative paths to an absolute path.

Development

If you are modifying templates, sending the USR1 signal to the dcrstakepool process will trigger a template reload.

Protoc

The RPC interface between dcrstakepool and stakepoold is defined in ./backend/stakepoold/rpc/api.proto. If modifications are made to this file, api.pb.go needs to be regenerated using the script ./backend/stakepoold/rpc/regen.sh. The following tools are required to run the script:

• libprotoc 3.11.4 or later
• protoc-gen-go 1.3.4 or later

Operations

• dcrstakepool will connect to the database or error out if it cannot do so.

• dcrstakepool will create the stakepool.Users table automatically if it doesn't exist.

• dcrstakepool attempts to connect to all of the stakepoold servers on startup or error out if it cannot do so.

• dcrstakepool takes a user's pubkey, validates it, calls getnewaddress on all the wallet servers, then createmultisig, and finally importscript. If any of these RPCs fail or returns inconsistent results, the RPC client built-in to dcrstakepool will shut down and will not operate until it has been restarted. Wallets should be verified to be in sync before restarting.

• User API Tokens have an issuer field set to baseURL from the configuration file. Changing the baseURL requires all API Tokens to be re-generated.

Adding Invalid Tickets

For Newer versions / git tip

If a user pays an incorrect fee, login as an account that meets the adminUserIps and adminUserIds restrictions and click the 'Add Low Fee Tickets' link in the menu. You will be presented with a list of tickets that are suitable for adding. Check the appropriate one(s) and click the submit button. Upon success, you should see the stakepoold logs reflect that the new tickets were processed.

For v1.1.1 and below

If a user pays an incorrect fee you may add their tickets like so (requires dcrd running with txindex=1):

dcrctl --wallet stakepooluserinfo "MultiSigAddress" | grep -Pzo '(?<="invalid": \[)[^\]]*' | tr -d , | xargs -Itickethash dcrctl --wallet getrawtransaction tickethash | xargs -Itickethex dcrctl --wallet addticket "tickethex"

Backups, monitoring, security considerations

• MySQL should be backed up often and regularly (probably at least hourly). Backups should be transferred off-site. If using binary backups, do a test restore. For .sql files, verify visually.

• A monitoring system with alerting should be pointed at dcrstakepool and tested/verified to be operating properly. There is a hidden /status page which throws 500 if the RPC client is shutdown. If your monitoring system supports it, add additional points of verification such as: checking that the /stats page loads and has expected information in it, create a test account and setup automated login testing, etc.

• Wallets should never be used for anything else (they should always have a balance of 0).

Disaster Recovery

Always keep at least one wallet voting while performing maintenance / restoration!

• In the case of a total failure of a wallet server:
  • Restore the failed wallet(s) from seed.
  • Restart the dcrstakepool process to allow automatic syncing to occur.

Getting help

To get help with dcrstakepool please create a GitHub issue or the join the Decred community using your preferred chat platform.

License

dcrstakepool is licensed under the copyfree MIT/X11 and ISC Licenses.

dcrstakepool's Issues

creating voting daemon to takeover stakepool-related functionality from dcrwallet

Broken out from #49.

• create a voting daemon (tentatively named stakepoold) to handle the voting
• receive voting config for all users from dcrstakepool
• set votebits according to user preference, ask wallet to sign, broadcast

Reason for keeping address index the same on all wallets?

I am doing a little development, but I was hoping I could get a little more info about why all wallets must be at the same index.

1. What happens when they are not in sync? Does it only impact the ability of that wallet to participate in the voting, or does it somehow ruin all votes that go through it?
2. Is there a way to ascertain the max index state from the network somehow (I'm doubting this is possible)?
3. Does the order of first getting the index right then adding the script keys matter?

controllers/config.go should be parsed at runtime instead of compiled

Acknowledged that this has been discussed internally, but here's an issue to track. This is potentially a source for errors as it parts with general expectations that config files will be read at runtime.

A secondary issue is that it is not clear for which files modification necessitates a re-compile. Specifically, the README.md calls for modification to:

1. controllers/config.go
2. controllers/main.go (ideally, pull recaptcha secret out of here and into config or MySQL)
3. views/auth/signup.html (presumably this one can be modified without recompile?)
4. config.toml

Maybe others?

multiple registrations can cause flakiness due to rescans triggered by importscript

08:25 Dyrk for some reason on one of the wallet servers it takes more than our to resync each time
08:26 Dyrk * > 1 hour
09:02 Dyrk During the day /stats page is not accessible, because many users registering in the pool, so wallets are in continues rescan process

Need to make importscript take an optional height since it's essentially doing rescans for nothing since a new user won't have bought tickets.

Main dcrclient msg chan will lock up if there are too many requests

Should discard the request instead of locking up

http://stackoverflow.com/questions/25657207/golang-how-to-know-a-buffered-channel-is-full

Update dcrticketbuyer option

I think this section (Step 3, Option A of the Tickets page @ dcrstakepool/views/tickets.html) needs to be updated since dcrticketbuyer is now integrated within dcrwallet.

status page looks good when stats doesn't respond

I just posted an issue with hung wallets here: decred/dcrwallet#210

What I didn't say was that this machine is part of a stake pool. One of those wallets was a wallet on the pool, so one of four wallets was not responding.

I forgot to mention in the other issue that they hung wallet returned some kind of client disconnected/lost error in response to getstake info, but returned fine with walletinfo. However, walletinfo indicated daemonconnected false.

But I digress. What I'm interested in here is having the pool's /status page return something other than RPC Status: Running when in this situation. Fortunately, I had a watch on /stats also which alerted me to this problem. I had to go to the pool's machine and run a wallet check script, which runs both walletinfo and getstakeinfo on all 4 wallets. Only getstakeinfo on the one wallet didn't work, and walletinfo for that one showed daemon not connected.

And this has been said before, but the other pages really need to time out on the RPC calls and return something, anything.

migrate config.toml options to dcrstakepool.conf

This is a remnant from the project we forked from and should be removed.

API key doesn't wrap

The API key extends outside of the page boundaries which makes it look ugly and unprofessional as well as making it harder to copy. The key should wrap to the page boundaries.

accept4: too many open files -- when wallets inaccessible for extended period

On a few occasions when one or more wallets is inaccessible for an extended period, dcrstakepool will start giving the following error repeatedly:

http: Accept error: accept tcp 127.0.0.1:3000: accept4: too many open files; retrying in 1s

At this point you cannot quit with CTRL+C. Here is the SIGABRT trace.

Command line switches are broken

dcrstakepool -h gives a nice summary of the options defined in config.go, but then if you try anything, you get a message from Gojiflag.Parse() instead:

$ ./dcrstakepool -C ./dcrstakepool.conf
flag provided but not defined: -C
Usage of ./dcrstakepool:
  -alsologtostderr
        log to standard error as well as files
  -bind string
        Address to bind on. If this value has a colon, as in ":8000" or
        "127.0.0.1:9001", it will be treated as a TCP address. If it
        begins with a "/" or a ".", it will be treated as a path to a
        UNIX socket. If it begins with the string "fd@", as in "fd@3",
        it will be treated as a file descriptor (useful for use with
        systemd, for instance). If it begins with the string "einhorn@",
        as in "einhorn@0", the corresponding einhorn socket will be
        used. If an option is not explicitly passed, the implementation
        will automatically select among "einhorn@0" (Einhorn), "fd@3"
        (systemd), and ":8000" (fallback) based on its environment. (default ":8000")
  -config string
        Path to configuration file (default "config.toml")
  -log_backtrace_at value
        when logging hits line file:N, emit a stack trace
  -log_dir string
        If non-empty, write log files in this directory
  -logtostderr
        log to standard error instead of files
  -stderrthreshold value
        logs at or above this threshold go to stderr
  -v value
        log level for V logs
09:00:25 2016-09-26 [INF] DCRS: Version: 0.0.1-beta
  -vmodule value
        comma-separated list of pattern=N settings for file-filtered logging

On the upside, I use -bind, so it's good that I can do this.

btcsuite/go-flags should be the only command line parser.

Using glide.yaml and glide.lock in current dcrstakepool master.

Replace UserCount with ActiveUsers

I think there is no need to count bots, fake users, those who will never use Stake Pool, forgot password etc. Non-empty MultiSigAddress in the query should solve it.

usercount, err := dbMap.SelectInt("SELECT COUNT(*) FROM Users WHERE MultiSigAddress <> ''")

Add expired tickets as a separate list

This will require some additional work in dcrwallet to allow for pool tickets to get properly given the status of expired instead of just missed.

modify instructions to use accounts to better provide a fallback in case of pool failure

13:57 ceejep Ideally when you make the P2SH address and give a pubkey, you
should use a new account I guess
13:57 ceejep Accounts are hardened, so it's OK to give the private key to a
single account to a third party iirc, as long as that account
only does voting and nothing else
13:58 ceejep createnewaccount voting
13:58 ceejep getnewaddress voting
13:58 ceejep then get the pubkey with validateaddress as before

improve votebits handling

Since votebits are going to be more important soon, the stakepool's handling of them and general functionality needs to be greatly improved.

• need to have a pool wide setting controllable by the admin (which is referred to now as 'pool policy')
• need to display the pool policy and what it means
• need to let the user specify a default setting for their own tickets
• may need some sort of basic UI to explain the various options to the user
• need to update all tickets for all users who are using 'pool policy' when the pool default changes
• need some sort of background task to ensure new tickets have the correct votebits set

Rather than doing the above, it's been decided to go in a different direction. Some of the finer details are still a bit fuzzy but the general idea is:

• create a voting daemon (stakepoold) which handles the voting
  • set votebits according to user preference, ask wallet to sign, broadcast
  • move fee enforcement from wallet to this daemon?
• dcrstakepool changes
  • new voting page with a UI for active agendas (i.e. getvoteinfo 4, turn the options into a drop down) and store the voting config
  • API for voting config
  • remove mentions of pool policy/current votebits implementation on tickets page
• dcrwallet
  • remove stored votebits/RPCs in dcrwallet

add voting page/config and API options

Broken out from #49.

• new voting page with a UI for active agendas (i.e. getvoteinfo 4, turn the options into a drop down) and store the voting config
• API for voting config
• remove mentions of pool policy/current votebits implementation on tickets page

Inconsistent logging backends

What logger should be used consistently? In places it is btclog, glog, fmt.Printf... Presumably dcrstakepoolLog (a btclog.Logger) is supposed to be used in most places, but is not.

Voted and missed tickets are remaining in the ticket list

When a ticket has been voted on, I thought the ticket would get removed from the ticket list (at least that's how I remember it working on the mainnet stakepool you guys set up). That doesn't seem to be working for me.

I'm talking about tickets you see under /tickets on the site.

Any ideas? I see nothing in the logs except:

W0402 03:22:12.407504 13815 user.go:38] Can't get user by email: sql: no rows in result set

But I only see that one time. (Should I add an issue for that warning?)

Handling of closed database absent

There are two main issues:

1. models.GetDbMap does not exit if there are db errors
2. The caller, Application.Init(andrunMain`) do not check for a valid db result.

allow to run dcrstakepool from different directory

The documentation says:

• Build and run the dcrstakepool binary from the dcrstakepool directory

$ cd $GOPATH/src/github.com/decred/dcrstakepool
$ go build
$ ./dcrstakepool

Are there any plans to allow to run the dcrstakepool binary from a different directory? We want to have /home/dcrstakepool mounted as noexec.

Update glide deps for 0.7.0

• 3rd party at the beginning
• internal before release

invalid tickets remain in stakepooluserinfo result even after ticket spent (voted)

As the title indicates, stakepooluserinfo will list invalid tickets that are already spent. In the case I am looking at, the tickets were spent by a ssgen. I don't recall adding the invalid tickets manually to the pool so I believe the user let their wallet vote using the import script.

invalid tickets that are voted, missed, or expired should be removed from the stakepool user info.

switch/upgrade web frameworks and rework middleware

Most Go web frameworks use https://godoc.org/golang.org/x/net/context/ or https://golang.org/pkg/context/ internally now. It would help the code base a lot to modernize the framework/middleware.

panic in SetTicketsVoteBits() via TicketsPost() when user has 0 live tickets

Reported by @dyrk:

[9:22] if user has at least 1 tickets and 0 Live tickets
[9:22] he can still update votebits from Tickets page
[9:23] and dcrstakepool dies

I believe this happens because the 'Update Tickets' button is shown when there's an immature ticket but since it's not actually live the code ends up calling SetTicketBoteBits() with no live ticket hashes.

enable DisableSubmissions by default when the pool reaches 5%

from the RFP:

Per the temporary soft cap of 5% of the tickets, pool operators will be required to turn off new registrations for their pool once they have >= 5.0% of the tickets in their pool. Once the initial 3 month period is over, the pool can re-enable registrations and remove its soft cap.

On the Vote bits control UX

The"pool control" checkbox it implies state, but there is none. Setting pool control, especially with a checkbox, implies the pool is being given the ability (control) to change vote bits as it sees fit. Really it just applies the current pool policy when the button is clicked. There are no future updates after this POST is handled. The buttons on the /tickets page should be modified to reflect this behavior.

In addition, given the current meaning of "pool control" I think the "Pool Control" column of the live tickets list should be removed. Presently is shows Yes if bits are 1 and No if bits are 0... not really to do with control and redundant with the Votbits column. https://github.com/decred/dcrstakepool-private/blob/master/views/tickets.html#L113

<td>{{ if eq $data.VoteBits 1 }}Yes{{end}}{{ if ne $data.VoteBits 1}}No{{end}}</td>

No real point in the above.

Also, the Update button is tough on the site as it blocks the page, and it sets bits on all tickets, not just live. Solved in #32

Maintenance Mode needed

Almost too obvious to state, but we need the ability to switch the server into maintenance mode. Say right before we start wallet upgrades, or repairing a wallet, or whatever.

This mode should be controlled through the Administrative interface (should this also be an issue) rather than through commands on the server. For load-balanced configurations, it may not be feasible or practical to login to the web servers to fiddle around.

Email support and password reset

Email support is needed for 2 important missing features:

1. email verification on sign up. Currently anyone can sign up with your email!
2. Password reset.

Add expired ticket area

should use SplitHostPort in getClientIP()

We're splitting on : which more than likely breaks IPv6. There's a convenience function for this:

https://godoc.org/net#SplitHostPort

Public key address runs off the screen and moves menu button

When displaying the Addresses page on a small window or a device with a small screen, the address runs out of the box and pushes the menu button far to the right.

The address should either wrap or be in a scrollable box. To get to the menu button on this page, it was necessary to scroll over even though it was positioned correctly on other pages:

This is a testnet address, and it's missing the first 12 or so digits, so, meh.

EDIT: Similar issues on Tickets page.

Design REST API for external integration.

We want to be able to integrate stakepools with, for example, Paymetheus. The idea is that we want to prompt the user to enter username, password and stakepool and Paymetheus fully automates the process.

This ticket's end-game is to have a spec that allows full integration between stakepools and external apps. Care must be taken to ensure security is a built-in feature.

General features/security concerns:

• Rate limiting to prevent abuse

Minimum required RPCs:

• Create account
• Login
• Obtain script
• Status
• Stats
• Logout

Discuss the following RPCs:

• Delete account
• Reset password

POC REST api command line tool

In order to validate the REST API as described in #34 we need a test tool.

POC a command line utility that is capable of issuing all RPC commands for testing and development purposes. This tool should become the reference implementation and be part of the stakepool repo.

This is an @jolan task.

paginate/improve performance of tickets page

The ticket page becomes slower to load over time because stakepooluserinfo returns every voted ticket.

Using my development/testnet stakepool, I can load the page OK for a user with 100,000 voted tickets with 3 wallets hosted on a LAN with very fast machines.

But once you have a few thousand on 3+ servers spread across the world on slowish VPSes you hit timeouts like @dyrk reported seeing.

Real fix would be to either add sorting/pagination options to the RPC or overhaul the architecture of stakepool to cache the ticket info in the database.

Maybe the easiest thing to do would be to add an option to the stakepooluserinfo that only returns tickets of a certain status so voted tickets could be processed separately.

Improve API

JSON messages need to be updated to not use strings for literally all fields.

There has been discussion about redirecting users to the pool's web page in order to sign up for the service, since then it can be protected with a captcha.

Consider using a sessionless API key instead of logging in to the service.

Add error codes to report specific error conditions.

Better handling of wallet failures needed -- limits or thresholds on healthy wallets

dcrstakepool is very fragile, breaking more easily as the number of wallets increases.

The current design of dcrstakepool is such that as the pool's voting system (i.e. it's multiple wallets) becomes larger and thus less likely to miss a vote, the web front-end becomes more likely to break. dcrstakepool is minimally robust to wallet issues. Having a single offline/desynced/misbehaving wallet halts the normal operation of the web interface and makes it quite fragile for pools that have many wallets, and thus more possible points of failure.

When a wallet is simply offline, the pool should function normally if certain criteria are met (or until an admin puts it into maintenance mode to fix the wallets):

1. N wallet's remain online (and are all in sync).
2. Less than M sync'd wallets are offline.
3. similar measure to indicate critical degradation

When wallets are out of sync, producing different scripts or latest address or whatever, there should be a method for determining which one(s) are out of sync. Perhaps new wallet RPCs and dcrstakepool methods to check:

1. Address index (current, next, whatever.) of each wallet.
2. Full comparison of list of addresses generated by each wallet.
3. Script comparisons?

In any case, mark one or more wallets as offline, and the wallet pool as degraded. The stake pool has the potential to scale very well, but it needs to be more robust first.

user registration while a wallet is disconnected (but is now up) is not handled well

14:23 < Dyrk> DCRS: importScriptFn nonequiv failure 1 on servers 1, 2
14:23 < Dyrk> [INF] DCRS: RPC ImportScript failed on connection error: non equivalent error returned 1
14:23 < Dyrk> [INF] DCRS: Wallet RPC manager shutting down
14:24 < Dyrk> when this happens in the stake pool (may be few times) it stop interacting with wallets
14:25 < Dyrk> only restart helps
14:25 < Dyrk> as I understant this bug was introduced in "Add smarter wallet connectivity " 0881103 right?

I hit this too while testing. I rebooted a wallet server. The wallet was shown as disconnected but was running again. When a user registered, I hit the same thing as @dyrk. I didn't investigate at all but my guess is that it is reconnecting the wallet but not sending the command or something like that.

Dynamic Wallet Discovery

This is more of an enhacement request. Using something like consul.io, it would be great to be able to have optional "service discovery" for wallets. Rather than the recompile every time I need to add a wallet, I'd like to just register it with consul and have it dynamically be in use.

internationalization support

feature request by @girino

Looks like this would be easy to implement:

https://github.com/nicksnyder/go-i18n

Pages hang and return 504 Gateway Time-out, and can't quit

Successful sign-up, add address, and verify 4 purchased tickets on the Tickets page. Then, 7 hours later, several pages (Stats, Tickets, but not Address) hang with:

504 Gateway Time-out
nginx/1.6.2

dcrstakepool has no messages after "[INF] DCRS: Starting wallet RPC manager" and /status shows "RPC Status: Running". journalctl has no informative messages either.

CTRL+C to dcrstakepool also hangs with "Goji received signal, gracefully stopping". Repeated CTRL+C after a couple minutes of waiting leads to "[INF] DCRS: Wallet RPC manager shutting down", and hangs.

After forcible kill and relauch, still hanging. I'm running dcrstakepool with -v 0 and there are no useful messages.

This is on our semi-private testnet stakepool sandbox:
https://stakepool-testnet.monkeyland.io/

@fai04d can have a look at MySQL to see what's happening there.

Favicons in new template

missing

Password reset functionality

During the process of the new Theme creation the view for resetting a forgotten password was forgotten.

Tickets Page needs Responsive Datatables

As the ticketlist can grow very big it is needed to add the datatables.js to make the ticketlist searchable, sortable and responsive

Fix copyright and grammar in footer

Invalid template path leads to a panic

The line numbers are slightly off, but in the following panic, the following line is the culprit:

if f.IsDir() != true && strings.HasSuffix(f.Name(), ".html") {

[jon@] 15:32 $ ./dcrstakepool -bind 127.0.0.1:8000 -C ~/.dcrstakepool/dcrstakepool.conf 
15:32:42 2017-02-05 [INF] DCRS: Version: 1.0.0
15:32:42 2017-02-05 [INF] DCRS: Network: testnet
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x55ba7f]

goroutine 1 [running]:
panic(0x9972c0, 0xc420014140)
	/usr/lib/go/src/runtime/panic.go:500 +0x1a1
github.com/decred/dcrstakepool/system.(*Application).LoadTemplates.func1(0xc42010e92d, 0x12, 0x0, 0x0, 0xe2dc60, 0xc420125830, 0x9e1901, 0xc420144b80)
	/home/jon/go/src/github.com/decred/dcrstakepool/system/core.go:90 +0x2f
path/filepath.Walk(0xc42010e92d, 0x12, 0xc420144b80, 0x9, 0xc42044dd97)
	/usr/lib/go/src/path/filepath/path.go:396 +0x8b
github.com/decred/dcrstakepool/system.(*Application).LoadTemplates(0xc420016480, 0xc42010e92d, 0x12, 0xa40857, 0x15)
	/home/jon/go/src/github.com/decred/dcrstakepool/system/core.go:96 +0xc2
main.runMain(0x0)
	/home/jon/go/src/github.com/decred/dcrstakepool/server.go:59 +0x3a0
main.main()
	/home/jon/go/src/github.com/decred/dcrstakepool/server.go:205 +0x22

Design Update, New Template, integrate new HTML, CSS and JS

We need to Update the default Design Template on dcrstakepool.

I will make a design update and integrate new HTML, CSS and JS

need to handle getticketsvotebits errors better

votebits errors out when ticket doesn't exist due to mempool differences or when a missed/revoked ticket is present or not.

Open source stakepool.

There is a desire to open source the stakepool software.

Action items:

• Fix obvious bugs assigned to 0.6.0
• Implement (most) enhancements that are assigned to 0.6.0
• Clean up code base
• Audit code base (peruse OWASP checklist)
• ...
• Profit

use X-Real-IP / X-Forwarded-For instead of remoteAddr

@dyrk and @chappjc are reporting that remoteAddr always gives 127.0.0.1 due to nginx proxying.

It seems to work fine for me but it may be due to how to the environment I'm running it in.

Anyway, pretty simple to fix.

Tickets added to pool with addticket not found in store

If a ticket is manually added with addticket to one of the pool wallets, dcrstakepool is unable to load the /tickets page and gives the following error:

[INF] DCRS: getTicketsVoteBitsFn failure on server 1: -4: ticket <ticket hash> not found in store
[INF] DCRS: GetTicketsVoteBits failed -4: ticket <ticket hash> not found in store

Preferably, it would show tickets that are common to all wallets. Auto-sync is an idea, but the common tickets could be shown.