I'm attempting to use the experimental gRPC API to generate an address, however it never completes and the connection will eventually timeout:

The only logs, even on debug mode are:

2019-05-15 17:41:37.300 [INF] GRPC: Unary method /walletrpc.WalletService/NextAddress invoked by <ip>:33470

Here is the code I'm using to make the request https://github.com/RTradeLtd/Temporal/blob/payments/bch/api/v2/routes_payment.go#L227

Here is the code I use to instantiate the client https://github.com/RTradeLtd/Temporal/blob/payments/bch/grpc-clients/bch.go

Creating a simple one input, one output raw transaction and then trying to sign it with Using bchctl --wallet signrawtransaction $RAWTX returns Post https://localhost:8332: EOF

I found that some packages, say github.com/gcash/bchwallet/walletdb, are placed in submodule github.com/gcash/bchwallet/walletdb instead of root module.

However, it seems that submodule github.com/gcash/bchwallet/walletdb is not tagged. According to go docs, submodule should be tagged like relative-path-to-root/vX.X.X.
At now, when trying to import package github.com/gcash/bchwallet/walletdb, downstream would depends on pseudo-version of module github.com/gcash/bchwallet/walletdb.

github.com/gcash/bchwallet/walletdb v0.0.0-20210524044131-61bcca2ae6f9

I think it is not very readable and difficult to upgrade. This is not conductive to version control either.
So, I propose whether it is possible to tag submodule properly. For example, walletdb/v0.0.1, walletdb/v0.10.0etc, so that other project can use tag to import this module in go.mod.

I was wondering is it possible to support multiple wallets?

I wanted to convert some software I have using the deprecated (In Bitcoin Core and Bitcoin ABC) accounts RPC command.

I noticed that bchwallet still is able to handle accounts.

But I also noticed that perhaps it's not best practices anymore and that in fact, I should actually use HDWallets and have users keep track of their 12 word phrase, or allow creating an HD wallet for each user, but bchwallet only supports a single wallet?

Thank you for your hard work on this project.

Right now AFAIK Crescent Cash is the only wallet to implement reusable payment codes with BIP47.
Would be a very welcome privacy enhancing feature to bchwallet / neutrino :)

is it possible to import a master public key to generate receive addresses and then the wallet behaves like a HODL wallet because it cannot send?

I made a small fork of bchwallet and added a proof-of-concept to integrate it into PHP/WordPress on shared hosting providers.

See the README for an explanation of the current PHP problems and possible solutions: https://github.com/Ekliptor/bchwallet

We (James Cramer and me need a solution to integrate bchwallet into WordPress) as the current rest.bitcoin.com solution is not reliable enough

Projects:
https://wordpress.org/plugins/slp-payments-for-woocommerce/
http://cashtippr.com/

I am open for better ideas.

Need to go through all the code and change references of btcwallet to bchwallet. Plus rename btcwallet.go to bchwallet.go to make sure the binary is named correctly.

Also need to update any btcd references to bchd in the docs and README.

I am happy to do this if needed.

Moving issue opened on bchd repo here: gcash/bchd#363

https://explorer.bitcoin.com/tbch/address/bchtest:qqcnquld2mak3x4x0ezfq4ag5nsg2lr7z59vwy7tan

Steps:

run bchd --reindexchainstate --addrindex --txindex
do dropwtxmgr on testnet wallet.db
connect bchwallet, use bchctl walletpassphrase to unlock
with bchctl I tried various commands to getbalance account and listreceivedbyaccount
Result
bchctl getreceivedbyaddress qqcnquld2mak3x4x0ezfq4ag5nsg2lr7z59vwy7tan 1
0

bchd.conf
txindex=1
testnet=1
rpcuser=bitcoinrpc
rpcpass=password

Hi,

is it possible to use bchd in multi wallet mode?

where do I find the complete list of api-json-rpc, both for bchd and bchdwallet?

where I find some examples on how to create wallets to create transactions, cost estimates etc.

Thanks in advance

Have not yet looked at how keys are derived in the code. If it doesn't use bip44, then let's make it use that.

If it does use bip44, the coinType will need to be updated to 145 (0x80000091) for Bitcoin Cash.

