⚠️ re2005 opened an issue: "Unable to send funds"
(https://github.com/bitcoin/bitcoin/issues/28001)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Using Bitcoin Core `v25.0.0` have it sync (pruned)

My wallet shows valid balance but I'm not able to send funds

### Expected behaviour

Be able to send funds when the wallet display you have balance



### Steps to reproduce

- Try to send funds to a valid rec
...

💬 vasild commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1246596157)
Alright, so I got it the other way around. So the point is to avoid recompiling all tests if e.g. `ALL_NETWORKS` is changed (defined in `test/util/net.h`). That lowers the re-compilation from 28-29 sec to about 10 sec (if `src/test/util/net.h` is modified).

I will leave it as it is because moving the code around would further increase the size of this PR which suffers from lack of interest from reviewers and I think expanding it may further turn people away.

💬 vasild commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1246596519)
Done.

💬 vasild commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1246596786)
Done.

💬 vasild commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1246602200)
Done.

I changed it to use `{}` as suggested but I don't see a point to use `{}` instead of `=` for initialization when `auto` is used. I find the `{}` variant a little bit less readable but see the merit to use it when `Type1 x{expresson_of_Type2};` is used to detect incompatibilities between `Type1` and `Type2`. But why do that for `auto x{expressoin_of_any_type};`?

💬 vasild commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1246602826)
Done, except this:

