sendrawtransaction takes too long about bitcoin

[maflcko]

What is the approximate size of the BDB wallet? What is the SSD read/write usage around the slowdown?

If this is the cause, I think you can try an sqlite descriptor wallet, whose flush is less expensive on the storage read/write usage.

[maflcko]

rpcthreads=1000
rpcworkqueue=4000

Yes, it is possible that all CPUs are busy if many threads are running, and possibly working.

[maflcko]

Bitcoin Core 22.0

Is this still an issue with a recent version of Bitcoin Core? If yes, what are the steps to reproduce?

[toolsopen]

rpcthreads=1000
rpcworkqueue=4000

Yes, it is possible that all CPUs are busy if many threads are running, and possibly working.

rpcthreads=1000
rpcworkqueue=4000

Yes, it is possible that all CPUs are busy if many threads are running, and possibly working.

Observe that the machine performance indicators are not full, but the current memory usage is 20GB.

[toolsopen]

Bitcoin Core 22.0

Is this still an issue with a recent version of Bitcoin Core? If yes, what are the steps to reproduce?

Bitcoin Core 22.0

Is this still an issue with a recent version of Bitcoin Core? If yes, what are the steps to reproduce?

Currently I don’t know how to reproduce it, it only happens from time to time in the prod environment.

[maflcko]

Observe that the machine performance indicators are not full, but the current memory usage is 20GB.

How large is your wallet, roughly?

[toolsopen]

How large is your wallet, roughly?
There are currently about 3,000 utxos available. A large number of transactions have been generated in history, and transaction reception and sending are also very active.

[maflcko]

So another reason for the delay may be that the wallet is currently persisted to storage in the background?

[toolsopen]

background

Is it related to the fact that the historical transaction data of the wallet is too large? The total number of transactions in our wallet is 1,170,364

[toolsopen]

What is the approximate size of the BDB wallet? What is the SSD read/write usage around the slowdown?

If this is the cause, I think you can try an sqlite descriptor wallet, whose flush is less expensive on the storage read/write usage.

9.3G Oct 31 03:55 wallet.dat

[maflcko]

You'll have to look for read/write usage in the unit [size in bytes]/[time] when the slow-down occurs.

[toolsopen]

One thing I need to state is that all transactions in my wallet are sent and received from the same address, and the read-only wallet mode used is only for broadcast transactions and utxo queries.

[toolsopen]

sqlite

I tried to use sqlite, but it was prompted that read-only import addresses are not supported.

[toolsopen]

@maflcko Will wallet.dat 9.3G affect performance? Is there any way to clear the used transactions in it?

[willcl-ark]

Hi @toolsopen

Bitcoin Core v22 is outside of maintenance window now, you should probably consider upgrading (to at least 24.2, or better still 25.1)

A few questions:

1. what do these config values do?

stake=0
staking=0
gen=0

2. How are you creating the sqlite wallet?

I can create a (new) sqlite descriptor wallet and import a wpkh pubkey on v25.1, after compiling with sqlite like this:

will@ubuntu in ~/src/bitcoin on master [$?⇡] : C v16.0.6-clang : 🐍
$ /home/will/src/bitcoin/src/bitcoin-cli -regtest -named createwallet wallet_name="toolsopen" disable_private_keys=true blank=true descriptors=true
{
  "name": "toolsopen"
}

will@ubuntu in ~/src/bitcoin on master [$?⇡] : C v16.0.6-clang : 🐍
$ /home/will/src/bitcoin/src/bitcoin-cli -regtest getdescriptorinfo "wpkh(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9)"
{
  "descriptor": "wpkh(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9)#8zl0zxma",
  "checksum": "8zl0zxma",
  "isrange": false,
  "issolvable": true,
  "hasprivatekeys": false
}

# import descriptor
# NOTE: this will import as inactive so `getnewaddress` on this wallet won't work natively
will@ubuntu in ~/src/bitcoin on master [$?⇡] : C v16.0.6-clang : 🐍 
$ /home/will/src/bitcoin/src/bitcoin-cli -regtest importdescriptors '[{ "desc": "wpkh(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9)#8zl0zxma", "timestamp": 0, "internal": true  }]'
[
  {
    "success": true
  }
]