• Create functions to download, validate, and return a BIP70 payment request

• Expose this function via the gRPC API.

• Stretch goal expose this function to the CLI.

Importing WIF keys using importprivkey triggers a rescan, but no UTXOs are present when completed.

@musashidev I had hoped your backports would resolve this but unfortunately the issue persists.

Description says it all. Need to handle and return error.

Im trying to connect using the SPV mode in Ubuntu 20.04 with the wallet "bchwallet-linux_amd64.zip" published in https://github.com/gcash/bchwallet/releases

When I launch the wallet with ./bchwallet --usespv -u user -P 1234 -d=debug
I get this error with all peers:

[DBG] BCHN: Received reject (cmd verack, code REJECT_MALFORMED, reason a verack message must follow version) from 136.243.250.139:8333 (outbound)

The files in the mainnet folder never update. I have tried removing all files and creating a new wallet but the problem persists.

Sample output:

2020-05-07 13:05:23.897 [INF] BCHW: Version 0.8.2
2020-05-07 13:05:23.908 [INF] RPCS: Listening on 127.0.0.1:8332
2020-05-07 13:05:23.909 [INF] BCHN: Loaded 20 addresses from file
2020-05-07 13:05:23.909 [DBG] BCHN: Starting block notifications subscription manager
2020-05-07 13:05:23.913 [DBG] BCHN: Waiting for peer connection...
2020-05-07 13:05:23.913 [INF] BCHN: Registering block subscription: id=1
2020-05-07 13:05:23.913 [DBG] BCHN: Delivering backlog of block notifications: id=1, start_height=0, end_height=0
2020-05-07 13:05:23.913 [INF] BCHN: Broadcaster now active
2020-05-07 13:05:24.012 [DBG] BCHN: Sending version (agent neutrino:0.0.4-beta/, pver 70013, block 0) to 136.243.250.139:8333 (outbound)
2020-05-07 13:05:24.052 [DBG] BCHN: Sending version (agent neutrino:0.0.4-beta/, pver 70013, block 0) to 3.85.109.130:8333 (outbound)
2020-05-07 13:05:24.056 [DBG] BCHN: Sending version (agent neutrino:0.0.4-beta/, pver 70013, block 0) to 3.222.251.214:8333 (outbound)
2020-05-07 13:05:24.064 [DBG] BCHN: Sending version (agent neutrino:0.0.4-beta/, pver 70013, block 0) to 3.222.251.214:8333 (outbound)
2020-05-07 13:05:24.070 [DBG] BCHN: Received version (agent /bchd:0.15.2(EB32.0)/, pver 70015, block 634070) from 136.243.250.139:8333 (outbound)
2020-05-07 13:05:24.070 [DBG] BCHN: Negotiated protocol version 70013 for peer 136.243.250.139:8333 (outbound)
2020-05-07 13:05:24.070 [DBG] BCHN: Added time sample of 0s (total: 1)
2020-05-07 13:05:24.070 [DBG] BCHN: Connected to 136.243.250.139:8333
2020-05-07 13:05:24.070 [INF] BCHN: New valid peer 136.243.250.139:8333 (outbound) (/bchd:0.15.2(EB32.0)/)
2020-05-07 13:05:24.070 [INF] BCHN: Syncing to block height 634070 from peer 136.243.250.139:8333
2020-05-07 13:05:24.070 [INF] BCHN: Downloading headers for blocks 1 to 11111 from peer 136.243.250.139:8333
2020-05-07 13:05:24.070 [DBG] BCHN: Sending getaddr to 136.243.250.139:8333 (outbound)
2020-05-07 13:05:24.070 [DBG] BCHN: Sending verack to 136.243.250.139:8333 (outbound)
2020-05-07 13:05:24.070 [DBG] BCHN: Received verack from 136.243.250.139:8333 (outbound)
2020-05-07 13:05:24.070 [DBG] BCHN: Sending getheaders (locator 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, stop 0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d) to 136.243.250.139:8333 (outbound)
2020-05-07 13:05:24.074 [DBG] BCHN: New peer 136.243.250.139:8333 (outbound)
2020-05-07 13:05:24.074 [DBG] BCHN: Peer connected, starting cfHandler.
2020-05-07 13:05:24.074 [INF] BCHN: Waiting for more block headers, then will start cfheaders sync from height 0...
2020-05-07 13:05:24.083 [DBG] BCHN: Sending version (agent neutrino:0.0.4-beta/, pver 70013, block 0) to 35.209.240.120:8333 (outbound)
2020-05-07 13:05:24.090 [DBG] BCHN: Sending version (agent neutrino:0.0.4-beta/, pver 70013, block 0) to 3.88.239.185:8333 (outbound)
2020-05-07 13:05:24.128 [DBG] BCHN: Received reject (cmd verack, code REJECT_MALFORMED, reason a verack message must follow version) from 136.243.250.139:8333 (outbound)
2020-05-07 13:05:24.128 [INF] BCHN: Lost peer 136.243.250.139:8333 (outbound)
2020-05-07 13:05:24.128 [WRN] BCHN: No sync peer candidates available
2020-05-07 13:05:24.128 [DBG] BCHN: Removed peer 136.243.250.139:8333 (outbound)
2020-05-07 13:05:24.145 [DBG] BCHN: Sending version (agent neutrino:0.0.4-beta/, pver 70013, block 0) to 76.102.192.81:8333 (outbound)
2020-05-07 13:05:24.160 [DBG] BCHN: Received version (agent /bchd:0.16.0(EB32.0)/, pver 70015, block 634070) from 3.222.251.214:8333 (outbound)
2020-05-07 13:05:24.160 [DBG] BCHN: Negotiated protocol version 70013 for peer 3.222.251.214:8333 (outbound)
2020-05-07 13:05:24.160 [DBG] BCHN: Added time sample of 0s (total: 2)
2020-05-07 13:05:24.160 [DBG] BCHN: Connected to 3.222.251.214:8333
2020-05-07 13:05:24.160 [DBG] BCHN: Received verack from 3.222.251.214:8333 (outbound)
2020-05-07 13:05:24.160 [INF] BCHN: New valid peer 3.222.251.214:8333 (outbound) (/bchd:0.16.0(EB32.0)/)
2020-05-07 13:05:24.160 [INF] BCHN: Syncing to block height 634070 from peer 3.222.251.214:8333
2020-05-07 13:05:24.160 [INF] BCHN: Downloading headers for blocks 1 to 11111 from peer 3.222.251.214:8333
2020-05-07 13:05:24.160 [DBG] BCHN: Sending getaddr to 3.222.251.214:8333 (outbound)
2020-05-07 13:05:24.160 [DBG] BCHN: Sending verack to 3.222.251.214:8333 (outbound)
2020-05-07 13:05:24.160 [DBG] BCHN: Sending getheaders (locator 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, stop 0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d) to 3.222.251.214:8333 (outbound)

