Okay, here is what I found for each item: list transactions 1 - fee: format is in scientific notation, decimal is correct I'll open an issue for this. 2 - list order is incorrect, the most current to the oldest, must be the oldest to the most current This is https://github.com/decred/dcrd/issues/3 3 - I can not list transactions with parameters: ./dcrctl --testnet --notls -u user1 -P passTest1 --wallet listtransactions "test" count=10 from=0 includewatchonly=false listtransactions command: parameter #2 'count' must parse to a int (code: ErrInvalidType) Usage: listtransactions ("account" count=10 from=0 includewatchonly=false) The proper way to do this is: ./dcrctl --testnet --notls -u user1 -P passTest1 --wallet listtransactions "test" 10 0 false Unfortunately, that gives you the result: jcv@yoshi ~ $ dcrctl --wallet listtransactions "default" 10 0 false -4: Transactions are not yet grouped by account which I believe is a btcwallet issue. getaddressesbyaccount does not work to list all the untitled accounts addresses in the wallet Do you have any more info, this looks okay to me so I need some help reproducing. getinfo 1 - the balance is zero, but i can send coins This was fixed in latest master 2 - some formats are in scientific notation I'll open an issue for this. sendtoaddress does not send correctly, it works better when the previous transaction has been confirmed, have not figured out the real reason for the malfunction I could use more info on this one. I've used sendtoaddress without issue. walletpassphrase - sometimes it takes more than 20 seconds, unnecessarily Most likely the wallet is doing something else (and the wallet unlock is generally not a fast operation). The rpc server is slow so this will have to wait until some ongoing improvements in btcwallet get merged in.
@Dyrk there isn't a direct way but on linux at least you could do something like: dcrctl getbestblock | grep height "height": 4901 Then take that number and: for i in `seq 0 4901`; do dcrctl getblockhash $i; done
The following single line command does what @jcv is suggesting as well without any need to manually look up the number: Code: for i in $(seq 0 $(dcrctl getblockcount)); do dcrctl getblockhash $i; done
After three days my tx still isn't confirmed. Can anyone check if it has been confirmed, or create a raw tx to resend it?
In order for someone to look into this, you must provide a transaction hash. I checked your earlier post and it did not include a transaction hash.
It is, it's in the "Spoiler: tx" button. I copied it from there: "txid": "8502f4a2edd23ea55bb9e59948714001266d43828f73afc31993f6988d672db4",
Possible issue here guys... Here is the situation. I am testing with 3 computers. One Windows, one Ubuntu VM, and one Raspberry Pi. I have one testnet wallet generated on each of them using the same seed (which I have verified on each machine using ./dcrctl --wallet getseed). The balance of the wallet on the Windows and Ubuntu machines match. The wallet balance on the Raspberry Pi board is roughly 11 coins less than the balance on the other two. The dcrd daemon is running independently on each device, and the blockchain is fully synced on each of them. I have went through and compared all the transactions in ./dcrctl --wallet listtransactions, they all matched up. I then checked my PoS tickets with ./dcrctl --wallet gettickets true, and this is where I found the discrepancy. The ticket with the hash abf050af312163324fa67ffd8e260e4069864a559389a42e3100c0b8667329eb is on both the Windows and Ubuntu machine, but it's missing from the Raspberry Pi (which has the lower balance). What could be the cause? Is it a bad idea to keep the same wallet online in multiple instances that I have done here?
@David what model raspberry pi is it? I've found that anything before the rpi2 just cannot keep up and is always either behind of otherwise having problems.
It's the raspberry Pi 2 model B. It's been keeping up fine so far.. I have Ubuntu LXDE (edit: 14.10) on it and it handles great... the initial blockchain download and processing was slow but it seems to be doing ok now.
@David My guess is that your wallet on the Pi hasn't generated the new address yet, so it doesn't recognize the ticket as yours. This is a general issue with running wallets on multiple machines. They don't know when a new address was generated by one of the other ones, so from their point of view, the new addresses aren't known yet. Think of it like this: Machine A: Wallet is at address #15 Machine B: Wallet is at address #12 Machine C: Wallet is at address #9 So Machine B won't know about anything going on with addresses #13, #14, and #15, and machine C won't know about anything going on with addresses #10-#15. Try issuing $ dcrctl --wallet getaccountaddress "default" on all of the wallets and you'll probably see they all have different addresses for the current address. So, if you issue $ dcrctl --wallet getnewaddress a few times on the Pi2 wallet you'll likely end up syncing up.
@David I should also note that wallet can be configured to listen on !localhost via --rpclisten, so you only need to run one instance somewhere, and then you can point dcrctl at the remote instance from the other machines. In order to do that you need make sure you copy the wallet's RPC certificate to the remote machine(s) and point dcrctl at it (--rpccert) as well as the correct remote address (--rpcserver).
@davecgh Thank you. I generated a few new addresses on the Pi and restarted the dcrd and wallet daemons, and upon initialization the dcrd showed this error message: [ERR] STKE: Accessory ticket database is desynced, resyncing now It took several minutes to resync, but even afterwards, the balances are still different. I will setup the remote rpc connection later. Thanks for the tips!
David - In general, running 3 wallets using the same wallet seed is not a suggested configuration. Per davecgh's comments, it creates a synchronization problem and will end up having addresses reused between the machines due to lack of synchronization. Do you have a similar wallet config working with other coins? I would expect similar problems with such a setup with Bitcoin.
That makes total sense. It wasn't an ideal setup for me.. I think it was merely coincidence that I left the wallet online at work and continued my testing at home, and came back to work the next day and saw the discrepancy. I don't actually plan on having the mainnet wallet online in more than one daemon. I haven't used another coin's wallet in this manner either. How can I know which wallet shows the right balance? If the blockchain keeps a master record of all the transactions to date, once the wallet is completely synced, shouldn't it have the same information? Or does the wallet say, for example, "Hey, this wallet address is one of the ones I've generated, so that transaction must have been linked to me"? Which would further mean, I'd have to generate all the same addresses as the first instance of the wallet did for everything to sync across..
It's the latter. The balance is calculated by looking at all transactions which involve the addresses the wallet currently knows about. When a wallet hasn't generated an address yet, it doesn't know the address belongs to it, so it can't count that transaction towards the balance. Also, because the block chain ends up growing quite large, there is an additional optimization that effectively says "if I generate this address now, I know I don't have to look for transactions before this moment in time, because this address didn't exist until just now." I had actually forgotten about this optimization in my previous answer when i suggested running getnewaddress on the other wallets. The result is that even if you go to a second wallet and issue a getnewaddress, it isn't going to rescan the entire block chain for those new addresses and so it's quite likely you will see a balance discrepancy. On the other hand, when you import from the seed, it is basically a recovery mode where there is an algorithm that specifically keeps searching for batches of your addresses that have associated transactions (up to a certain gap limit) in order to figure out the most recent used address. This is obviously fairly expensive (in terms of computing resources) to do hence why it only applies when importing a seed.
That makes sense. In this particular case, each wallet was generated using the seed as opposed to copying the wallet.db file across the machines.. I have only been stake mining for less than a week, and the wallet on the Pi doens't see one of the tickets I currently hold. Is there a way to get it to recognize that the particular stake ticket belongs to it?
If I understand the issue, according to this post, then the wallet must be regenerated from the seed. The "right" way for you to set this up is to run one wallet and simply use dcrctl on other machines to interact with it, as I believe @davecgh suggested earlier.