decred / decrediton

Cross-platform GUI for Decred.

decrediton

decrediton is a cross-platform GUI for decred written in node.js using Electron.

Installation

Currently decrediton is available on Windows, Linux, and macOS.

Decrediton will NOT use or in any way disrupt the CLI wallet file you may already be using at this time.

Download the decrediton release for your operating system on decred/decred-binaries.

On macOS, Ubuntu (14.04 LTS kernel 3.16 and later), and recent Debians, there should be no additional dependencies needed (exception: Ubuntu 18.04+, see issue #1404).

On Fedora or similar distros you may need to install the libXScrnSaver package if you see this error:

error while loading shared libraries: libXss.so.1

You can install this on a recent Fedora with the command:

sudo dnf -y install libXScrnSaver

On linux you will need to decompress the package:

tar -xvzf decrediton-X.X.X.tar.gz

and then run the file:

./decrediton

This will start dcrd and dcrwallet for you.

On macOS, double-click the .dmg file, drag the .app to your Applications folder. Double click on Decrediton.app to start.

You can also install via brew cask:

brew cask install decrediton

From there follow the on screen instructions to setup your wallet.

Options

When running a release version, there are a few options available.

To see additional debug information (including the output of dcrd and dcrwallet) run:

decrediton --debug

To pass additional arguments to dcrwallet (such as to increase the logging level run:

decrediton --extrawalletargs='-d=debug'

Development Setup

Node and Electron Versions

You need to use compatible node and electron versions to build native modules and in general to ensure the code you're working on will behave correctly in production.

The current recommended versions for the main tools are:

• Node: 14.16.1
• Npm: 6.4+
• Yarn: 1.12+

To ease node version management, install all top-level tools (node/npm/yarn) using nvm.

Electron extensions

Decrediton uses electron-devtools-installer to automatically install react and redux dev tools in the userData/extensions directory.

The extensions will not be updated unless you set the UPGRADE_EXTENSIONS environment variable to true.

Decred Binaries

Development using the master version of decrediton usually requires using a corresponding master version of dcrd, dcrwallet and dcrlnd.

Follow the instructions to install these from source from their respective repos:

• dcrd installation instructions
• dcrwallet installation instructions
• dcrlnd installation instructions

Basic Development Setup

These steps are usually the only ones required for basic development on linux/macOS (after compiling dcrd/dcrwallet/dcrlnd from source).

For Windows users, it's usually a good idea to use MSYS2 instead of the standard cmd.exe (see below for more Windows tips).

git clone https://github.com/decred/decrediton.git
cd decrediton
mkdir bin/
cp $GOPATH/bin/dcr* bin/
yarn
yarn dev

Requirements for DEX Development Usage

The building of the dex module requires Go to be installed.

Keeping up with dcrd/dcrwallet changes

If you're developing decrediton improvements on a daily basis, you need to also keep up to date with dcrd/dcrwallet changes (especially when developing things like new grpc calls).

In that case, instead of copying the binaries to /bin it's better to symlink them so that you only need a single step (go install) to run newer versions of these tools:

cd bin
ln -s `which dcrd` dcrd
ln -s `which dcrwallet` dcrwallet
ln -s `which dcrlnd` dcrlnd

Advanced Daemon Mode

This step is only recommended if you're constantly restarting decrediton. If you're not developing on a daily basis, you can safely ignore this for the moment.

When starting decrediton in RPC (or "normal") mode, it automatically runs dcrd in the backgound to gather blockchain data. If you need to constantly restart decrediton, loading the node every time may be time consuming.

In that case, it's helpful to run the dcrd node in a separate process and simply attach to it between decrediton restarts. In order to see the advanced daemon configuration options either start decrediton with the --advanced option or open config.json and set the daemon_start_advanced flag to true as follows:

"daemon_start_advanced": true,

Note: Your config.json file is located in the following directories:

Windows - C:\Users\<your-username>\AppData\Local\Decrediton\config.json

macOS - $HOME/Library/Application\ Support/Decrediton/config.json

Linux - ~/.config/decrediton/config.json

Run the following to start the Decred daemon in a standalone terminal window:

Windows - dcrd --testnet -u USER -P PASSWORD --rpclisten=127.0.0.1:19119 --rpccert=C:\Users\<username>\AppData\Local\Dcrd\rpc.cert

macOS - dcrd --testnet -u USER -P PASSWORD --rpclisten=127.0.0.1:19119 --rpccert=$HOME/Library/Application\ Support/Dcrd/rpc.cert

Linux - dcrd --testnet -u USER -P PASSWORD --rpclisten=127.0.0.1:19119 --rpccert=~/.dcrd/rpc.cert

Once you restart decrediton, you should be presented with a screen to specify the node parameters. Note that all of them are present in the command you used to start the node for your respective system.

CLI options (including --advanced) when running yarn dev are currently not supported.

When generating the TLS keypairs for the rpc endpoint you should use the P-256 curve by starting the daemon with --tlscurve=P-256. Note that the rpccert/rpckey files need to be deleted before this.

Platform-specific instructions

macOS

To start decrediton from command-line (assuming it is installed in /Applications):

$ /Applications/decrediton.app/Contents/MacOS/decrediton

Windows

Requires at least Windows 10.

Windows is tricky, due to some things working better on MSYS2, while some things only working on cmd.exe, and native module building being very tough to get right.

On a day-to-day basis, for development and testing (of general decrediton functionality) MSYS2 is fine, and usually useful for providing GNU-like CLI tools.

However, for building native modules, you'll need to use the cmd.exe prompt.

First, from an administrative prompt (cmd.exe), install windows-build-tools:

npm install --global --production windows-build-tools

This usually works, but sometimes bugs out. If it does, try manually installing the vs tools by going opening an explorer window to c:\users\[user]\.windows-build-tools, then running vs_BuildTools.exe.

After installing windows-build-tools, open a non-administrative prompt (cmd.exe) and then try recompiling the native modules:

yarn
yarn rebuild-natives

If you have multiple versions of VS Build Tools installed, you may need to configure which version to use:

npm config set msvs_version 2015 -g

Sometimes you have to nuke /node_modules and /app/node_modules for the native modules to be forced to rebuild.

You might also run into trouble when compiling or trying to use modules compiled with a different version of node than the one that electron internally uses. In that case, switch to the same version of node from electron (check the electron/node version here) then try everything again.

The end result for module compilation should be the following files:

• app/node_modules/blake-hash/bin/win32-x64-64/blake-hash.node
• app/node_modules/dcrwin32ipc/build/Release/dcrwin32ipc.node
• app/node_modules/grpc/src/node/extension_binary/electron-v3.0-win32-x64/grpc_node.node

Note: yarn start does not currently correctly load the dcrwin32ipc module, so testing with yarn build/start will fail to correctly unload dcrd/dcrwallet when closing.

When using git bash, cmd.exe or Powershell, you might need to install MingW-w64 to get access to gcc and be able to compile libdex. After installing it, ensure gcc and python are accessible in console (add the appropriate binary paths to the %PATH% environment variable).

Raspberry Pi & Other Platforms

Building on a Raspberry Pi (and other less common platforms) requires rebuilding the native modules, given that most of them (specially grpc) do not come with precompiled binaries for them.

Do note that for the moment, support for this platform is experimental, so you might need to tweak stuff (in particular, you'll need to disable hardware acceleration and ui animations) to run decrediton on it.

yarn rebuild-natives

Building release versions

You need the binaries copied into the bin/ directly (note that symlinks don't work for production builds: you need to actually copy the executables).

You can test the production version (without most of the debugging info and with compiled and minified code) by using:

yarn build
yarn start

And finally, a packaged version (including the final standalone electron binaries) for the current platform can be built with:

yarn package

Linux

You need to make sure you have the rpm-build package installed for the building to work.

yarn package-linux

After it is finished it will have the built rpm, deb and tar.gz in the release/ directory.

If you're only interested in a tar.gz, you can alternatively use:

yarn package-dev-linux

Contact

If you have any further questions you can find us at: https://decred.org/community/

Issue Tracker

The integrated github issue tracker is used for this project.

License

decrediton is licensed under the copyfree ISC License.

decrediton's Issues

Add rescan button to dashboard and trigger rescan on Create

async/await instead of callback`

Appears to be able to use the promise/async/await babel needs to have some special tweaks to get it building.

Set up decrediton config files

Currently there are some hardcoded paths/values to connect to grpc client.

These should be handled via config files instead.

readd eslint-formatter-pretty

hashHistory causing double renders

Seeing similar issues as referenced here:
reactjs/react-router-redux#197

2 possible solutions:
Downgrade to react-router 2.8.0
or
use browserHistory instead of hashHistory

Check for proper version of wallet

decrediton should check that it is communicating with a new enough version of wallet (or an expected version of wallet) and give an error if not.

Scrollbars showing up

Sidebar vertical scrollbar and main area horizontal scrollbar are showing up when they are not necessary

Set dcr or bits as unit in the configs.

Typos in readme

There are a few typos and mistakes in the README.md that need fixing. This includes not using the copy of electron installed by npm in the decrediton directory.

Create proper wrapper for grpc client calls

Add convinient boilerplate infrastructure so that async calls to grpc client (ie client.balance(request{}, cb())) have their responses bubbled back up.

Allow command line options

Would be nice to specify cmd line options such as --testnet or --datadir in a way that plays nice with config file.

Update .gitignore

app/main.js.map

and various other garbage in app/dist/ upon doing npm run pacakge

Ports in README do not match defaults in code

Allow for app settings to perpetuate after app close

The rough idea is to have a app settings screen that would set certain values in a flat file or something that is loaded on start.

Package up dcrd/dcrwallet

At some point we need to be able to include dcrd and dcrwallet the way the msi installer does for windows to allow a single download. Not sure how we would do this at the moment.

Add material-ui stepper to get started/bring up process

Audit usage of passphrases in redux state

We are currently holding public/private passphrases in redux state. For obvious reasons, this is not ideal.

Couple points to research:

• Is there a existing way to handle these situations with redux?
• Are there any other options than storing in redux state or asking each request?
• Are there any issues with memory usage to take under consideration?

When starting wallet, decrediton needs to use the option for P256 certs and --onetimetlskey

Start wallet in decrediton specific directory

Much like paymetheus, decrediton should start dcrwallet in a directory of its own rather than in $HOME/.dcrwallet (or whatever the os specific one is) so it doesn't interfere with existing wallets.

Fix additional linter caught issues.

implement tx construction for dcrwallet grcp

Currently the use of fundtransaction + sign/publish isn't ideal and we'd like to instead keep that functionality within dcrwallet. So basically it would be akin to implementing sendtoaddress/sendfrom for grpc.

Remove duplicate cert code

We have identical code to find the rpc.cert twice. Should have single function for it.

Document install

Currently a user needs to have dcrd and dcrwallet already installed. dcrinstall is probably the best way to do that. This must be added to the README.md

Fix rpc loading to avoid possible exception

Should match the example updated in:
decred/dcrwallet#445

Form validation

Implement a form validation solution that will allow us to at least have some minimal amount of input sanitization for the various forms we have (and any forms we may have).

Implement SeedService to offer new seeds (or decode existing ones)

cross-build

We need to investigate if cross-building/packaging is possible. Due to the dmg this almost certainly would only work when done from a mac (if it works at all of course).

Address use

Currently, on startup decrediton gets a new address from the wallet. That way when you go to the recieve page it already has an address ready. That's nice, but if you do not go to the recieve page the next time you start up it will get an new address to have ready. We can go through a lot of addresses this way.

Probably it should either not ask for an address until it needs it (as in you load the wallet page) or internally keep track of the last used address.

Implement proper login actions via middleware grpc

http://stackoverflow.com/questions/7255956/return-results-from-a-function-javascript-nodejs

and

reduxjs/redux#291

with both of these we should be able to properly handle the state

License

Need to have the same license in readme, LICENSE, and both package.json files.

Confirm current webpack config + package.json scripts all for proper release building

The package.json is taken from:
https://github.com/chentsulin/electron-react-boilerplate#packaging

it should be updated to s//g decrediton and confirm that the commands:
npm run package
and
npm run package-all

work as intended

Location of config data and cache data

Config, cache, and various other bits that get written to disk should go in ~/.decrediton (or whatever the os specific place is) instead of ~/.config/Electron.

grpc node_module causing build errs in webpack (or watchify)

When attempting to:
import grpc from 'grpc'
in any file in app/ webpack is not able to properly build it and gives crazy parsing errors.

This may have something to do with webpack config setup or package.json settings.

Import of the Seed is not working

I've tried to import standard 33 words seed (without new lines: words and spaces only) of existing wallet and it failed. In the console, I see "Error: seed length must be between 128 and 512 bits" and, actually, the correct seed is printed in the console.

app name

There are some of the menu items (on osx at least) that have electron as the name still instead of decrediton. Those need renaming.

Better grpc install

A less hacky way to install an electron compatible grpc would be good.

If the grpc branch we are using hits master there we might be able to avoid the issue all together which would be ideal. Will have to keep an eye on that.

Refactor gRPC clients

Our current implementation of the grpc client communication has a lot reused code, this should all be refactored to use a cleaner/more easily expandable structure.

This issue will also include updating to use proper async/await/Promises (as defined in ES2016/ES7) instead of callbacks. Previous attempts at this was unsuccessful due to strange babel-loader issues ("await is a reserved word")

jslint

Once travis builds are going #33 we need to include jslint or some other js style checker.

Explicietly set rpc ports for dcrd when autostarted

travis builds

We should be testing builds and PRs with travis like our other projects.

Remove unneeded file

We had a copy of the grpc binary in our repo from an earlier version of our build instructions. It isn't used any more so should be removed (and isn't cross platform anyway).

User cannot log in if he has existing wallet without public passphrase

Styling html and css of get started page (home + notloggedin)

Update the current homepage for the notloggedin state for a cleaner/better looking login form that is properly centered and looks good at various widths of the app.

version number

Currently when one builds the package with

npm run package

the result is decrediton-1.0.0.dmg (or other platform specific extension). Probably should not be 1.0 just yet :)

Clean up based on eslint

Clean up code based on eslint.

If needed change eslint rules to match what we do (if we really mean to do it that way).

Create launcher for decrediton

Aim is to have a similar launcher to paymetheus.
Spawn dcrd and dcrwallet child processes so decrediton works straight off the bat.

First iteration can just be a simple process spawner, but in the end dcrd/dcrwallet should be fully functional but practically invisible to the user for ease of use.

Hide/Display Drawer dependent upon get started position

Hide drawer if wallet not prepared... etc.

icon

The dmg and app both use the default electron icon. We should add a decred one (even if it is just the current logo).

dcrwallet certs not accepted by grpc/boring ssl

This isn't really a bug in this project but I'm putting it here to aid in tracking it. Two related bugs are:
grpc/grpc/pull/8601
grpc/grpc/issues/6722

The certs used by dcrwallet (https://github.com/decred/dcrutil/blob/master/certgen.go) are not accepted by grpc because the underlying ssl library does not accept them.

To test I built the latest boringssl on linux and attempted to connected to dcrwallet:

./bssl s_client -connect 127.0.0.1:9110
Connecting to 127.0.0.1:9110
Error while connecting: 141106832:error:1000006b:SSL routines:OPENSSL_internal:BAD_ECC_CERT:/home/jcv/code/boringssl/ssl/ssl_cert.c:821:

The corresponding openssl command:

openssl s_client -connect 127.0.0.1:9110

works fine.

Add functional Send form

For a first pass the send form should include the following things:

• destination address
• destination amount
• account number to use (can just be a text field to start)
• required confirmations

Once those basics are in:

• Dropdown list for accounts to use
• Multiple recipients for Send
• Optional change address This is no longer a requirement of the issue. discussion is below

We would also like to break out the construct/sign/publish into individual steps so users can confirm transaction before sign/publish.