Feedback Public Testnet Evaluation

Discussion in 'Technical Development' started by tacotime, Jan 6, 2016.

  1. 2017/12/15 - Decred v1.1.2 released! → Release Notes  → Downloads
  1. Emilio Mann

    Emilio Mann Full Member
    Advocate (Facebook)

    Jan 9, 2016
    188
    162
    Male
    Thanks!
     
  2. jcv

    jcv Full Member
    Developer

    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.
     
  3. Dyrk

    Dyrk Sr. Member
    Developer

    Jan 7, 2016
    518
    376
    Male
    Wonderland
    How can I get hashes of all confirmed blocks using dcrctl?
     
  4. jcv

    jcv Full Member
    Developer

    @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
     
    Dyrk likes this.
  5. davecgh

    davecgh Hero Member
    Developer Organizer

    Dec 31, 2015
    642
    788
    Male
    United States
    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
    
     
  6. vuiltje

    vuiltje New Member

    Jan 28, 2016
    4
    0
    Male
    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?
     
  7. jy-p

    jy-p Sr. Member
    Organizer

    Jan 2, 2016
    133
    340
    Male
    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.
     
  8. vuiltje

    vuiltje New Member

    Jan 28, 2016
    4
    0
    Male
    It is, it's in the "Spoiler: tx" button.
    I copied it from there:
    "txid": "8502f4a2edd23ea55bb9e59948714001266d43828f73afc31993f6988d672db4",
     
  9. David

    David Sr. Member

    Jan 22, 2016
    364
    207
    Male
    USA
    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?
     
  10. jcv

    jcv Full Member
    Developer

    @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.
     
    chappjc and David like this.
  11. David

    David Sr. Member

    Jan 22, 2016
    364
    207
    Male
    USA
    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.
     
  12. davecgh

    davecgh Hero Member
    Developer Organizer

    Dec 31, 2015
    642
    788
    Male
    United States
    @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 likes this.
  13. davecgh

    davecgh Hero Member
    Developer Organizer

    Dec 31, 2015
    642
    788
    Male
    United States
    @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).
     
    chappjc and David like this.
  14. David

    David Sr. Member

    Jan 22, 2016
    364
    207
    Male
    USA
    @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!
     
  15. jy-p

    jy-p Sr. Member
    Organizer

    Jan 2, 2016
    133
    340
    Male
    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.
     
    chappjc, David and tacotime like this.
  16. David

    David Sr. Member

    Jan 22, 2016
    364
    207
    Male
    USA
    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..
     
    chappjc likes this.
  17. davecgh

    davecgh Hero Member
    Developer Organizer

    Dec 31, 2015
    642
    788
    Male
    United States
    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.
     
    chappjc, David and jy-p like this.
  18. David

    David Sr. Member

    Jan 22, 2016
    364
    207
    Male
    USA
    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?
     
  19. chappjc

    chappjc Full Member
    Developer Pool Operator (PoS)

    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.
     
    David likes this.

Share This Page