There are a couple tests that seem to sometimes fail and sometimes pass on travis. The error is always Failed to create Manager: failed to master public key: unable to decrypt. Since travis runs the tests for different versions of Go it's almost a guarantee that one of them will fail and need to be restarted.

I can't get this to replicate on my home machine. Tests pass 100% of the time for me. So I'm finding it difficult to debug.

The mnemonic seed provided for the creation of a new wallet is not validated.

It is created with the method NewSeed from github.com/tyler-smith/go-bip39
The same library provides tools for validating the seed that could be used.
This issue could lead to the creation of insecure wallets from unaware developers.

Also unrelated: for using a SPV wallet with --noinitialload something like this could be implemented,

if cfg.NoInitialLoad {
	// Ensure the data directory for the network exists.
	if err := checkCreateDir(netDir); err != nil {
		fmt.Fprintln(os.Stderr, err)
		return nil, nil, err
	}
}

Thank you for this project!

bchd version 0.16.0
bchwallet version 0.8.2
bchctl version 0.16.0

bcdd.conf
fastsync=1
prune=1
prunedepth=288

Steps:

1. bchd createnewaccount account12
2. bchctl getnewaddress account12
3. send BCH to this new addresses
4. bchctl getbalance account12 1
   0
5. Then sometime after that bchwallet closes down and can't reopen.

