💬 besoeasy commented on issue "DNS seed "seed.bitcoinstats.com" doesn't support filtering while the comments says it does":
(https://github.com/bitcoin/bitcoin/issues/29911#issuecomment-2086948476)
yea seeds resolve to nothing, almost 80% nodes are down

💬 sipa commented on pull request "Several randomness improvements":
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1585458355)
> #28558 made PeerManager own a FastRandomContext, so we could (should?) use `m_rng` here instead (otherwise `PeerManager::Options::deterministic_rng` still only applies to some of the randomness).

I've changed the PR to reuse `PeerManagerImpl::m_rng`.



> Since this PR kind of makes individual "make this component deterministic" options redudant, we could consider reverting #28558 (not necessarily in this PR)?

Maybe. I've opted to use it where possible for now as it's a smaller chang
...

💬 achow101 commented on pull request "chainparams: Add achow101 DNS seeder":
(https://github.com/bitcoin/bitcoin/pull/30007#discussion_r1585461831)
Done

📝 achow101 opened a pull request: "seeds: Pull additional nodes from my seeder and update fixed seeds"
(https://github.com/bitcoin/bitcoin/pull/30008)
The [DNS seeder](https://github.com/achow101/dnsseedrs) that I wrote collects statistics on node reliability in the same way that sipa's seeder does, and also outputs this information in the same file format. Thus it can also be used in our fixed seeds update scripts. My seeder additionally crawls onion v3, i2p, and cjdns, so will now be able to set those fixed seeds automatically rather than curating manual lists.

In doing this update, I've found that `makeseeds.py` is missing newer versions
...

💬 jonatack commented on pull request "seeds: Pull additional nodes from my seeder and update fixed seeds":
(https://github.com/bitcoin/bitcoin/pull/30008#discussion_r1585488736)
It looks like something odd happened to the manual onion and i2p seeds. Only a small range of first letters were present, and seeds run by colleagues and the bitcoin community were no longer present.

💬 1440000bytes commented on issue "DNS seed "seed.bitcoinstats.com" doesn't support filtering while the comments says it does":
(https://github.com/bitcoin/bitcoin/issues/29911#issuecomment-2087301007)
> almost 80% nodes are down

seeds are up but the results they give are down? yes. can't do anything they are hardcoded forever.

Do not use them. `dnsseed=0` and `fixedseeds=0`

💬 brunoerg commented on pull request "fuzz: wallet: add target for `CreateTransaction`":
(https://github.com/bitcoin/bitcoin/pull/29936#issuecomment-2087315636)
Rebased

💬 achow101 commented on pull request "seeds: Pull additional nodes from my seeder and update fixed seeds":
(https://github.com/bitcoin/bitcoin/pull/30008#discussion_r1585525305)
They were updated in #29561, and the addresses were pulled from my node's addrman. Some sorting happened somewhere, and because `makeseeds.py` doesn't shuffle (this PR adds a commit that does that), when it applied the max node count, it ended up with the tail end of that list.

💬 naiyoma commented on pull request "test: Assumeutxo: import snapshot in a node with a divergent chain":
(https://github.com/bitcoin/bitcoin/pull/29996#issuecomment-2087518282)
Concept ACK covers more tests scenarios for AssumeUTXO

🤔 achow101 reviewed a pull request: "p2p: opportunistically accept 1-parent-1-child packages"
(https://github.com/bitcoin/bitcoin/pull/28970#pullrequestreview-2032571316)
ACK e518a8bf8abf3d7b83c9013f56d0dca18ae04d6f

💬 achow101 commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1585554972)
In 092c978a42e8f4a02291b994713505ba8aac8b28 "[txpackages] add canonical way to get hash of package"

Is there a reason to convert the wtxids into hex strings for this comparison? That seems kind of expensive, especially when `Wtxid` already has an `operator<`.

I surmise that this has to do with the "concatenated in lexicographical order (treating the wtxids as little endian encoded uint256, smallest to largest)" and BIP 331 defines the same thing, but it's not clear to me why it must be lik
...

💬 instagibbs commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1585616207)
made a similar point at https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1571063644 fwiw (with a response attached)

🚀 achow101 merged a pull request: "p2p: opportunistically accept 1-parent-1-child packages"
(https://github.com/bitcoin/bitcoin/pull/28970)

🤔 mzumsande reviewed a pull request: "p2p: opportunistically accept 1-parent-1-child packages"
(https://github.com/bitcoin/bitcoin/pull/28970#pullrequestreview-2032696340)
Light ACK e518a8bf8abf3d7b83c9013f56d0dca18ae04d6f
I didn't review the functional tests in much detail, but the p2p code looks good to me.

💬 mzumsande commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1585612529)
nit: I think that 6c51e1d7d021ed6523107a6db87a865aaa8fc4c9 changes behavior such that txns which are now in `m_recent_rejects_reconsiderable` instead of `m_recent_rejects` will be ignored when calling `m_recent_rejects.contains(...)`. That is probably an undesired change of behavior - however it's just for 1 commit :man_shrugging:

💬 mzumsande commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1585614142)
I agree, would be nice to avoid this code duplication.

💬 mzumsande commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1585616821)
I wonder if there are situations in which we fail on a package level and therefore return here and never call `ProcessInvalidTx()` to remove the child from the orphanage. Would that be possible, for example, with v3 transactions that violate `PackageV3Checks()`, and is there something we could do against it? (or should, maybe it's not that terrible?).

⚠️ BullishNode opened an issue: "Change estimate_mode default to "ECONOMICAL" in these RPC calls"
(https://github.com/bitcoin/bitcoin/issues/30009)
### Please describe the feature you'd like to see added.

The default fee estimate mode for the following RPC calls is set to "ECONOMICAL" rather than "CONSERVATIVE".

My observation running a Bitcoin non-custodial exchange and payment processor which creates a lot transactions is that Bitcoin Core on conservative mode consistently overpays transaction fees as compared to mempool's fee estimation algorithm. I have collected data on this, if anyone needs convincing, but I think this is common k
...

✅ achow101 closed an issue: "AddTimeData will never update nTimeOffset past 199 samples"
(https://github.com/bitcoin/bitcoin/issues/4521)

🚀 achow101 merged a pull request: "Simplify network-adjusted time warning logic"
(https://github.com/bitcoin/bitcoin/pull/29623)