⚠️ JaviVald10 opened an issue: "Error: This wallet has no available keys (code -4)"
(https://github.com/bitcoin/bitcoin/issues/28117)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

I am new and I just installed Bitcoin core, so I'm learning. However, I cannot get a new receiving address and I don't know why!!
I also tried to use the command
/getnewaddress but then it pops up an error saying "this wallet has no available keys (code -4)". I also tried the
...

💬 MarcoFalke commented on pull request "Fuzz: a more efficient descriptor parsing target":
(https://github.com/bitcoin/bitcoin/pull/27888#issuecomment-1645380531)
For testing I've injected a bug in currently uncovered code:


```diff
diff --git a/src/script/descriptor.cpp b/src/script/descriptor.cpp
index 09ded5fc61..b69db182ab 100644
--- a/src/script/descriptor.cpp
+++ b/src/script/descriptor.cpp
@@ -509,7 +509,7 @@ public:
out = "[" + origin_str + "]" + EncodeExtPubKey(xpub) + FormatHDKeypath(end_path);
if (IsRange()) {
out += "/*";
- assert(m_derive == DeriveType::UNHARDENED);
+ assert(m
...

💬 pinheadmz commented on issue "Error: This wallet has no available keys (code -4)":
(https://github.com/bitcoin/bitcoin/issues/28117#issuecomment-1645434395)
How did you create the wallet? There is an option to disable private keys. Don't use it!


<img width="426" alt="Screen Shot 2023-07-21 at 7 25 43 AM" src="https://github.com/bitcoin/bitcoin/assets/2084648/4494846d-168e-4cb7-84b3-275aa822b505">

💬 JaviVald10 commented on issue "Error: This wallet has no available keys (code -4)":
(https://github.com/bitcoin/bitcoin/issues/28117#issuecomment-1645440006)
I do not remember, I'm gonna try to create another one

💬 JaviVald10 commented on issue "Error: This wallet has no available keys (code -4)":
(https://github.com/bitcoin/bitcoin/issues/28117#issuecomment-1645442739)
OMG NOW I CAN THANK YOU SO MUCH

✅ JaviVald10 closed an issue: "Error: This wallet has no available keys (code -4)"
(https://github.com/bitcoin/bitcoin/issues/28117)

💬 pinheadmz commented on issue "Error: This wallet has no available keys (code -4)":
(https://github.com/bitcoin/bitcoin/issues/28117#issuecomment-1645443624)
🎯

💬 MarcoFalke commented on pull request "util: Replace std::filesystem with util/fs.h":
(https://github.com/bitcoin/bitcoin/pull/28076#issuecomment-1645453965)
rebased

💬 vasild commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1270627453)
If `ProcessMessagesOnce()` is called directly, then it will not be an end-to-end test. It will defeat the purpose of this PR.

Sending ping and waiting for pong (`sync_with_ping`) might be an alternative. It is not as flexible and fine-grained though as waiting for a particular log message to be logged and it involves a timeout too (which could expire too soon on slow platforms). What would be the advantage of a `sync_with_ping` approach? I have to think about this.

💬 darosior commented on pull request "Fuzz: a more efficient descriptor parsing target":
(https://github.com/bitcoin/bitcoin/pull/27888#issuecomment-1645525854)
Thanks for testing. Fixed the issue. I also introduced the bug you shared and it does make the target crash.

💬 ChrisCho-H commented on pull request "script: add description for the functionality of each opcode":
(https://github.com/bitcoin/bitcoin/pull/27109#issuecomment-1645528886)
Thx! I updated

💬 MarcoFalke commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1270656464)
> If ProcessMessagesOnce() is called directly, then it will not be an end-to-end test. It will defeat the purpose of this PR.

Makes sense. I guess I misunderstood the goal of this pull. So the goal is to mimic the functional tests that already do the same checks, but do it without spinning up a real socket, but use a mocked socket?

📝 MarcoFalke opened a pull request: "test: Add SyncWithValidationInterfaceQueue to mockscheduler RPC"
(https://github.com/bitcoin/bitcoin/pull/28118)
There should be no risk in adding a call to `SyncWithValidationInterfaceQueue` here. In fact, it will make tests less brittle. For example,

* If one sets the timeouts in `test/functional/feature_fee_estimation.py` to `0`, on `master` the test will fail and here it will pass.
* It may avoid a rare (theoretic) intermittent issue in https://github.com/bitcoin/bitcoin/pull/28108/files#r1268966663

💬 MarcoFalke commented on pull request "test: fix intermittent failure in wallet_resendwallettransactions.py":
(https://github.com/bitcoin/bitcoin/pull/28108#discussion_r1270660411)
Attempt in https://github.com/bitcoin/bitcoin/pull/28118

💬 jonatack commented on pull request "ci: Start with clean env":
(https://github.com/bitcoin/bitcoin/pull/27976#issuecomment-1645571335)
Approach ACK

💬 instagibbs commented on pull request "Package Relay 1/3: Introduce TxPackageTracker as Orphan Resolution Module":
(https://github.com/bitcoin/bitcoin/pull/28031#discussion_r1270671380)
This logging should be handled by the caller, since the caller sometimes isn't actually requesting the items!

💬 jamesob commented on pull request "BIP324 ciphersuite":
(https://github.com/bitcoin/bitcoin/pull/28008#discussion_r1268163179)
26a7c254dcb49a92070c88cc7963e4996cd9e7c7

(Non-blocking note:) a little unexpected that this is written out of sequence with how it's described in [RFC 8439](https://datatracker.ietf.org/doc/html/rfc8439#section-2.8);

> - First, a Poly1305 one-time key is generated from the 256-bit key and nonce using the procedure described in [Section 2.6](https://datatracker.ietf.org/doc/html/rfc8439#section-2.6).
> - Next, the ChaCha20 encryption function is called to encrypt the plaintext, using the
...

🤔 jamesob reviewed a pull request: "BIP324 ciphersuite"
(https://github.com/bitcoin/bitcoin/pull/28008#pullrequestreview-1537240624)
Submitting partial review (now to some degree obviated) up to the `FSChaCha20` implementation.

Looking good so far. I also did cross-validation of the test vectors with [a Python library](https://github.com/ph4r05/py-chacha20poly1305) (happily a different implementation than The Stack Man) - the script for that can be found [here](https://github.com/jamesob/bitcoin-review-data/blob/master/28008.sipa.bip324_ciphersuite/verifycrypto.py), where I've manually copied test data from @sipa's cpp and
...

💬 jamesob commented on pull request "BIP324 ciphersuite":
(https://github.com/bitcoin/bitcoin/pull/28008#discussion_r1268291488)
Note that this ciphertext includes the Poly1305 tag; in the RFC, ciphertext vector omits the tag.

💬 jamesob commented on pull request "BIP324 ciphersuite":
(https://github.com/bitcoin/bitcoin/pull/28008#discussion_r1268282951)
Note for reviewers that RFC test vectors use network byte order (big-endian); the `Nonce96` constructor here expects little-endian representation. Hence the reversal relative to RFC vectors.