2020-05-02 10:39:05.506 [INF] WLLT: Opened wallet
2020-05-02 10:40:14.831 [ERR] WLLT: Cannot fetch new account properties for notification after account creation: address manager is locked
2020-05-02 10:40:31.494 [INF] WLLT: The wallet has been temporarily unlocked
2020-05-02 11:00:33.654 [ERR] CHNS: Websocket receive error from localhost:18334: websocket: close 1006 unexpected EOF
2020-05-02 11:00:33.657 [INF] CHNS: Failed to connect to localhost:18334: dial tcp 127.0.0.1:18334: connect: connection refused
2020-05-02 11:00:33.657 [INF] CHNS: Retrying connection to localhost:18334 in 5s
^X^C2020-05-02 11:00:36.255 [INF] BCHW: Received signal (interrupt). Shutting down...
2020-05-02 11:00:36.255 [WRN] BCHW: Stopping legacy RPC server...
2020-05-02 11:00:38.658 [INF] BCHW: Legacy RPC server shutdown
2020-05-02 11:00:38.658 [INF] BCHW: Shutdown complete
steve@MacBook-Pro ~ % bchwallet
2020-05-02 11:02:35.158 [INF] BCHW: Version 0.8.2
2020-05-02 11:02:35.168 [INF] RPCS: Listening on 127.0.0.1:8332
2020-05-02 11:02:35.168 [INF] BCHW: Attempting RPC client connection to localhost:8334
2020-05-02 11:02:35.200 [INF] CHNS: Established connection to RPC server localhost:8334
2020-05-02 11:02:35.913 [INF] WLLT: Opened wallet
2020-05-02 11:02:36.947 [INF] WLLT: RECOVERY MODE ENABLED -- rescanning for used addresses with recovery_window=250
2020-05-02 11:02:38.692 [INF] WLLT: Seed birthday surpassed, starting recovery of wallet from height=632985 hash=000000000000000004859ebde01898003052ccf27f9a97a3204cff1048d7389e with recovery-window=250
2020-05-02 11:02:38.693 [INF] WLLT: Scanning 10 blocks for recoverable addresses
2020-05-02 11:02:38.833 [ERR] CHNS: Websocket receive error from localhost:8334: websocket: close 1006 unexpected EOF

steve@MacBook-Pro ~ % bchwallet
2020-05-02 12:37:04.384 [INF] BCHW: Version 0.8.2
2020-05-02 12:37:04.394 [INF] RPCS: Listening on 127.0.0.1:8332
2020-05-02 12:37:04.394 [INF] BCHW: Attempting RPC client connection to localhost:8334
2020-05-02 12:37:04.425 [INF] CHNS: Established connection to RPC server localhost:8334
2020-05-02 12:37:05.092 [INF] WLLT: Opened wallet
2020-05-02 12:37:06.099 [INF] WLLT: RECOVERY MODE ENABLED -- rescanning for used addresses with recovery_window=250
2020-05-02 12:37:07.816 [INF] WLLT: Seed birthday surpassed, starting recovery of wallet from height=633121 hash=0000000000000000026c46e5090930c04822dad511f1342b96fba93b4d508a0e with recovery-window=250
2020-05-02 12:37:07.818 [INF] WLLT: Scanning 10 blocks for recoverable addresses
panic: Unable to synchronize wallet to chain: unable to perform wallet recovery: -5: The bchd version 0.16.0 must be enabled for this command

goroutine 40 [running]:
github.com/gcash/bchwallet/wallet.(*Wallet).handleChainNotifications(0xc000503380)
/Users/steve/bchwallet/wallet/chainntfns.go:117 +0x13f3
created by github.com/gcash/bchwallet/wallet.(*Wallet).SynchronizeRPC
/Users/steve/bchwallet/wallet/wallet.go:222 +0x1aa

bchwallet --version bchwallet version 0.9.0
bchd --version bchd version 0.16.3
bchwallet --simnet --noclienttls --noservertls --username admin --password adminpass —rpcconnect localhost:18556

I'm trying to connect to bchwallet through python http post

import getpass
import json
import requests
from requests.auth import HTTPBasicAuth
# python json rpc

# bchd
# URL = "http://127.0.0.1:18556/"