```
test/net_msg_tests.cpp should add these lines:
#include <boost/preprocessor/arithmetic/limits/dec_256.hpp>
#include <boost/preprocessor/comparison/limits/not_equal_256.hpp>
#include <boost/preprocessor/control/expr_iif.hpp>
#include <boost/preprocessor/control/iif.hpp>
#include <boost/preprocessor/detail/limits/auto_rec_256.hpp>
#include <boost/preprocessor/logical/compl.hpp>
#include <boost/preprocessor/logical/limits/bool_256.hpp>
#include <boost/preprocessor
...

💬 furszy commented on issue "Unable to send funds":
(https://github.com/bitcoin/bitcoin/issues/28001#issuecomment-1613178955)
Based on the logs, the input is spent on the mempool.

To confirm it, try the following:
1) Call `listunspent` and save the output `txid` and `vout` (the one whose id starts with `af4dd794df`).
2) Call `gettxspendingprevout '[{txid: your_tx_id, vout: your_vout}]'`

And let me know what `gettxspendingprevout` returns. If it returns a non-empty array, we will need to see why your wallet didn't mark the output as spent.

💬 re2005 commented on issue "Unable to send funds":
(https://github.com/bitcoin/bitcoin/issues/28001#issuecomment-1613190080)
Hi @furszy thank you so much for the reply.

```
listunspent
[
{
"txid": "af4dd794df45774317fb681fb2545399e34069b4c4ff48e8cde2acae7d92217f",
"vout": 1,
"address": "363VZYA4LxQ7AogtwQ4ZTuZZMfbcQAVkVq",
"redeemScript": "001451f9e2f74be844c1d192af5fa392d2fa707ace0c",
"scriptPubKey": "a9142fbfe4ad67ad78e28eed6d0549f22ca163202d7e87",
"amount": 0.01502419,
"confirmations": 186937,
"spendable": true,
"solvable": true,
"desc": "sh(wpkh([f8ff6f62/0
...

💬 furszy commented on issue "Unable to send funds":
(https://github.com/bitcoin/bitcoin/issues/28001#issuecomment-1613206134)
Ok thanks. Would be helpful if you can provide the complete logs.

And to solve the issue, just need to restart the node. Your wallet should detect the mempool transaction and mark the output as spent automatically.

💬 re2005 commented on issue "Unable to send funds":
(https://github.com/bitcoin/bitcoin/issues/28001#issuecomment-1613209444)
Here you go.
[debug.log](https://github.com/bitcoin/bitcoin/files/11906321/debug.log)

I've restarted `BitcoinCore` but still showing the `Available` funds,

📝 fanquake opened a pull request: "refactor: remove in-code warning suppression"
(https://github.com/bitcoin/bitcoin/pull/28002)
Should no-longer be needed post #27872. If it is, then suppress-external-warnings should be fixed.

💬 furszy commented on issue "Unable to send funds":
(https://github.com/bitcoin/bitcoin/issues/28001#issuecomment-1613229116)
Ok. Your transaction was actually confirmed 14 blocks ago ([explorer](https://blockstream.info/tx/697ea53a4fbecbb048c36bbd0fd6ed5a662af79f19e5eee5f10c573fcd829174)).

Try rescanning the blockchain:
`rescanblockchain 796400`

💬 MarcoFalke commented on pull request "fuzz: call `LookupSubNet` before calling `Ban` with a subnet":
(https://github.com/bitcoin/bitcoin/pull/27935#issuecomment-1613261020)
Could rebase on master to remove `export FUZZ_TESTS_CONFIG="--exclude banman" # https://github.com/bitcoin/bitcoin/issues/27924`?

💬 instagibbs commented on pull request "validate package transactions with their in-package ancestor sets":
(https://github.com/bitcoin/bitcoin/pull/26711#issuecomment-1613277774)
> One goal of that is to prevent any potential regression from legacy orphan handling

Sorry can you motivate the issue here explicitly? How would this issue not arise in cluster mempool world?

> favoring smaller chunks over larger ones.

I think it'd be good to be explicit what "favoring" means here. Is this just individual submissions, then the full chunk on the rest of the chunk on an individual failure?

> Refine our linearization using the fee information.

Any thoughts on what a
...

💬 sipa commented on pull request "Add support for RFC8439 variant of ChaCha20":
(https://github.com/bitcoin/bitcoin/pull/27985#discussion_r1246699001)
Rephrased; indeed, the `2^38 - 64` number only applies to the AEAD and not to ChaCha20 (which supports 2^28).

💬 sipa commented on pull request "Add support for RFC8439 variant of ChaCha20":
(https://github.com/bitcoin/bitcoin/pull/27985#discussion_r1246699465)
I've added a comment about it being repeated.

💬 sipa commented on pull request "Add support for RFC8439 variant of ChaCha20":
(https://github.com/bitcoin/bitcoin/pull/27985#issuecomment-1613287345)
Made some changes:
* Addressed the comments above.
* Renamed `nonce_low` and `nonce_high` to `nonce_prefix` and `nonce` respectively; there isn't any inherent ordering of low/high between them, but RFC8439 refers to the first one as "32-bit fixed-common part" in one place.
* Removed the old RFC8439 test vectors (as they were essentially created by translating test vectors for 96/32 nonces to the equivalent 64/64 one). The new RFC8439 test vectors actually match the document.

💬 craigraw commented on pull request "Add feerate histogram to getmempoolinfo":
(https://github.com/bitcoin/bitcoin/pull/21422#issuecomment-1613293519)
The points regarding CPFP etc are well noted, although it's possible these are in practice more applicable to higher time preference fee estimations? Estimation aside, there are not insignificant client costs to maintaining a "txid to vsize and fee rate" mempool replica. By my measurement, this data structure with ~125,000 transactions requires ~14Mb of RAM.

Further, the initial load using `getmempoolentry` takes around 20 seconds on a locally running node, and would certainly be slower if th
...

💬 achow101 commented on issue "failure in wallet_basic.py --descriptors":
(https://github.com/bitcoin/bitcoin/issues/27249#issuecomment-1613300675)
From those logs, it seems like the second transaction is taking a while to get into the mempool, long after the wallet submitted it. I believe it's only being accepting after we've the listunspent call, which then causes the assertion to fail.

I'm wondering why it's taking so long to get into the mempool - in a lot of tests, we assume that `send*` commands are basically instantaneous, otherwise I'd expect to see similar failures in a lot of other places.

💬 jamesob commented on pull request "script: utxo_snapshot.sh error handling":
(https://github.com/bitcoin/bitcoin/pull/27845#issuecomment-1613314386)
ACK https://github.com/bitcoin/bitcoin/pull/27845/commits/39aa958b2049bc50819d645052c0b90cf19f306e

But I think you can just squash these two commits down into one.