# derive the address
will@ubuntu in ~/src/bitcoin on master [$?⇡] : C v16.0.6-clang : 🐍 on ☁️  (europe-west1)
$ /home/will/src/bitcoin/src/bitcoin-cli -regtest deriveaddresses "wpkh(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9)#8zl0zxma"
[
  "bcrt1q0ht9tyks4vh7p5p904t340cr9nvahy7uevmqwj"
]

# load wallet with funds to send from

# send coins and check balance
will@ubuntu in ~/src/bitcoin on master [$?⇡] : C v16.0.6-clang : 🐍 on ☁️  (europe-west1)
$ /home/will/src/bitcoin/src/bitcoin-cli -regtest -rpcwallet=descriptor sendtoaddress bcrt1q0ht9tyks4vh7p5p904t340cr9nvahy7uevmqwj 1
dac907862d74fb45afc9dd174794a0132b3a8a59c35e67229d670fb241e4e1e5

will@ubuntu in ~/src/bitcoin on master [$?⇡] : C v16.0.6-clang : 🐍 on ☁️  (europe-west1)
$ /home/will/src/bitcoin/src/bitcoin-cli -regtest -rpcwallet=descriptor -generate 1
{
  "address": "bcrt1qf4ps9gxeperfnszz7c25ls9yupmt45d6x9pvea",
  "blocks": [
    "3a4ae953cac8b899b36293e0f45892bec804588f721e47e5b30529c276fc74b8"
  ]
}

will@ubuntu in ~/src/bitcoin on master [$?⇡] : C v16.0.6-clang : 🐍 on ☁️  (europe-west1)
$ /home/will/src/bitcoin/src/bitcoin-cli -regtest -rpcwallet=toolsopen getbalance
1.00000000

will@ubuntu in ~/src/bitcoin on master [$?⇡] : C v16.0.6-clang : 🐍 on ☁️  (europe-west1)
$ /home/will/src/bitcoin/src/bitcoin-cli -regtest -rpcwallet=toolsopen listunspent
[
  {
    "txid": "dac907862d74fb45afc9dd174794a0132b3a8a59c35e67229d670fb241e4e1e5",
    "vout": 0,
    "address": "bcrt1q0ht9tyks4vh7p5p904t340cr9nvahy7uevmqwj",
    "scriptPubKey": "00147dd65592d0ab2fe0d0257d571abf032cd9db93dc",
    "amount": 1.00000000,
    "confirmations": 1,
    "spendable": true,
    "solvable": true,
    "desc": "wpkh([7dd65592]02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9)#lps3yegk",
    "parent_descs": [
      "wpkh(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9)#8zl0zxma"
    ],
    "safe": true
  }
]

will@ubuntu in ~/src/bitcoin on master [$?⇡] : C v16.0.6-clang : 🐍 on ☁️  (europe-west1)
$ /home/will/src/bitcoin/src/bitcoin-cli -regtest -rpcwallet=descriptor getnewaddress
bcrt1qqwegjptkfuwqddznkqf8q5968xw83y60zvyqyc

will@ubuntu in ~/src/bitcoin on master [$?⇡] : C v16.0.6-clang : 🐍 on ☁️  (europe-west1)
$ /home/will/src/bitcoin/src/bitcoin-cli -regtest -rpcwallet=toolsopen createrawtransaction "[{\"txid\":\"dac907862d74fb45afc9dd174794a0132b3a8a59c35e67229d670fb241e4e1e5\",\"vout\":0}]" "[{\"bcrt1qqwegjptkfuwqddznkqf8q5968xw83y60zvyqyc\":0.01}]"
0200000001e5e1e441b20f679d22675ec3598a3a2b13a0944717ddc9af45fb742d8607c9da0000000000fdffffff0140420f000000000016001403b28905764f1c06b453b0127050ba399c78934f00000000