# bchwallet
URL = "http://127.0.0.1:18554/"


def instruct_wallet(method, params):
    payload = json.dumps({"jsonrpc":"1.0","id":"0","method": method, "params": params})
    headers = {'content-type': "application/json", 'cache-control': "no-cache"}
    try:
        response = requests.request("POST", URL, data=payload, headers=headers, auth=HTTPBasicAuth(rpc_user, rpc_password))
        print( json.loads(response.text))
    except requests.exceptions.RequestException as e:
        print (e)
    except:
        print(response)
        # print ('No response from Wallet, check Bitcoin is running on this machine')

rpc_user='admin'
rpc_password='adminpass'

# instruct_wallet('getinfo', [])
instruct_wallet('getbalance', [])

and got this error

Default (0') is here (see comments).

Someone who can inject their own Coin type doesn't need this. For everyone else, it seems worth making it explicit in documentation and/or wallet creation (requires update to bchctl). Current documentation is a generic string:

bchwallet uses the m/44'/<coin type>'/<account>'/<branch>/<address index> HD path for all derived addresses, as described by BIP0044.

Does that sound reasonable or am I missing something obvious?

$go get github.com/gcash/bchwallet

github.com/gcash/bchwallet/internal/legacy/keystore

../src/github.com/gcash/bchwallet/internal/legacy/keystore/keystore.go:2258:21: privKey.Sign undefined (type *bchec.PrivateKey has no field or method Sign)

The wallet currently uses a hex string for the wallet seed. We should use bip39 as it's more standard.
Code here https://github.com/tyler-smith/go-bip39

The chaincfg.Params object in bchd contains a HDCoinType field which specifies the bip44 cointype. For Bitcoin (btc) the cointype is 0, but according to the bip44, Bitcoin Cash is given the cointype of 145 (and testnet is 1).

The problem we have is the bchwallet has hardcoded the cointype to 0 and doesn't bother to load the cointype from the params. If we change the hardcoded cointype to 145 it breaks a lot of tests (which are rather poorly written as it causes panics that are difficult to trace through), and further the cointype would not be loaded from the params so, for example, testnet will not use 1.

The question for us is do we want to use a cointype of 145 to be consistent with the bip44 spec? Is anyone else doing that? If so, do we want to put in the work to make it load the cointype from the params (which is quite a bit of work).

A decision should be made before the wallet is released because changing it afterwards can break compatibility with existing users.

The difficulty rules are not implemented in neutrino. It may be possible to just import the blockchain package from bchd. If not a simple copy and paste might work.

The following doesn't work:

$ go get github.com/gcash/bchwallet
go: go.mod file not found in current directory or any parent directory.
        'go get' is no longer supported outside a module.
        To build and install a command, use 'go install' with a version,
        like 'go install example.com/cmd@latest'
        For more information, see https://golang.org/doc/go-get-install-deprecation
        or run 'go help get' or 'go help install'.

The recommended way is to use 'go install', however the following error occurs when trying this:

$ go install github.com/gcash/bchwallet@latest
go: downloading github.com/gcash/bchwallet v0.10.0
go: github.com/gcash/bchwallet@latest (in github.com/gcash/[email protected]):
        The go.mod file for the module providing named packages contains one or
        more replace directives. It must not contain directives that would cause
        it to be interpreted differently than if it were the main module.

Not 100% sure but I think CTOR may prevent the wallet from learning of relevant transactions. I've taken a brief look at the code and it looks like the fix may be as easy as modifying this function in chain/block_filterer.go to sort the block in topological order before checking each tx for relevancy.

func (bf *BlockFilterer) FilterBlock(block *wire.MsgBlock) bool {
	var hasRelevantTxns bool
	for _, tx := range block.Transactions {
		if bf.FilterTx(tx) {
			bf.RelevantTxns = append(bf.RelevantTxns, tx)
			hasRelevantTxns = true
		}
	}

	return hasRelevantTxns
}

If this is indeed all that is needed it looks like the topological sort may not be that resource intensive as it appears this function is only call if the block matches the CF filter. Which means we'd expect it to be a relatively small number of blocks that match and thus require sorting.

Is there a less intensive way of handling CTOR than doing a full sort of the block?