Skip to content
Decred fork of a multisig, HD wallet service. Used by Copay.
Branch: master
Clone or download
Pull request Compare This branch is 13 commits ahead, 1003 commits behind bitpay:master.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
bcmonitor various fixes May 7, 2015
bitcorenode Sync with upstream (#4) Jun 23, 2016
db . Feb 24, 2015
emailservice send email from a separate service May 29, 2015
fiatrateservice
lib Changes required for Copay 3.2.1 (#11) Jun 15, 2017
locker refactor config Apr 15, 2015
messagebroker connect to locker server by default May 11, 2015
pushnotificationsservice Sync with upstream (#4) Jun 23, 2016
scripts Sync with upstream (#4) Jun 23, 2016
test Sync with upstream (#4) Jun 23, 2016
.coveralls.yml Create .coveralls.yml Feb 20, 2015
.gitignore gitignore to include .idea Jun 17, 2015
.travis.yml Sync with upstream (#4) Jun 23, 2016
Dockerfile Added Docker configuration (#12) Jan 2, 2018
LICENCE Update LICENCE Mar 5, 2015
Makefile . Feb 20, 2015
README.md Added Docker configuration (#12) Jan 2, 2018
bws.js Sync with upstream (#4) Jun 23, 2016
config.js Added Docker configuration (#12) Jan 2, 2018
index.js export storage 2 Mar 3, 2015
installation.md corrected note about blockchain explorer service Jun 17, 2015
package.json
start-docker.sh Added Docker configuration (#12) Jan 2, 2018
start.sh Sync with upstream (#4) Jun 23, 2016
stop.sh Sync with upstream (#4) Jun 23, 2016

README.md

bitcore-wallet-service

Decred fork

NPM Package Build Status Coverage Status

A Multisig HD Bitcore Wallet Service.

Description

Bitcore Wallet Service facilitates multisig HD wallets creation and operation through a (hopefully) simple and intuitive REST API.

BWS can usually be installed within minutes and accommodates all the needed infrastructure for peers in a multisig wallet to communicate and operate – with minimum server trust.

See [Bitcore-wallet-client] (https://github.com/bitpay/bitcore-wallet-client) for the official client library that communicates to BWS and verifies its response. Also check [Bitcore-wallet] (https://github.com/bitpay/bitcore-wallet) for a simple CLI wallet implementation that relays on BWS.

BWS have a extensive test suite but have not been tested on production environments yet and have been recently released, so it it is still should be considered BETA software.

More about BWS at https://blog.bitpay.com/announcing-the-bitcore-wallet-suite/

Install

 npm install bitcore-wallet-service
 npm start

This will launch the BWS service (with default settings) at http://localhost:3232/bws/api.

BWS needs mongoDB. You can configure the connection at config.js

BWS supports SSL and Clustering. For a detailed guide on installing BWS with extra features see Installing BWS.

Deployment

Launching BWS using Docker:

docker build -t decred/bws .
docker run --rm -d decred/bws

By default, BWS will try to connect to mongodb on localhost. To specify a custom host, run:

docker run --rm -d -e MONGODB_URI=mongodb://[mongodb host/IP]:27017/bws decred/bws

decred-bws-backend contains configuration for running the full BWS stack.

Security Considerations

  • Private keys are never sent to BWS. Copayers store them locally.
  • Extended public keys are stored on BWS. This allows BWS to easily check wallet balance, send offline notifications to copayers, etc.
  • During wallet creation, the initial copayer creates a wallet secret that contains a private key. All copayers need to prove they have the secret by signing their information with this private key when joining the wallet. The secret should be shared using secured channels.
  • A copayer could join the wallet more than once, and there is no mechanism to prevent this. See wallet's confirm command, for a method for confirming copayers.
  • All BWS responses are verified:
  • Addresses and change addresses are derived independently and locally by the copayers from their local data.
  • TX Proposals templates are signed by copayers and verified by others, so the BWS cannot create or tamper with them.

REST API

Authentication

In order to access a wallet, clients are required to send the headers:

  x-identity
  x-signature

Identity is the Peer-ID, this will identify the peer and its wallet. Signature is the current request signature, using requestSigningKey, the m/1/1 derivative of the Extended Private Key.

See Bitcore Wallet Client for implementation details.

GET Endpoints

/v1/wallets/: Get wallet information

Returns:

/v1/txhistory/: Get Wallet's transaction history

Optional Arguments:

  • skip: Records to skip from the result (defaults to 0)
  • limit: Total number of records to return (return all available records if not specified).

Returns:

  • History of incoming and outgoing transactions of the wallet. The list is paginated using the skip & limit params. Each item has the following fields:
  • action ('sent', 'received', 'moved')
  • amount
  • fees
  • time
  • addressTo
  • confirmations
  • proposalId
  • creatorName
  • message
  • actions array ['createdOn', 'type', 'copayerId', 'copayerName', 'comment']

/v1/txproposals/: Get Wallet's pending transaction proposals and their status Returns:

/v1/addresses/: Get Wallet's main addresses (does not include change addresses)

Returns:

/v1/balance/: Get Wallet's balance

Returns:

  • totalAmount: Wallet's total balance
  • lockedAmount: Current balance of outstanding transaction proposals, that cannot be used on new transactions.
  • availableAmount: Funds available for new proposals.
  • totalConfirmedAmount: Same as totalAmount for confirmed UTXOs only.
  • lockedConfirmedAmount: Same as lockedAmount for confirmed UTXOs only.
  • availableConfirmedAmount: Same as availableAmount for confirmed UTXOs only.
  • byAddress array ['address', 'path', 'amount']: A list of addresses holding funds.
  • totalKbToSendMax: An estimation of the number of KiB required to include all available UTXOs in a tx (including unconfirmed).

POST Endpoints

/v1/wallets/: Create a new Wallet

Required Arguments:

  • name: Name of the wallet
  • m: Number of required peers to sign transactions
  • n: Number of total peers on the wallet
  • pubKey: Wallet Creation Public key to check joining copayer's signatures (the private key is unknown by BWS and must be communicated by the creator peer to other peers).

Returns:

  • walletId: Id of the new created wallet

/v1/wallets/:id/copayers/: Join a Wallet in creation Required Arguments:

  • walletId: Id of the wallet to join
  • name: Copayer Name
  • xPubKey - Extended Public Key for this copayer.
  • requestPubKey - Public Key used to check requests from this copayer.
  • copayerSignature - Signature used by other copayers to verify that the copayer joining knows the wallet secret.

Returns:

  • copayerId: Assigned ID of the copayer (to be used on x-identity header)
  • wallet: Object with wallet's information

/v1/txproposals/: Add a new transaction proposal Required Arguments:

  • toAddress: RCPT Bitcoin address.
  • amount: amount (in atoms) of the mount proposed to be transfered
  • proposalsSignature: Signature of the proposal by the creator peer, using prososalSigningKey.
  • (opt) message: Encrypted private message to peers.
  • (opt) payProUrl: Paypro URL for peers to verify TX
  • (opt) feePerKb: Use an alternative fee per KB for this TX.
  • (opt) excludeUnconfirmedUtxos: Do not use UTXOs of unconfirmed transactions as inputs for this TX.

Returns:

/v1/addresses/: Request a new main address from wallet

Returns:

/v1/txproposals/:id/signatures/: Sign a transaction proposal

Required Arguments:

  • signatures: All Transaction's input signatures, in order of appearance.

Returns:

/v1/txproposals/:id/broadcast/: Broadcast a transaction proposal

Returns:

/v1/txproposals/:id/rejections: Reject a transaction proposal

Returns:

/v1/addresses/scan: Start an address scan process looking for activity.

Optional Arguments:

  • includeCopayerBranches: Scan all copayer branches following BIP45 recommendation (defaults to false).

DELETE Endpoints

/v1/txproposals/:id/: Deletes a transaction proposal. Only the creator can delete a TX Proposal, and only if it has no other signatures or rejections

Returns:

Push Notifications

Installation

In order to use push notifications service, you need install:

Recomended to complete config.js file:

POST Endpoints

/v1/pushnotifications/subscriptions/: Adds subscriptions for push notifications service at database.

DELETE Endopints

/v1/pushnotifications/subscriptions/: Remove subscriptions for push notifications service from database.

You can’t perform that action at this time.