will@ubuntu in ~/src/bitcoin on master [$?⇡] : C v16.0.6-clang : 🐍 on ☁️  (europe-west1)
$ /home/will/src/bitcoin/src/bitcoin-cli -regtest -rpcwallet=toolsopen decoderawtransaction 0200000001e5e1e441b20f679d22675ec3598a3a2b13a0944717ddc9af45fb742d8607c9da0000000000fdffffff0140420f000000000016001403b28905764f1c06b453b0127050ba399c78934f00000000
{
  "txid": "e39f32d1b266b0c7504cd22b4fec445a7aae7e99a80ef4b87f8339f128169152",
  "hash": "e39f32d1b266b0c7504cd22b4fec445a7aae7e99a80ef4b87f8339f128169152",
  "version": 2,
  "size": 82,
  "vsize": 82,
  "weight": 328,
  "locktime": 0,
  "vin": [
    {
      "txid": "dac907862d74fb45afc9dd174794a0132b3a8a59c35e67229d670fb241e4e1e5",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "sequence": 4294967293
    }
  ],
  "vout": [
    {
      "value": 0.01000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 03b28905764f1c06b453b0127050ba399c78934f",
        "desc": "addr(bcrt1qqwegjptkfuwqddznkqf8q5968xw83y60zvyqyc)#quh7r7my",
        "hex": "001403b28905764f1c06b453b0127050ba399c78934f",
        "address": "bcrt1qqwegjptkfuwqddznkqf8q5968xw83y60zvyqyc",
        "type": "witness_v0_keyhash"
      }
    }
  ]
}

This will rescan the blockchain for historical transactions but you would lose transaction metadata. There does exist a migration tool which should be released in v26.0 which may also handle metadata too, if this is important to you (unsure about this).

@maflcko Will wallet.dat 9.3G affect performance? Is there any way to clear the used transactions in it?

If you import the descriptor as above and use "timestamp": "now" then it won't rescan for historical transactions. Although if any time in the future you happened to rescan your chain, these would be picked back up by the wallet. But AFAIK you can't "clear" them from the wallet.

You could create a new wallet with a new address and use that? Each transaction should use a unique address. Address re-use is terrible for sender and receiver privacy.

[achow101]

Will wallet.dat 9.3G affect performance?

Yes, significantly.

Is there any way to clear the used transactions in it?

Not automatically. However you can use removeprunedfunds and delete old transactions manually.

[toolsopen]

If you import the descriptor as above and use "timestamp": "now" then it won't rescan for historical transactions. Although if any time in the future you happened to rescan your chain, these would be picked back up by the wallet. But AFAIK you can't "clear" them from the wallet.

1.is to turn off some mining settings
2.The following versions and commands were used for testing

https://bitcoincore.org/bin/bitcoin-core-25.1/bitcoin-25.1-x86_64-linux-gnu.tar.gz
curl -X POST 'http://test:[email protected]:8432' -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","method":"createwallet","params":["main",true,true,null,false,true,true],"id":"1"}'
curl -X POST 'http://test:[email protected]:8432' -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","method":"importaddress","params":[ "bc1qmxxxxxxxxxxxxxxxxx", "main", true],"id":"1"}'

One address is easier to maintain

[toolsopen]

Will wallet.dat 9.3G affect performance?

Yes, significantly.

Is there any way to clear the used transactions in it?

Not automatically. However you can use removeprunedfunds and delete old transactions manually.

This helps, let me write a script and try it out

[toolsopen]

#12115

@achow101 @maflcko @willcl-ark @gregwebs I saw that this issue was raised in 2018, but no attention was paid to it

[maflcko]

Again, it is hard or impossible to fix your problem if it is wasn't properly diagnosed. The delay could be entirely unrelated to the wallet.

However, if the delay is caused by storage speed limitations in combination with the BDB flush behavior, a solution could be to migrate your wallet to sqlite. The (experimental) migratewallet RPC is only available in 25.x or the upcoming 26.x.

[toolsopen]

@maflcko @achow101 @willcl-ark @gregwebs After the read-only wallet was reset and utxo was selectively imported, the performance was greatly improved and the problem was solved.

[toolsopen]

This proves that it would be a very good way if bitcoind can self-isolate expired transactions.

[willcl-ark]

Thanks for the update. Wallet performance is something that's being continually worked on.

Did you end up upgrading versions (too), or still running on V22?

[maflcko]

Assuming this is a bdb wallet (can be checked via getwalletinfo()[format]), I don't think it is worth to spend time on optimizing the code, given that it will be removed in the future.

[toolsopen]

Thanks for the update. Wallet performance is something that's being continually worked on.

Did you end up upgrading versions (too), or still running on V22?

I also updated the final version to 25.1. It must have nothing to do with the version update at that time. I tried the complete rescan wallet to compare it.

[toolsopen]

Assuming this is a bdb wallet (can be checked via getwalletinfo()[format]), I don't think it is worth to spend time on optimizing the code, given that it will be removed in the future.

I use it for utxo maintenance and transaction broadcasting, but an overly large wallet will definitely have a great impact on performance.

[maflcko]

What does the getwalletinfo RPC return in the format field, for you?