💬 murchandamus commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#discussion_r1809279480)
```suggestion
dust output in a transaction, provided the transaction
```

👍 laanwj approved a pull request: "rpc: net: follow-ups for #30062"
(https://github.com/bitcoin/bitcoin/pull/30183#pullrequestreview-2383023507)
thanks for updating !
re-ACK a16917fb5981d1465ffd4c036586f8729e683b73

💬 hasti0073 commented on pull request "Add Signet and testnet4 launch shortcuts for Windows":
(https://github.com/bitcoin/bitcoin/pull/26334#issuecomment-2427467282)
1JjXPKN1yyPMxi2WvJv4BHVaJqqgzxSRGg

💬 instagibbs commented on pull request "Remove mempoolfullrbf":
(https://github.com/bitcoin/bitcoin/pull/30592#discussion_r1809368084)
will fix if I touchup

💬 instagibbs commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#discussion_r1809451766)
done

💬 instagibbs commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#discussion_r1809451807)
done

💬 sdaftuar commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#discussion_r1809453084)
Hm, I I think that approach uses an extra 24 bytes per mempool entry, which strikes me as a bit heavy for what we need. Let's see if this is fast enough as-is and if so, call it a day.

💬 instagibbs commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#discussion_r1809480956)
Alternative is to store a bool, and use that to filter 99.9% of transactions that won't have dust, and then eat the O(num_outputs) cost to find the dust.

With 1000 inputs/outputs and a small number of dust outputs, I get:
```
| ns/op | op/s | err% | total | benchmark
|--------------------:|--------------------:|--------:|----------:|:----------
| 60,600.53 | 16,501.51 | 0.7% | 0.01 | `MempoolCheckEphemeralSpends`
```

When
...

💬 hodlinator commented on pull request "Windows bitcoind stall debugging [NOMERGE, DRAFT]":
(https://github.com/bitcoin/bitcoin/pull/30956#issuecomment-2427711698)
Debugged a 3rd dump:
https://github.com/hodlinator/bitcoin/actions/runs/11414623090
Same stacks in threads and local function state in `RandAddSeedPerfmon()` was similar/same as observed in 2 previous dump files - `nSize = 843750` (250000 × (1.5^3)).


### Main thread

```
ntdll.dll!NtReleaseSemaphore() Unknown
KERNELBASE.dll!ReleaseSemaphore() Unknown
WmiApRpl.dll!WmiReverseGuard::LeaveRead(long) Unknown
WmiApRpl.dll!WmiReverseMemoryExt<class WmiReverseGuard>::Read(void *,uns
...

📝 COPILOT-WEB-ui opened a pull request: "Update README.md to Format Header Correctly"
(https://github.com/bitcoin/bitcoin/pull/31126)
This pull request updates the `README.md` file to improve its readability by formatting the first line as a markdown header. The change involves adding a hashtag at the beginning of the line, transforming "Bitcoin Core integration/staging tree" into "# Bitcoin Core integration/staging tree". This modification enhances the document structure, making it easier for users to identify the title at a glance.

No changes have been made to functions, global data structures, or external interfaces. Th
...

✅ fanquake closed a pull request: "Update README.md to Format Header Correctly"
(https://github.com/bitcoin/bitcoin/pull/31126)

💬 stevenroose commented on pull request "Update README.md to Format Header Correctly":
(https://github.com/bitcoin/bitcoin/pull/31126#issuecomment-2427777849)
Who released the kraken?

💬 sipa commented on pull request "Update README.md to Format Header Correctly":
(https://github.com/bitcoin/bitcoin/pull/31126#issuecomment-2427799816)
The krAIken?

💬 hodlinator commented on pull request "test: Shut down framework cleanly on RPC connection failure":
(https://github.com/bitcoin/bitcoin/pull/30660#issuecomment-2427838505)
(Rebased onto latest master).

💬 wiz commented on issue "Testnet4 consensus failure due to timewarp related "softfork"":
(https://github.com/bitcoin/bitcoin/issues/30786#issuecomment-2427918316)
I figured the community had started mining it by now - will take a look

⚠️ casey opened an issue: "getblockchaininfo `verificationprogress` never reaches 1.0"
(https://github.com/bitcoin/bitcoin/issues/31127)
In the output of `bitcoin-cli getblockchaininfo`, `verificationprogress` sometimes never reaches 1.0, and fluctuates around 0.99999.

```
{
...
"verificationprogress": 0.9999945316157191,
...
}
```

This was reported in #26433, and closed because `verificationprogress` is only an estimate. I would have commented in that issue, but it's locked. The rationale for closing the issue was because the OP in the issue wanted to use `verificationprogress` to check if the chain is synced,
...

💬 glozow commented on pull request "Package validation: accept packages of size 1":
(https://github.com/bitcoin/bitcoin/pull/31096#issuecomment-2427979944)
> @glozow we may want to consider relaxing `package-not-child-with-unconfirmed-parents` to allow people to submit just the cpfp alone? Should be done in a separate PR regardless.

That works without validation changes if you make the split happen within RPC or ProcessNewPackage.

💬 jonatack commented on issue "getblockchaininfo `verificationprogress` never reaches 1.0":
(https://github.com/bitcoin/bitcoin/issues/31127#issuecomment-2428007153)
Maybe it could return 1 instead of the estimate, when "blocks" equals "headers" or "initialblockdownload" is false.

💬 sipa commented on issue "getblockchaininfo `verificationprogress` never reaches 1.0":
(https://github.com/bitcoin/bitcoin/issues/31127#issuecomment-2428013831)
The verification progress estimate is computed by first determining an estimate on the total number of transactions to date (based on the current time, and a known growth rate), and then dividing the actual number of transactions in the chain by that.

If we want something that looks nicer, it's possible to instead of using the current time, use the timestamp of the best known block header. This will give wildly inaccurate results while headers are still syncing, though.

💬 kevkevinpal commented on pull request "test: Assert that when we add the max orphan amount that we cannot add anymore and that a random orphan gets dropped":
(https://github.com/bitcoin/bitcoin/pull/31040#issuecomment-2428044905)
> > I'm a bit confused to the behavior i'm observing on this PR. Not necessarily anything to do with the test, but how orphans are handled.
> > I tried adding another part to the test case to check we can clear the orphanage by propagating parent transactions: [Christewart@04815c4](https://github.com/Christewart/bitcoin/commit/04815c463d331f674f67fdcb3b8da601484d7a33)
> > It appears that to _totally_ clear the orphanage, we need to propagate the parent transaction for the last child transactio
...