💬 glozow commented on pull request "p2p: Allow 1P1C to fetch parent from compact block extra_txn":
(https://github.com/bitcoin/bitcoin/pull/30032#discussion_r1589595727)
Feels inefficient/expensive to construct a package + call these checks for every tx every time there's a missing input. Maybe parameterize by the txid of the missing parent (i.e. just 1 exists) and first check that the txid matches?

💬 glozow commented on pull request "p2p: Allow 1P1C to fetch parent from compact block extra_txn":
(https://github.com/bitcoin/bitcoin/pull/30032#discussion_r1589595916)
nice :brain:

💬 glozow commented on pull request "p2p: Allow 1P1C to fetch parent from compact block extra_txn":
(https://github.com/bitcoin/bitcoin/pull/30032#discussion_r1589590238)
needs comment

💬 instagibbs commented on pull request "p2p: Allow 1P1C to fetch parent from compact block extra_txn":
(https://github.com/bitcoin/bitcoin/pull/30032#issuecomment-2093553813)
> Nice. Have you tried running this to see how often it hits?

I'll do some logging :+1: I suspect it'll be quite above non-0 because from my log-reading just-below-minfee is quite commonly a reason for missing the parent.

💬 jlopp commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2093554109)
> Does your node still have network adjusted time?

That could explain it. IIRC I was originally using v25.

I can generate a genesis block in about 15 minutes so no biggie to try variations.
Here's an alternate genesis block with a zeroed out pubkey:

```
./generate-genesis -timestamp 1714658825 -pubkey 000000000000000000000000000000000000000000000000000000000000000000 -psz "CCN 02/May/2024 Bitcoin Testnet Could Need Reset"
Ctrl Hash: 0x00000000fa64304c1e2ebace74844da4a1a7fecca7fb94a0f
...

📝 willcl-ark opened a pull request: "ci: add markdown link check job"
(https://github.com/bitcoin/bitcoin/pull/30034)
Potential followup to: #30025

This should prevent us reintroducing broken markdown links.

It does not test "online" (external) links, only those within this repo. Both relative and absolute links are parsed successfully if they resolve.

💬 willcl-ark commented on pull request "ci: add markdown link check job":
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2093636778)
Without #30025 (or alternative fix) the new action being added here will fail.
It takes ~11s to run:

- [example pass](https://github.com/willcl-ark/bitcoin/actions/runs/8943826589)
- [example fail](https://github.com/willcl-ark/bitcoin/actions/runs/8943826087)

📝 instagibbs converted_to_draft a pull request: "p2p: Allow 1P1C to fetch parent from compact block extra_txn"
(https://github.com/bitcoin/bitcoin/pull/30032)
One relatively common pattern of 1P1C relay is receiving
a just-below-minfee parent, dropping it and marking it
as reconsiderable, then fetching it again from the peer
once the child is added to the orphanage.

A cache of dropped parents would be useful, and it turns
out we're already opportunistically storing transactions
like this for compact blocks as "extra transactions".
Use this size-limited cache to potentially fetch a
reconsiderable parent from memory, and submit for validation.
...

👍 TheCharlatan approved a pull request: "build: no-longer disable WARN_CXXFLAGS when CXXFLAGS is set"
(https://github.com/bitcoin/bitcoin/pull/25972#pullrequestreview-2038887677)
ACK f0e22be69a15248c42964d57f44ce8c37a36081d

📝 paplorinc opened a pull request: "test: Add a few more corner cases to the base58 test suite"
(https://github.com/bitcoin/bitcoin/pull/30035)
Split out the additional tests from the base58 optimization PR, see: https://github.com/bitcoin/bitcoin/pull/29473#discussion_r1526210147

🤔 sr-gi reviewed a pull request: "p2p: index TxOrphanage by wtxid, allow entries with same txid"
(https://github.com/bitcoin/bitcoin/pull/30000#pullrequestreview-2038712299)
Concept ACK

💬 sr-gi commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589529436)
In 646aa4da91c03a0e72d086cae281aa0688f2f41d

This is only used for logging now. Do we care about logging the `txid` now that the map is keyed by `wtxid`?

💬 sr-gi commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589549760)
In 646aa4da91c03a0e72d086cae281aa0688f2f41d

Same here, do we still care about logging `txids`? I guess this applies to all the file, so not pointing it out again

💬 sr-gi commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589569008)
In 646aa4da91c03a0e72d086cae281aa0688f2f41d

This should not be called `orphanHash` anymore, but also, this could be inlined

💬 sr-gi commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589547282)
In 646aa4da91c03a0e72d086cae281aa0688f2f41d

nit: `nErased` is a counter right? Shouldn't this read `txs` instead?

💬 sr-gi commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589571339)
Also, in L231:

`for (const auto& orphanHash : vOrphanErase)` -> `for (const auto& wtxid : vOrphanErase)`

💬 Sjors commented on pull request "depends: swap some cctools tools for LLVM tools":
(https://github.com/bitcoin/bitcoin/pull/29739#issuecomment-2093692188)
@fanquake I get the same hashes on AMD Ubuntu 24.04

⚠️ IAmAdamRest opened an issue: "Possible to Ban Clients by Name?"
(https://github.com/bitcoin/bitcoin/issues/30036)
### Please describe the feature you'd like to see added.

Thousands of "/Satoshi-BTC(Bitcoin Finance):0.15.1/" peers are suddenly connecting to my two nodes and sending GIGABYTES of information even though my nodes are fully synced, this doesn't feel like expected behavior.

Can we have a way to ban something like this? They are connecting from only cloud providers or inside mainland China. I can barely keep up banning these. Is it possible to have a way to reject this sort of thing from happe
...

💬 IAmAdamRest commented on issue "Manually Banning Peers Results in Crash":
(https://github.com/bitcoin/bitcoin/issues/29916#issuecomment-2093708486)
> @iotamega @IAmAdamRest
>
> Does the issue happen with Bitcoin Core v26.1, v25.2?

I don't know, I can download one of those. I am likely just giving up though as this network seems to be full of spam trash nodes that seem intent on just overwhelming machines. I have spent all day banning peers that are sending gigs of data even though I am fully synced and wasting my bandwidth.

💬 pinheadmz commented on issue "Possible to Ban Clients by Name?":
(https://github.com/bitcoin/bitcoin/issues/30036#issuecomment-2093720851)
You can not ban by user agent (that is very easily spoofed) but you can ban a range of IPs. What exactly is happening here? What are you receiving? Bitcoin Core already has lots of DoS mitigation mechanisms.