💬 stickies-v commented on pull request "net: Allow inbound whitebind connections to more aggressively evict peers when slots are full":
(https://github.com/bitcoin/bitcoin/pull/27600#discussion_r1197037590)
Imo, "find" makes it sound like this has no side effects, whereas I think this actually does disconnect the node.

💬 stickies-v commented on pull request "net: Allow inbound whitebind connections to more aggressively evict peers when slots are full":
(https://github.com/bitcoin/bitcoin/pull/27600#discussion_r1197041677)
suggested rephrasing (although I'm not sure about the "NoBan" qualifier, maybe we have a better established term?)
```suggestion
* @param[in] force If all connections are otherwise protected, still evict a random inbound NoBan node if it exists
```

💬 stickies-v commented on pull request "net: Allow inbound whitebind connections to more aggressively evict peers when slots are full":
(https://github.com/bitcoin/bitcoin/pull/27600#discussion_r1196896354)
Oh, good point @LarryRuane. I didn't realize `NodeId` was just a typedef for `int64_t`. I think that entirely resolves it indeed.

💬 stickies-v commented on pull request "net: Allow inbound whitebind connections to more aggressively evict peers when slots are full":
(https://github.com/bitcoin/bitcoin/pull/27600#discussion_r1196853062)
To add: I think this can be reached when e.g. all of `vEvictionCandidates` gets protected by the `ProtectNoBanConnections(vEvictionCandidates);` call?

💬 mzumsande commented on pull request "net: Allow inbound whitebind connections to more aggressively evict peers when slots are full":
(https://github.com/bitcoin/bitcoin/pull/27600#discussion_r1197060760)
Maybe just copy over the doc from net.cpp? That's basically what I did in a WIP [branch](https://github.com/mzumsande/bitcoin/commit/1aaa795e3f43caf8aa06331e61b14b777a04a6d9).

💬 theuni commented on pull request "macOS: Bump minimum required runtime version and prepare for building with upstream LLVM":
(https://github.com/bitcoin/bitcoin/pull/27676#issuecomment-1552154137)
Converting to draft while I investigate the clang issue.

📝 theuni converted_to_draft a pull request: "macOS: Bump minimum required runtime version and prepare for building with upstream LLVM"
(https://github.com/bitcoin/bitcoin/pull/27676)
This (I believe) resolves the last of the blockers for [switching us away from cctools and instead using out-of-the-box llvm and lld](https://github.com/bitcoin/bitcoin/pull/21778) for building Darwin binaries.

For now, we continue building with a pre-packaged llvm and cctools, but after this PR the clang+lld combo should just work for anyone trying it. Additionally after this PR, the new runtime `fixup_chains` behavior will be in-use, as ld64 uses it as well.

The commits may seem unrelate
...

💬 achow101 commented on issue "test: use-of-uninitialized-value in sqlite3Strlen30":
(https://github.com/bitcoin/bitcoin/issues/27222#issuecomment-1552238004)
This looks to be an issue with either sqlite or clang, I don't think there's anything that we can do to resolve these other than suppressing them.

MSan is tripping on sqlite calling `strlen` on a string that it copied into a temp buffer. That temp buffer was malloc'd by sqlite (without clearing out the data, so it has uninitialized memory), and then our string copied into it, maybe modified (this particular function normalizes a path), a null terminator added, and the result strlen'd. That la
...

🤔 theStack reviewed a pull request: "assumeutxo (2)"
(https://github.com/bitcoin/bitcoin/pull/27596#pullrequestreview-1431794725)
Did the following more or less random test scenario (build at commit b8fd765a06998a79ef6efef5355c956a4679df6f) over the last days:
- start up `bitcoind -prune=800 -blockfilterindex=1` (-dbcache intentionally left at default)
- load snapshot from height 788000 via `bitcoind loadtxoutset /path/to/utxo-788000.dat` (thanks for providing the file!)
- wait until snapshot chainstate reaches network tip
- shut down the node and wait 1-2 days (with the idea to again provoke both chainstates being in
...

💬 theStack commented on pull request "assumeutxo (2)":
(https://github.com/bitcoin/bitcoin/pull/27596#discussion_r1197159021)
Right now if a non-existing file path is passed, a rather cryptic error message appears:
```
$ ./src/bitcoin-cli loadtxoutset jslkdf
error code: -1
error message:
CAutoFile::operator>>: file handle is nullptr: unspecified iostream_category error
```

Should ensure that `afile` is not null and throw an explicit error if it is (like `dumptxoutset` already does), e.g.:
```suggestion
CAutoFile afile{file, SER_DISK, CLIENT_VERSION};
if (afile.IsNull()) {
throw JSONRPCErro
...

💬 DanM3rcurius commented on issue "Can't compile v24.0.1":
(https://github.com/bitcoin/bitcoin/issues/27680#issuecomment-1552379839)
It's building now! I used default parameters and left the GUI ins this time, so its taking quite a while ^^

The documentation in the github was absolutely fine. I added the BDB as I might need to access legacy wallets, for RasPi OS I had to add the `--build=aarch64-unknown-linux-gnu ` to the `./configure` command before building the DB.

For a noob like me it's important to know that the ./autogen.sh script and configure command are run after all dependencies have been installed. When I fir
...

💬 ajtowns commented on pull request "p2p: Stop relaying non-mempool txs":
(https://github.com/bitcoin/bitcoin/pull/27625#issuecomment-1552435967)
Concept ACK

The original use of `mapRelay` was that if a tx wasn't in `mapRelay` it wouldn't be relayed at all. That resulted in problems with child transactions -- if we relay a recent child to a peer that doesn't have the parent, the parent may have expired from `mapRelay` and thus the peer wouldn't be able to accept the child at all.

We fixed that with #16851 so that we'd relay txs from the mempool if they'd been in the mempool long enough to expire from `mapRelay` (ie, 15 minutes). Tha
...

💬 MarcoFalke commented on issue "test: use-of-uninitialized-value in sqlite3Strlen30":
(https://github.com/bitcoin/bitcoin/issues/27222#issuecomment-1552453177)
Ok, thanks for taking a look. If there is a reduced test case, it could make sense to report something upstream.

⚠️ faca5 opened an issue: "dumpprivkey - This type of wallet does not support this command (code -4)"
(https://github.com/bitcoin/bitcoin/issues/27693)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Hello.

When I try export private key for bitcoin address i got:
This type of wallet does not support this command (code -4)

I tried on all 4 types of bitcoin address base58 and bech32 (legacy, segwit...).

I'm using ZIP version of Bitcoin Core v23.1.0 downloaded from:
https://bitcoincore.org/bin/bitcoin-core-23.1/bitcoin-23.1-win64.zip

### Expected behaviour

It should display p
...

💬 willcl-ark commented on issue "dumpprivkey - This type of wallet does not support this command (code -4)":
(https://github.com/bitcoin/bitcoin/issues/27693#issuecomment-1552647611)
Are you using a descriptor wallet? If so see conversation here: https://github.com/bitcoin/bitcoin/issues/26046

💬 MarcoFalke commented on pull request "p2p: Stop relaying non-mempool txs":
(https://github.com/bitcoin/bitcoin/pull/27625#issuecomment-1552665725)
> I think it would also be good to continue serving txs from `vExtraTxnForCompact`

I wasn't sure how to do this, given the planned removal of `m_recently_announced_invs` in https://github.com/bitcoin/bitcoin/pull/27675 . Otherwise we may relay invalid/non-standard transactions that were injected into us by a spy node.

Maybe a flag on each transaction in `vExtraTxnForCompact` could be set to indicate if it ever was in the mempool. Though that would still leave the fingerprint vector if the
...

💬 faca5 commented on issue "dumpprivkey - This type of wallet does not support this command (code -4)":
(https://github.com/bitcoin/bitcoin/issues/27693#issuecomment-1552682174)
Looks like.

I just downloaded latest version for Windows, created Bitcoin address and like to export private keys.

None of bitcoin address types any more works to export private keys:
Base58 (Legacy)
Base58 (P2SH-SegWit)
Bech32 (SegWit)
Back32m (Taproot)

When you are owner of bitcoin address you expect to get PRIVATE and PUBLIC keys.

In latest version of Bitcoin core I haven't found any settings to set bitcoin address as descriptor or normal one.

Any idea how to create bitcoin
...

💬 faca5 commented on issue "dumpprivkey - This type of wallet does not support this command (code -4)":
(https://github.com/bitcoin/bitcoin/issues/27693#issuecomment-1552693835)
On Bitcoin Core version v0.14.2 works without problem.

💬 dergoegge commented on pull request "fuzz: net, add `recv_flood_size`, `prefer_evict` in `ConsumeNode`":
(https://github.com/bitcoin/bitcoin/pull/27678#issuecomment-1552706486)
I think this would be a good thing to do if our current targets would be fuzzing the logic that these params are influencing (afaict this is not the case right now) but without that it unfortunately just invalidates our input corpora.

* `prefer_evict` is only used in `CConnman::AttemptToEvictConnection` which is currently not being fuzzed.
* `recv_flood_size` is used to set the value of `CNode::fPauseRecv` which is used to determine if we should stop reading from the socket in `CConnman::Gen
...

💬 GregTonoski commented on issue "dumpprivkey - This type of wallet does not support this command (code -4)":
(https://github.com/bitcoin/bitcoin/issues/27693#issuecomment-1552706536)
> I have already found issue #26046 but there is not any solution on how to export private keys for my own bitcoin address.

Does the RPC `listdescriptors true ` instead of `dumpprivkey` gives you the information, perhaps?