💬 mzumsande commented on issue "qa: Intermittent failure in `feature_fee_estimation.py`":
(https://github.com/bitcoin/bitcoin/issues/23165#issuecomment-1624334379)
Just noting here too (I also posted in #20725) that failures can be reproduced by using the PRNG seed from the log (`7288975409214300634` in the most recent one) and running with `--randomseed`. So it would be good to include that seed in future reports - the earlier ones are no longer accessible from cirrus.

💬 jonatack commented on pull request "p2p: Drop m_recently_announced_invs bloom filter":
(https://github.com/bitcoin/bitcoin/pull/27675#discussion_r1254974082)
Thanks, makes sense, and I see that your change makes the conditional here the same as in `ProcessMessage::TX` followed by the same comment.

```cpp
if (peer->m_wtxid_relay && txid != wtxid) {
// Insert txid into m_tx_inventory_known_filter, even for
// wtxidrelay peers. This prevents re-adding of
// unconfirmed parents to the recently_announced
// filter, when a child tx is requested. See
// ProcessGetData().

...

🤔 ismaelsadeeq reviewed a pull request: "Fee estimation: extend bucket ranges consistently"
(https://github.com/bitcoin/bitcoin/pull/21161#pullrequestreview-1517440130)
The issue this is solving occurs intermittently.
I tested the test failed on recent master c325f0f with [seed](https://github.com/bitcoin/bitcoin/issues/20725#issuecomment-1624279055) from @mzumsande and passed on this PR rebased on master head c325f0f.

Did not finish understanding the PR yet

🤔 jonatack reviewed a pull request: "p2p: Drop m_recently_announced_invs bloom filter"
(https://github.com/bitcoin/bitcoin/pull/27675#pullrequestreview-1517398008)
ACK 172fa815e08b54c61b24d552f065df15046aef3c

With this simplification, test coverage for the new logic might be feasible?

💬 jonatack commented on pull request "p2p: Drop m_recently_announced_invs bloom filter":
(https://github.com/bitcoin/bitcoin/pull/27675#discussion_r1254977700)
caf32d2 mentioning `m_sequence_number`'s new responsibility for p2p tx relay might be helpful (or alternatively, drop "external")

```suggestion
// In-memory counter for internal (p2p tx relay) and external (zmq) mempool tracking purposes.
```

💬 jonatack commented on pull request "p2p: Drop m_recently_announced_invs bloom filter":
(https://github.com/bitcoin/bitcoin/pull/27675#discussion_r1254981645)
c219b68 nit, could add `[[nodiscard]]` while touching this

💬 jonatack commented on pull request "p2p: Drop m_recently_announced_invs bloom filter":
(https://github.com/bitcoin/bitcoin/pull/27675#discussion_r1254980474)
caf32d2 nit, could be ` [[nodiscard]]`

👍 theStack approved a pull request: "Add support for RFC8439 variant of ChaCha20"
(https://github.com/bitcoin/bitcoin/pull/27985#pullrequestreview-1517469616)
Code-review ACK 200e1a292b277d6c32dbd6081d38b715cbc079cb

Verified that the implementation matches the RFC8439 specification (https://datatracker.ietf.org/doc/html/rfc8439#section-2.3) and checked that the test vectors match the ones from the linked sources (https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04#section-7 and https://datatracker.ietf.org/doc/html/rfc8439#page-30).

Note for other reviewers (that get as easily confused as me): we don't store the constants in the `inp
...

💬 achow101 commented on pull request "Add support for RFC8439 variant of ChaCha20":
(https://github.com/bitcoin/bitcoin/pull/27985#issuecomment-1624433876)
Is the current ChaCha20 implementation used for anything that needs backwards compatibility?

💬 sipa commented on pull request "Add support for RFC8439 variant of ChaCha20":
(https://github.com/bitcoin/bitcoin/pull/27985#issuecomment-1624469014)
@achow101 Good question!

It's used by FastRandomContext and MuHash. I haven't investigated whether there are any uses of FastRandomContext that could generate more than 256 GiB of data, but even if there are there it's possible to at least use the new seeking style (the current implementation, when using the 96/32 split, when the block counter overflows, just increments the nonce, which is exactly what we'd want for an RNG anyway).

So no - I think all existing uses could be converted to us
...

💬 ariard commented on pull request "[NO MERGE] BIP331 Ancestor Package Relay":
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1255193877)
Okay so I’ve been looking into the code, and yes to my understanding there is _no_ processing penalty at `GETPKGTXNS` reception in `ProcessMessage` than our child has 1 or N parents, we’re calling `FindTxForGetdata` to compose the response `PKGTXNS`. This invalidate this specific source of concern.

> we have rate-limiting based on the way the parents are fetched (i.e individiually rather than in batch) the equivalent package of A+E will propagate better.

I’ll maintain there is still an int
...

💬 ariard commented on pull request "[NO MERGE] BIP331 Ancestor Package Relay":
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1255197289)
Yes adding a mention in BIP331 than a p2p packages can support multiple versions of policy regimes e.g nversion=3.

For flexibility towards the node operators in their resource management (especially for DoS protection on low-performance hosts), I think we should have a `acceptnversion=3`setting, that way a node operator can opted in package relay though not in the most computationally expensive type of policy regimes. The utility of such setting is theoretical as long as we have one policy r
...

💬 ariard commented on issue "Package Relay Project Tracking":
(https://github.com/bitcoin/bitcoin/issues/27463#issuecomment-1624619100)
From a reviewing standpoint on #27742, I think it would benefit if the release aim for current package version (BIP331 + nversion=3 policy regime) is explicitly bounded to Lightning time-sensitive confirmation flows, especially in matters of DoS protection:
- broadcast of revoked transaction output spend
- broadcast of a commitment transaction with pending HTLC outputs and its associated second-stage transactions

I think this covers the most sensitive Lightning flows impacted by the pinning
...

👍 MarcoFalke approved a pull request: "wallet: don't include bdb files from our headers"
(https://github.com/bitcoin/bitcoin/pull/28039#pullrequestreview-1517976711)
lgtm

💬 MarcoFalke commented on pull request "wallet: don't include bdb files from our headers":
(https://github.com/bitcoin/bitcoin/pull/28039#discussion_r1255284707)
nit in c217c542f0fd9c741b79a91419247bd44440e6d9: I think you forgot `static` or `namespace`?

👍 MarcoFalke approved a pull request: "wallet: sqlite: don't include sqlite files from our headers"
(https://github.com/bitcoin/bitcoin/pull/28040#pullrequestreview-1517997528)
lgtm. I wonder why iwyu can't transform those two symbols into forward decls. Output on master:

```
The full include-list for wallet/sqlite.h:
...
#include <sqlite3.h> // for sqlite3_stmt, sqlite3
...

👍 TheCharlatan approved a pull request: "wallet: sqlite: don't include sqlite files from our headers"
(https://github.com/bitcoin/bitcoin/pull/28040#pullrequestreview-1518158272)
Nice, ACK bea9fc2600635020fd28ec7a6613c92a6f349a86

👍 kristapsk approved a pull request: "wallet: sqlite: don't include sqlite files from our headers"
(https://github.com/bitcoin/bitcoin/pull/28040#pullrequestreview-1518168856)
utACK bea9fc2600635020fd28ec7a6613c92a6f349a86

💬 MarcoFalke commented on pull request "test: bugfix, synchronize indexes synchronously":
(https://github.com/bitcoin/bitcoin/pull/28026#issuecomment-1624951013)
Does your feedback from https://github.com/bitcoin/bitcoin/pull/28036#issuecomment-1623813703 also apply here? I think you'll also have to check for it being synced?

```
Assert(index.GetSummary().synced);

👍 hebasto approved a pull request: "wallet: sqlite: don't include sqlite files from our headers"
(https://github.com/bitcoin/bitcoin/pull/28040#pullrequestreview-1518273732)
ACK bea9fc2600635020fd28ec7a6613c92a6f349a86, I have reviewed the code and it looks OK.