💬 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.

💬 MarcoFalke commented on pull request "Add feerate histogram to getmempoolinfo":
(https://github.com/bitcoin/bitcoin/pull/21422#issuecomment-1613343824)
> By my measurement, this data structure with ~125,000 transactions requires ~14Mb of RAM.

If memory usage is the only concern, I am sure you could toss the transactions into (lossy) buckets and then subscribe via zmq to avoid duplicates, without having to remember txids, or individual size/fee details.

> ... applicable to higher time preference fee estimations?

If you only care about the top N blocks worth of transactions, the memory usage likely could also be reduced.

💬 MarcoFalke commented on issue "failure in wallet_basic.py --descriptors":
(https://github.com/bitcoin/bitcoin/issues/27249#issuecomment-1613349621)
I think adding it to the mempool should always be instantaneous. However, the background thread will still handle the AddedToMempool event, which may fire in the wallet when the transaction has already been removed from the mempool, and thus cause a wrong transaction state.

Not sure if this is what happened here, though.

🤔 sipa reviewed a pull request: "test: add python implementation of Elligator swift"
(https://github.com/bitcoin/bitcoin/pull/24005#pullrequestreview-1505500030)
Code review ACK afd762afa39569d8932dd0cf62f8d134e25fc651

💬 sipa commented on pull request "test: add python implementation of Elligator swift":
(https://github.com/bitcoin/bitcoin/pull/24005#discussion_r1246749262)
Perhaps it makes sense to assert here that X is actually on the curve.

`assert GE.is_valid_x(x)`

💬 sipa commented on pull request "test: add python implementation of Elligator swift":
(https://github.com/bitcoin/bitcoin/pull/24005#discussion_r1246752385)
Would it make sense to include the BIP324 test vectors here? (https://github.com/bitcoin/bips/blob/master/bip-0324/ellswift_decode_test_vectors.csv and https://github.com/bitcoin/bips/blob/master/bip-0324/xswiftec_inv_test_vectors.csv). See `test_schnorr_testvectors` in test/functional/test_framework/key.py for an example that involves CSV files.

💬 Empact commented on pull request "Enable -Wstring-concatenation and -Wstring-conversion on clang builds":
(https://github.com/bitcoin/bitcoin/pull/26288#discussion_r1246795871)
Done

💬 Empact commented on pull request "Enable -Wstring-concatenation and -Wstring-conversion on clang builds":
(https://github.com/bitcoin/bitcoin/pull/26288#discussion_r1246796464)
Done