💬 pinheadmz commented on pull request "test: use sleepy wait-for-log in reindex readonly":
(https://github.com/bitcoin/bitcoin/pull/30006#discussion_r1585294720)
Gotcha, the default timeout in `wait_for_debug_log()` now `busy_wait_for_debug_log()` is 60 unless im mistaken?

💬 maflcko commented on pull request "test: use sleepy wait-for-log in reindex readonly":
(https://github.com/bitcoin/bitcoin/pull/30006#discussion_r1585296203)
Sure, any value works. But 2 seconds may be a bit on the risky side.

💬 pinheadmz commented on pull request "test: use sleepy wait-for-log in reindex readonly":
(https://github.com/bitcoin/bitcoin/pull/30006#discussion_r1585296893)
done, thanks

💬 maflcko commented on pull request "test: use sleepy wait-for-log in reindex readonly":
(https://github.com/bitcoin/bitcoin/pull/30006#issuecomment-2086446928)
utACK fd6a7d3a13d89d74e161095b0e9bd3570210a40c

📝 achow101 opened a pull request: "chainparams: Add achow101 DNS seeder"
(https://github.com/bitcoin/bitcoin/pull/30007)
I wrote a [DNS seeder](https://github.com/achow101/dnsseedrs) and have been running it for the past 2 months now. I believe it is ready/good enough to be used as an additional DNS seeder for all of our supported public networks.

💬 laanwj commented on pull request "[PoC, nomerge] IPv6 PCP pinhole test":
(https://github.com/bitcoin/bitcoin/pull/30005#issuecomment-2086638251)
>There is a UPnP plugin, but that's not what you're using (and probably best left uninstalled).

Yea, according to [this list](https://github.com/opnsense/plugins/tree/master), UPnP and PCP is the same plugin. It could be that they can be turned on and off seperately in the plugin configuration (it's similar for OpenWRT).

💬 pinheadmz commented on pull request "Support JSON-RPC 2.0 when requested by client":
(https://github.com/bitcoin/bitcoin/pull/27101#discussion_r1585388938)
Without it there is a compile error:

```
In file included from ./rpc/server.h:9:
./rpc/request.h:22:79: error: unknown type name 'JSONRPCRequest'
22 | std::string JSONRPCReply(const UniValue& result, const UniValue& error, const JSONRPCRequest& jreq);
| ^
1 error generated.
```

💬 laanwj commented on pull request "chainparams: Add achow101 DNS seeder":
(https://github.com/bitcoin/bitcoin/pull/30007#discussion_r1585404894)
Looks like it's missing "." at the end (all the other seeder DNS names have this)--same for the testnet one

💬 alfonsoromanz commented on pull request "test: Assumeutxo: import snapshot in a node with a divergent chain":
(https://github.com/bitcoin/bitcoin/pull/29996#issuecomment-2086782948)
I splitted the original commit into two commits (one for each test). The second test (https://github.com/bitcoin/bitcoin/pull/29996/commits/af0f401258e0c189799a36f4487eaa751d779e7b) may be redundant with this one: https://github.com/bitcoin/bitcoin/pull/29428. The only difference is that my test is executed on a node that has a divergent chain after block 199. I did that to cover this scenario described in the comments

`[...] Loading a snapshot when the current chain tip is: [...] Not an anc
...

💬 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
...