Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing the asset balance after the transactions is trusted false #884

Open
rahuldotar opened this issue Jun 14, 2020 · 3 comments
Open

Comments

@rahuldotar
Copy link

rahuldotar commented Jun 14, 2020

{
    "address": "xxxxxxxx",
    "category": "send",
    "amount": -100000.00000000,
    "amountblinder": "0000000000000000000000000000000000000000000000000000000000000000",
    "asset": "xxxxxxxx",
    "assetblinder": "0000000000000000000000000000000000000000000000000000000000000000",
    "vout": 0,
    "fee": 0.00026420,
    "confirmations": 0,
    "trusted": "false",
    "txid": "xxxxxx",
    "walletconflicts": [
      
    ],
    "time": xxxx,
    "timereceived": xxxx,
    "bip125-replaceable": "no",
    "abandoned": "false"
  }

After this transaction, the asset balance is not showing as expected. When I check the transaction history using listtransaction function and manually calculate the balance it is not matching with the getbalance function.

@stevenroose
Copy link
Member

I don't really understand what situation you're in. Could you give a bit more information?

@rahuldotar
Copy link
Author

I created the Elements blockchain network and implemented the Block signing federation using Kafka. Then I issued an asset and did the multiple transactions. After 2 multiple consecutive transactions with the same amount from the same wallet and one of that transaction failed. And I noticed that in the transaction details the param trusted is return as false and I lost the remaining balance in that wallet.

@stevenroose
Copy link
Member

This is how the "trusted" field works:

bool CWalletTx::IsTrusted(interfaces::Chain::Lock& locked_chain) const
{
    LockAnnotation lock(::cs_main); // Temporary, for CheckFinalTx below. Removed in upcoming commit.

    // Quick answer in most cases
    if (!CheckFinalTx(*tx))
        return false;
    int nDepth = GetDepthInMainChain(locked_chain);
    if (nDepth >= 1)
        return true;
    if (nDepth < 0)
        return false;
    if (!pwallet->m_spend_zero_conf_change || !IsFromMe(ISMINE_ALL)) // using wtx's cached debit
        return false;

    // Don't trust unconfirmed transactions from us unless they are in the mempool.
    if (!InMempool())
        return false;

    // Trusted if all inputs are from us and are in the mempool:
    for (const CTxIn& txin : tx->vin)
    {
        // Transactions not sent by us: not trusted
        const CWalletTx* parent = pwallet->GetWalletTx(txin.prevout.hash);
        if (parent == nullptr)
            return false;
        const CTxOut& parentOut = parent->tx->vout[txin.prevout.n];
        if (pwallet->IsMine(parentOut) != ISMINE_SPENDABLE)
            return false;
    }
    return true;
}

So it can be that the tx is dropped from the mempool for some reason. Did you accidentally double-spend the same coins?

gwillen pushed a commit that referenced this issue Mar 3, 2021
…erministic

f899580 tests: Make coins_tests/updatecoins_simulation_test deterministic (practicalswift)

Pull request description:

  Make `coins_tests/updatecoins_simulation_test` deterministic.

  Before:

  ```
  $ contrib/devtools/test_deterministic_coverage.sh 1000
  [2019-06-15 05:36:20] Measuring coverage, run #1 of 1000
  [2019-06-15 05:38:05] Measuring coverage, run #2 of 1000
  [2019-06-15 05:39:49] Measuring coverage, run #3 of 1000
  [2019-06-15 05:41:38] Measuring coverage, run #4 of 1000
  [2019-06-15 05:43:16] Measuring coverage, run #5 of 1000
  ...
  [2019-06-16 18:25:23] Measuring coverage, run #880 of 1000
  [2019-06-16 18:27:12] Measuring coverage, run #881 of 1000
  [2019-06-16 18:29:33] Measuring coverage, run #882 of 1000
  [2019-06-16 18:33:00] Measuring coverage, run #883 of 1000
  [2019-06-16 18:35:32] Measuring coverage, run #884 of 1000

  The line coverage is non-deterministic between runs. Exiting.

  The test suite must be deterministic in the sense that the set of lines executed at least
  once must be identical between runs. This is a necessary condition for meaningful
  coverage measuring.

  --- gcovr.run-1.txt     2019-06-15 05:38:05.282359029 +0200
  +++ gcovr.run-884.txt   2019-06-16 18:37:23.518298374 +0200
  @@ -269,7 +269,7 @@
   test/bloom_tests.cpp                         320     320   100%
   test/bswap_tests.cpp                          13      13   100%
   test/checkqueue_tests.cpp                    223     222    99%   169
  -test/coins_tests.cpp                         478     472    98%   52,68,344-345,511,524
  +test/coins_tests.cpp                         478     474    99%   52,68,511,524
   test/compilerbug_tests.cpp                    18      18   100%
   test/compress_tests.cpp                       27      27   100%
   test/crypto_tests.cpp                        268     268   100%
  @@ -401,5 +401,5 @@
   zmq/zmqpublishnotifier.h                       5       0     0%   12,31,37,43,49
   zmq/zmqrpc.cpp                                23       3    13%   16,18,20,23,33-35,37,40-47,51,62,64-65
   ------------------------------------------------------------------------------
  -TOTAL                                      53323   28305    53%
  +TOTAL                                      53323   28307    53%
   ------------------------------------------------------------------------------
  ```

  After:

  ```
  $ contrib/devtools/test_deterministic_coverage.sh 1000
  [2019-06-15 05:36:20] Measuring coverage, run #1 of 1000
  [2019-06-15 05:38:05] Measuring coverage, run #2 of 1000
  [2019-06-15 05:39:49] Measuring coverage, run #3 of 1000
  [2019-06-15 05:41:38] Measuring coverage, run #4 of 1000
  [2019-06-15 05:43:16] Measuring coverage, run #5 of 1000
  ...
  $
  ```

ACKs for commit f89958:
  MarcoFalke:
    ACK f899580 (checked that the randomness state of g_insecure_rand_ctx is the same after three test runs)

Tree-SHA512: 796d362b050c5750e351de1126b62f0f2c8e2d712cf01b6e1a3e2cc6ef92fa68439a32fc24c76d34bce4d553aee4ae4ea88a036c56eb9e25979649a19c59c3e5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants