💬 glozow commented on pull request "[NO MERGE] BIP331 Ancestor Package Relay":
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1253243468)
I've squashed the commits so that it's more clear that this was copied to TxPackageTracker (other PR)

💬 glozow commented on pull request "[NO MERGE] BIP331 Ancestor Package Relay":
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1253253635)
Done (in other PR)

💬 glozow commented on pull request "[NO MERGE] BIP331 Ancestor Package Relay":
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1253252501)
Done (in other PR)

💬 glozow commented on pull request "[NO MERGE] BIP331 Ancestor Package Relay":
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1253290488)
Fixed here

💬 glozow commented on pull request "[NO MERGE] BIP331 Ancestor Package Relay":
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1253291132)
Done (in other PR)

💬 ajtowns commented on pull request "validation: Replace MinBIP9WarningHeight with MinBIP9WarningStartTime":
(https://github.com/bitcoin/bitcoin/pull/27427#discussion_r1253319265)
I'm not sure what I was trying to suggest in the comment above: having `BeginTime()` return a height doesn't make sense. Maybe I confused myself by using `N` as a block height when the PR at the time was already time based?

I think `BeginTime() { return MinBIP9WarningTime > nPowTargetTimespan ? MinBIP9WarningTime - nPowTargetTimespan : MinBIP9WarningTime; }` might make reasonable sense, with the idea being to check that there aren't any warning reported, then set `MinBIP9WarningTime` to a tim
...

🤔 mzumsande reviewed a pull request: "test: bugfix, synchronize indexes synchronously"
(https://github.com/bitcoin/bitcoin/pull/28026#pullrequestreview-1514862606)
> (An alternative, functionally equivalent to this, might be to just make the timeout infinite, see https://github.com/bitcoin/bitcoin/pull/27988#issuecomment-1619218007, but I think this is fine as well.)

I think I'd prefer that option because then we wouldn't need to add a test-only arg to `BaseIndex::Start`, plus having the same thread structure as in production seems more natural and more robust with respect to possible future changes of the init sequence and unit tests.

💬 mzumsande commented on pull request "[NO MERGE] BIP331 Ancestor Package Relay":
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1253333443)
Thanks for the explanation, makes sense. I got confused there somehow.

💬 pinheadmz commented on pull request "net: Add new permission `forceinbound` to evict a random unprotected connection if all slots are otherwise full":
(https://github.com/bitcoin/bitcoin/pull/27600#issuecomment-1622067241)
@mzumsande This summary looks correct to me. Point (1) is covered by the functional test. You are also right that by default most nodes will not need the flag since there will be enough open slots or evictable peers.

I think the use case highlighted in the issue (as well as my own use case) is more about "personal" nodes or limited-resource nodes, where max connections are more limited but we still always want our light clients to be able to connect.

📝 achow101 reopened a pull request: "util/system: Close non-std fds when execing slave processes"
(https://github.com/bitcoin/bitcoin/pull/22417)
Currently, `RunCommandParseJSON` runs its target with whatever fds happen to be open inherited on POSIX platforms. I don't think there's any practical scenario where this is a problem right now, but there's a lot of potential for weird problems (eg, if a process manages to outlive bitcoind - perhaps it's hanging - the listening port(s) won't get released and starting bitcoind again will fail). It's also a potential security issue if a child process is intended to be sandboxed at some point. Not
...

👋 luke-jr's pull request is ready for review: "util/system: Close non-std fds when execing slave processes"
(https://github.com/bitcoin/bitcoin/pull/22417)

💬 luke-jr commented on pull request "util/system: Close non-std fds when execing slave processes":
(https://github.com/bitcoin/bitcoin/pull/22417#issuecomment-1622082377)
Rebased and squashed

💬 fanquake commented on pull request "util/system: Close non-std fds when execing slave processes":
(https://github.com/bitcoin/bitcoin/pull/22417#discussion_r1253372361)
In-code warning suppression has [recently been removed](https://github.com/bitcoin/bitcoin/pull/28002), so you can drop all of the `#if defined(__GNUC__)` blocks.

🤔 jonatack reviewed a pull request: "wallet: Give deprecation warning when loading a legacy wallet"
(https://github.com/bitcoin/bitcoin/pull/27869#pullrequestreview-1514938806)
re-ACK 8fbb6e99bfc85a1b9003cae402a7335843a86abd

modulo https://github.com/bitcoin/bitcoin/pull/27869#pullrequestreview-1477293036

Tested on the command line and with the GUI

<img width="577" alt="Screenshot 2023-07-05 at 10 40 10" src="https://github.com/bitcoin/bitcoin/assets/2415484/042eb69e-9ec7-4e7e-ac19-e072ae977f82">

💬 jonatack commented on pull request "wallet: Give deprecation warning when loading a legacy wallet":
(https://github.com/bitcoin/bitcoin/pull/27869#discussion_r1253378453)
nit, the similar warning at the end of `CreateWallet()` could be updated to use this expanded one

💬 pinheadmz commented on pull request "test: cover addrv2 anchors by adding TorV3 to CAddress in messages.py":
(https://github.com/bitcoin/bitcoin/pull/27452#discussion_r1253398027)
yes thanks

💬 mzumsande commented on pull request "[NO MERGE] BIP331 Ancestor Package Relay":
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1253401345)
Hmm, I think the maximum possible value is currently `101 * MAX_STANDARD_TX_WEIGHT` (after that, `LimitOrphans()` would kick in), so an `unsigned int` should suffice in theory? Maybe use a `uint64_t` if this was to be made configurable by users (see comment above, but not sure if that makes sense).

💬 pinheadmz commented on pull request "test: cover addrv2 anchors by adding TorV3 to CAddress in messages.py":
(https://github.com/bitcoin/bitcoin/pull/27452#discussion_r1253422959)
Good question, I'm just letting it drop out of scope at the end of the test, but [looking into it more](https://docs.python.org/3/library/threading.html#threading.Thread.daemon) it may actually be staying alive until the entire test runner exits.

Should I add a manual close function?

💬 pinheadmz commented on pull request "test: cover addrv2 anchors by adding TorV3 to CAddress in messages.py":
(https://github.com/bitcoin/bitcoin/pull/27452#discussion_r1253426245)
fantastic, thanks for the patch

💬 achow101 commented on pull request "Bump unconfirmed ancestor transactions to target feerate":
(https://github.com/bitcoin/bitcoin/pull/26152#discussion_r1253422291)
In 0f6c13665c4ab7d4928ff0fa63c4e755667f7fd6 "Amend bumpfee for inputs with overlapping ancestry"

nit: I'd prefer if variables were not renamed if they don't need to be, it makes review of this commit slightly harder and unnecessarily breaks git blame. `new_total_fee` is still a valid description of what this variable contains.