$HOME/.dcrwallet/dcrwallet.conf:88: unknown option: dcrusername

works fine as dcrdusername and dcrdpassword

After changing sstxfee wallet is not inserting sstx . Its been 10hours no luck . Now even after i changed it default vaule 0.05 its not inserting sstx transaction

waddrmgr can rarely panic when importing useful multisignature address redeemscripts from unconfirmed transactions.

As the title says, the JSON-RPC server should be returning a WWW-Authenticate header when it receives invalid credentials.

See the btcsuite/btcd code here for the proper handling:
https://github.com/btcsuite/btcd/blob/528ddaf23e0a68666a9992b81f978e49e2c61f5e/rpcserver.go#L3895-L3899

When attempting to create a new wallet with the --create when a wallet already exists, the application prints The wallet already exists. This is obviously correct behavior, but I'd suggest this is changed to include the path since otherwise it can be difficult to know where the wallet lives.

So, for example:

A wallet already exists at '/path/to/existing/wallet'.

There is currently no fees calculation for revocations. The size of the revocation is known before hand, so this should be patched to correctly calculate the correct amount of fees.

dcrwallet does not use the balancetomaintain option from the config file or the command line completely correctly. This has been an issue for some time but has gone unreported. The ticketmaxprice works as expected, but as soon as that condition is met the wallet grabs the entire balance to buy tickets, but doesn't buy them.

even with valid tickets and the --enablestaking flag

setgenerate 1
getgenerate
false

The access of IsClosed outside of a mutex runs the risk of racing. Access should be moved to inside the mutex.

query dcrcoin keypoolrefill 100
query dcrcoin getinfo
{
"version": 100,
"protocolversion": 1,
"walletversion": 4,
"balance": 0,
"blocks": 4306,
"timeoffset": 0,
"connections": 3,
"proxy": "",
"difficulty": 199771.58352835,
"testnet": true,
"keypoololdest": 1454271842,
"keypoolsize": 0,
"unlocked_until": 0,
"paytxfee": 0.01,
"relayfee": 1e-05,
"errors": ""
}

If keypoolsize is deprecated, can we use a static 100 or something large so people dont think the keypool is empty

There are a few places where the rpc server returns scientific notation that should probably be decimal to be consistent with everything else. This was pointed out by Emilio Mann on the forum:

fee in listtransactions

paytxfee and relayfee in getinfo

Reported by simple on IRC.

I confirmed it as well:

$  dcrwallet -h
...
  /c, /rpcconnect:          Hostname/IP and port of dcrd RPC server to connect
                            to (default localhost:18334, mainnet:
                            localhost:8334, simnet: localhost:18556)
...
      /rpclisten:           Listen for RPC/websocket connections on this
                            interface/port (default port: 18332, mainnet: 8332,
                            simnet: 18554)
...

The correct ports should be as follows:

dcrd:
mainnet: 9109
testnet: 19109
simnet: 18556

dcrwallet:
mainnet: 9110
testnet: 19110
simnet: 18557

Also, the dcrd simnet port looks to be the same as it is for btcd. I think it should be changed to something unique for decred as well.

The wallet is currently lacking the ability to adjust these parameters from the RPC.

In the latest wallet (after the btcwallet sync) only the hex is shown when creating a new wallet. The pgpwordlist version should also be shown.

One for real sent amount and another one with the input bloc time, seems to be "spent transactions"

I was unable to filter them easily except for mined/generated coins. "category": "send" and "generated": true

needed += feeForSize(feeIncrement...)

but then:

return w.createTx(eligible, pairs, bs, w.FeeIncrement...)

This should be looked into to ensure that correct functionality is achieved.

Also should fix/remove all with FeeIncrement switch/cases that are throughout

Fees appear to be calculated incorrectly in listtransactions/getransaction.

{ "amount": 0, "fee": 23.99999, "confirmations": 0, "blockhash": "", "blockindex": 0, "blocktime": 0, "txid": "f8ffa009d4e9618c5250288718c8ce342bd8859a6d7c553b6c60acb009265136", "walletconflicts": [], "time": 1454058589, "timereceived": 1454058589, "details": [ { "account": "", "amount": -12, "category": "send", "fee": 23.99999, "vout": 0 } ], }

