💬 instagibbs commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#discussion_r1809451766)
done
(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
(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.
(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
...
(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
...
(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
...
(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)
(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?
(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?
(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).
(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
(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,
...
(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.
(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.
(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.
(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
...
(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
...
💬 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-2428049870)
> Concept ACK for the test While we are trying to add another orphan transaction when the max amount is reached , why are we dropping a random orphan and not just the incoming orphan ? Even in the condition of the node getting DOSed , having to remove a random transaction translates to some amount of work done while its not the case when we just drop the incoming transaction.
If we drop the incoming orphan then an attacker can quickly fill up a node's orphan pool with tx's that will never get
...
(https://github.com/bitcoin/bitcoin/pull/31040#issuecomment-2428049870)
> Concept ACK for the test While we are trying to add another orphan transaction when the max amount is reached , why are we dropping a random orphan and not just the incoming orphan ? Even in the condition of the node getting DOSed , having to remove a random transaction translates to some amount of work done while its not the case when we just drop the incoming transaction.
If we drop the incoming orphan then an attacker can quickly fill up a node's orphan pool with tx's that will never get
...
🤔 glozow reviewed a pull request: "cluster mempool: Implement changeset interface for mempool"
(https://github.com/bitcoin/bitcoin/pull/31122#pullrequestreview-2383546169)
Concept ACK, did a first pass
(https://github.com/bitcoin/bitcoin/pull/31122#pullrequestreview-2383546169)
Concept ACK, did a first pass
💬 glozow commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1809704580)
`StageAddition` and `StageRemoval` seem a bit more intuitive, but it's a nit
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1809704580)
`StageAddition` and `StageRemoval` seem a bit more intuitive, but it's a nit
💬 glozow commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1809737214)
Question: why isn't this a `shared_ptr` / what's the purpose of the `unique_ptr`? I get that there should only ever be one changeset, but I'm confused by the fact that this carries a copy of the underlying raw pointer, as the `unique_ptr` then doesn't seem very unique.
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1809737214)
Question: why isn't this a `shared_ptr` / what's the purpose of the `unique_ptr`? I get that there should only ever be one changeset, but I'm confused by the fact that this carries a copy of the underlying raw pointer, as the `unique_ptr` then doesn't seem very unique.