We assign GUIDs to address to make sure not only the address matches, but the guid matches as extra security. listtransactions doesn't properly populate the field.

query dcrcoin validateaddress "TsXfyM6SLS1JhqXDds58YGoMEQuuyMdQj7X"
{
"isvalid": true,
"address": "TsXfyM6SLS1JhqXDds58YGoMEQuuyMdQj7X",
"ismine": true,
"pubkeyaddr": "TkKmN6PYmKy6Q7qMhJmqtFUc5Yrnx2CRMAdd2KFwhrJL4WDEohWBG",
"pubkey": "026b1bc6c1c7068f09771ffcad32b3b53da33e0f9545c760d970c4ce49ba2661d7",
"iscompressed": true,
"account": "d25f76a6-da7b-456c-b615-dee68d859362"
}

query dcrcoin listtransactions
[
{
"account": "",
"address": "TsXfyM6SLS1JhqXDds58YGoMEQuuyMdQj7X",
"amount": -50,
"category": "send",
"confirmations": 0,
"fee": -0.01,
"time": 1454270237,
"timereceived": 1454270237,
"txid": "647a664a1b8c01d27ba7b9bbe619c1413b83abd4928ff798d40dfa3a353e6bdb",
"vout": 1,
"walletconflicts": []
},
{
"account": "",
"address": "TsXfyM6SLS1JhqXDds58YGoMEQuuyMdQj7X",
"amount": 50,
"category": "receive",
"confirmations": 0,
"time": 1454270237,
"timereceived": 1454270237,
"txid": "647a664a1b8c01d27ba7b9bbe619c1413b83abd4928ff798d40dfa3a353e6bdb",
"vout": 1,
"walletconflicts": []
},

this is nit picky, but causes a problem because comments aren't supported yet and a lot of btc libraries include all the parameters in the interface.

if sendtoaddress is called with empty strings, it should complete the transaction without throwing the error.

I have no repro but we have seen dcrd return previously used addresses when calling getnewaddress multiple times.

in this case, the counter looked to be rolled back 4 addresses (ie, i called getnewaddress 4 times before getting an address that wasn't previously used).

According to decred.org:

Free and Open-Source Software

Where is the source code for dcrwallet?

When transactions are created there is no checking as to whether any outputs would be considered dust by dcrd. Instead of just sending them to subsequently get an err (output 0 of 100000 is considered dust) back from dcrd, we should check outputs are above isDust threshold. If not return an error (without sending along tx), and a note to suggest using the soon to be available consolidate RPC. But again, if the output value is too small, no consolidation would help that. Dust is still dust.

Sorry this is a better place for this issue than dcrd maybe. Delete issue in dcrd if need be.

Many people cannot purchase PoS tickets because it ignores the account you specify and tries to use default. Also looks like the move command is broken.

C:\Program Files\Decred>dcrctl -u -P --wallet purchaseticket CodyF86 2
-4: not enough to purchase sstx

C:\Program Files\Decred>dcrctl -u -P --wallet listaccounts
{
"CodyF86": 30.50512524,
"default": 0,
"imported": 0
}

C:\Program Files\Decred>dcrctl -u -P --wallet move CodyF86 default 10
-1: Request unsupported by dcrwallet

It would be great if GUIs could create wallet's from a simple command line command. At this moment it is almost impossible to create wallets from anything but the command line, because stdio emulation won't work when asked for passwords.

query dcrcoin listreceivedbyaddress 0 true
-4: no transaction details could be found

This should list every address in the wallet... include minconf = 0 and includeempty=true

The cursor for new addresses from the default account is correctly incremented for the getnewaddress function, but it is possible to get a list of used and unused addresses from the getaddressesbyaccount. The getaddressesbyaccount call should also take into account the current cursor of the address pool and not return unused addresses. Without this, the user becomes in danger of reusing their addresses.

When issuing a getbalance RPC call with the balancetype set to all, the balance does not include unconfirmed coins in the balance as it should.

$ dcrctl --testnet --wallet getbalance "default" 0
1080.99029897
$ dcrctl --testnet --wallet getbalance "default" 0 all
1076.13881383

See http://play.golang.org/p/nNtX7BaIsC for why.

I have a wallet from which I did a few ticket purchases. when I do dcrctl ... --wallet gettickets 1, I can see the list of all my immature tickets.

In order to avoid the risk of missing a vote I started 2 other instance of dcrwallet on other systems. using the same seed. On creation, dcrd and the wallets will sync up to the most recent block and I can see the same tickets and transactions.

However if I make new ticket purchase from my first system (only that one is used for purchase). The 2 other wallets will randomly or not see the new ticket even 6 hours later.

When I check the dcrd and dcrwallet window on all system they all have processed the most recent block (624 at this time). If I take the transaction id from my main wallet I can verify that it was successfully received with the mainnet web block explorer. Restarting dcrwallet on the 2 redundant systems will sometime add one or 2 new transaction but most of the time not.

If I use the transaction id and do a search on all systems, the one on which the purchase was made will see the transaction, and the others will find no record of that transaction even if they have processed the corresponding block recently or a while back.

The only way I have found to force a wallet to sync up is to delete it and recreate it. On creation it will sync everything and then it will report all the tickets and transactions.

Also, I am not sure this issue is only affecting redundant wallets because after 350 blocks were created yesterday, the wallet I created at launch with my previous seed still couldn't see my airdrop even though the transactions was listed in the block explorer and all daemons were telling me they were up to date with the latest block. It's only after I deleted my wallet and recreated it that I was able to see the transaction and correct balance.

All systems use v0.0.4, are on windows system and on different networks

To show a custom number of entries i had to use the wallet --terminal to be able to use the "*"

on the linux command line * means all files, tried to quote and use backslashes without success

I suggest to allow the empty string "" as account to list all, like its explained in help (* or unset)

Stake tickets that don't get accepted before the difficulty rises get "stuck" in the wallet and a restoration from seed is required to remove them. The correct behaviour would be tickets purchased having an expiry and being removed from the wallet after their expiration.

The RPC calls also need to be updated so that adding an expiry is possible. Pruning of other transactions that are expired should happen in addition to the above change.

query dcrcoin getnewaddress a1c021f5-17ea-46a6-b08e-4ca7a6f0a1e6
-4: account name 'a1c021f5-17ea-46a6-b08e-4ca7a6f0a1e6' not found

I understand that i can call 'createnewaccount' first, but to keep things closer to btc (and to not disrupt current btc workflows) getnewaddress should just check if the account exists... if it doesn't, it should createnewaccount and then getnewaddress.

Not sure why this is happening. The GetStakeInfoCmd type is registered by dcrjson, and the help texts are included in the rpchelp package (helpdescs_en_US.go) but no help texts are created for the command when the help descriptions map is generated (by running go generate in rpc/legacyrpc package). go generate -x does show the generators being run.

The extended public key network is not checked when passing an extended public key to a watching only wallet.

User jdavidof from freenode reports that they received the following err:

-32603: insufficient funds: transaction requires 4 Coin input but only 4.04366253 Coin spendable

even after using:

dcrctl --wallet settxfee 0.01

they subsequently tried to send 3.99 and it was successfully sent:
https://mainnet.decred.org/tx/ec1a97aef09a6f22d459fc8fd8fdb713613b66b149f946bcae06950968908831

User has spendable/mature coins, but unable to sendtoaddress "addr" 2.

Though they were able to successfully send with sendfrom Main "addr" 2.

Appears that an alternative account is being created and is not usable under current sendtoaddress conditions.

https://github.com/decred/dcrwallet/tree/master/rpc/documentation
With the new arrival of btcwallet's new gRPC server, the associated documentation needs to be updated to properly refer to various things ie bitcoin --> decred, update ports etc.

There is no way for a user to look up their votes and vote subsidy in the wallet. A JSON RPC call should be added to facilitate this.

dcrcoin gettransaction 60fbd3092222d26c887188358436d5158c3d7d7ab695782d35dadc66a0f72f71
{
"amount": 0.95,
"confirmations": 24,
"blockhash": "0000000000005843ea1b5122d75d0f6415c9b37ebb9258dd5b5ba7b67f856315",
"blockindex": 0,
"blocktime": 1454981933,
"txid": "60fbd3092222d26c887188358436d5158c3d7d7ab695782d35dadc66a0f72f71",
"walletconflicts": [],
"time": 1454981888,
"timereceived": 1454981888,
"details": [
{
"account": "",
"address": "DsYrr6HAiyceXwvfzhYk1WCHxLctokGjEUM",
"amount": 0.95,
"category": "receive",
"vout": 0
}
],
"hex": "01000000010855c1022575bc9608b929d79d599a8dcecd3b71a3374ebb52857561af42fb1d0100000000ffffffff02c095a9050000000000001976a914569bac4b9c765c5aa2ace4d56f75e38a3c61896a88ac222305010000000000001976a914786d11b73005815d283c6d1e6ce0e28b8586eb1788ac000000000000000001ffffffffffffffff00000000ffffffff6b4830450221009c53bcb55bf79aac1744176e4f9cd1364e87f551c1e5d11edf14cb1aba88e0f402201e64684a2c7ee343b7e737069777c2350031965b6da001648b2b4f7ac168029d012103b0c45f1190b0b6309b134e57b5ca6a10dd0bf76e66e4f72418c522e2fdc2266c"
}

the same transaction using listtransactions
{
"account": "3ed3b1bd-c1aa-4a49-ac3e-d60bb7a1ef01",
"address": "DsYrr6HAiyceXwvfzhYk1WCHxLctokGjEUM",
"amount": 0.95,
"blockhash": "0000000000005843ea1b5122d75d0f6415c9b37ebb9258dd5b5ba7b67f856315",
"blocktime": 1454981933,
"category": "receive",
"confirmations": 25,
"time": 1454981888,
"timereceived": 1454981888,
"txid": "60fbd3092222d26c887188358436d5158c3d7d7ab695782d35dadc66a0f72f71",
"vout": 0,
"walletconflicts": []
},

Feb 8 12:35:32 i5 mainnet: fdc(main): /home/coins/wallets/fdc/.dcrwallet/dcrw
allet.conf:8: unknown option: mainnet

When rescanning from seed, the last used address should be set in the wallet database so that when the address pool is initially the next correct address may be used. Right now it generates all the addresses in waddrmgr but fails to put the cursor for the address pool in the correct place, introducing a large gap of unused addresses.

...or doesn't work the way I expected.

I see this in my log:

07:16:20 2016-02-10 [INF] WLLT: Stake mining is enabled. Votebits: 1, minimum wallet balance 50

However, all of my dtc were spent on a ticket and it seemed to ignore the minimum wallet balance.

In case it helps, this is the transaction:
https://mainnet.decred.org/tx/7e8487b7b81f37b8b5cfb7042be539872962815e443233eaf08ad797ad5d71ae

After updating dcrwallet today, getstakeinfo is broken:

decred@ubuntu1604:~$ dcrctl --wallet getstakeinfo
-32602: wrong number of params (expected between 0 and 1, received 2)

To me it feels very weird that I can only have a single wallet on my machine in a fixed place. Is it possible to have the option for me to specify the wallet location so I can have multiple wallets on one machine in the location I prefer? I can imagine that some households have multiple users using the same account both wanting to have their own wallet.

Below is an example. The 'imported' account has 15 coins in one imported address.

--wallet sendfrom imported TsccTV6aBctUPVht3TcHnNyL2qfUUuYfqXo 10
-32603: insufficient funds: transaction requires 10 Coin input but only 56.48416839 Coin spendable

Balance is wrong after a successful send. It fixes it self after blocks confirm.

It appears this issue was inherited from btcwallet.

https://github.com/btcsuite/btcwallet/blob/master/wallet/wallet.go#L695-L710

Calls to the w.lockRequests channel should cause the wallet to lock, but rather it sets the timeout to nil which causes it to never trigger the lock.

Running this command
dcrwallet -u user -P password

The plain text password is displayed.

sometimes when trying to send coins I got this message:

E0078: RPC method did not return 200 OK: Address: xxxxxxxxxxxxxxxxxxx ERROR: Response error or empty: -22: TX rejected: transaction def2d3bea20f8928e359c218c64cd210f967a434d7a5d5d9a5edc9c1e500a232 has insufficient priority (2.529764803846154e+07 <= 5.76e+07)

currently listtransactions returns newest first instead of oldest first; this is opposite from bitcoin's listtransactions json.