💬 instagibbs commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#issuecomment-2215221618)
rebased on master, and s/anchor/dust/ everywhere

💬 mzumsande commented on pull request "assumeutxo: Don't load a snapshot if it's not in the best header chain":
(https://github.com/bitcoin/bitcoin/pull/30320#discussion_r1669272313)
ah, sorry, am on a different computer now and forgot to update the branch... Fixed now.

💬 fjahr commented on pull request "assumeutxo: Don't load a snapshot if it's not in the best header chain":
(https://github.com/bitcoin/bitcoin/pull/30320#issuecomment-2215232338)
re-ACK b715a13d11c6ca7e928b2dee66edcc8c6c30a8d4

Just addressed my latest re-nit.

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1669280166)
I've changed it to "Find the best (highest-feerate, smallest among those in case of a tie) ancestor set among the remaining transactions.", because "best" is a bit more specific than highest-feerate.

Regarding the side note: that rule in `BlockAssembler` is an optimization, as it avoids looking at child transactions with higher ancestor feerate, because the ancestors will have been picked earlier anyway. The same optimization could be made in `AncestorCandidateFinder`, but because it's an $\m
...

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1669281361)
I've added a comment that inc needs to be topological (a term which is defined in the `WorkItem` definition above).

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1669281468)
Fixed.

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1669282068)
I've added a short comment to the docstring of the function instead.

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1669283836)
Done, good idea. Avoiding a separate copy `m_todo` in `Linearize` forced me to rewrite some of the code, which turned out to simplify the LIMO logic slightly.

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1669288946)
@glozow Indeed. Even if this function was changed to return an explicit `optimal`, it would remain quite possible that it returns the optimal without *knowing* it's optimal (because it's possible that the `best` passed in for example was already optimal, but it requires a ton of iterations to exhaust the search space to prove nothing better exists).

@instagibbs Well I think we may want to cache in the mempool clusters whether or not the linearization for them is known to be optimal too, so th
...

💬 instagibbs commented on pull request "policy: Add PayToAnchor(P2A), `OP_TRUE <0x4e73>` as a standard output script for spending":
(https://github.com/bitcoin/bitcoin/pull/30352#issuecomment-2215368575)
@achow101 `wallet_backwards_compatibility.py --legacy` failure seems spurious? can you check?

🤔 stickies-v reviewed a pull request: "fuzz: bound some miniscript operations to avoid fuzz timeouts"
(https://github.com/bitcoin/bitcoin/pull/30197#pullrequestreview-2163854874)
Concept ACK

💬 stickies-v commented on pull request "fuzz: bound some miniscript operations to avoid fuzz timeouts":
(https://github.com/bitcoin/bitcoin/pull/30197#discussion_r1668972900)
It's not obvious to me why we need/prefer to iterate in reverse, here?

💬 stickies-v commented on pull request "fuzz: bound some miniscript operations to avoid fuzz timeouts":
(https://github.com/bitcoin/bitcoin/pull/30197#discussion_r1668971771)
note: with #30263 merged, you can now use `std::reverse::views` again (see #28687)

<details>
<summary>git diff on 178a1da9c4</summary>

```diff
diff --git a/src/test/fuzz/util/descriptor.cpp b/src/test/fuzz/util/descriptor.cpp
index 1ead54f254..d0ed6ee94c 100644
--- a/src/test/fuzz/util/descriptor.cpp
+++ b/src/test/fuzz/util/descriptor.cpp
@@ -3,8 +3,8 @@
// file COPYING or http://www.opensource.org/licenses/mit-license.php.

#include <test/fuzz/util/descriptor.h>
-#include <r
...

💬 stickies-v commented on pull request "fuzz: bound some miniscript operations to avoid fuzz timeouts":
(https://github.com/bitcoin/bitcoin/pull/30197#discussion_r1669371925)
Is this correct? I'd expect something like:

<details>
<summary>git diff on 178a1da9c4</summary>

```diff
diff --git a/src/test/fuzz/util/descriptor.cpp b/src/test/fuzz/util/descriptor.cpp
index 1ead54f254..434df93994 100644
--- a/src/test/fuzz/util/descriptor.cpp
+++ b/src/test/fuzz/util/descriptor.cpp
@@ -108,12 +108,10 @@ bool HasTooManyWrappers(const FuzzBufferType& buff, const int max_wrappers)
auto count{0};
// We iterate in reverse order to start counting when we enc
...

💬 stickies-v commented on pull request "fuzz: bound some miniscript operations to avoid fuzz timeouts":
(https://github.com/bitcoin/bitcoin/pull/30197#discussion_r1668978835)
nit: `HasTooManySubFrags` seems like a more accurate name?
```suggestion
bool HasTooManySubFrags(const FuzzBufferType& buff, const int max_subs = MAX_SUBS);
```

💬 andrewtoth commented on pull request "Don't empty dbcache on prune flushes: >30% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1669602373)
Done.

💬 andrewtoth commented on pull request "Don't empty dbcache on prune flushes: >30% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/28280#issuecomment-2216328752)
Added a `CoinsViewCacheCursor` struct to encapsulate the iteration of the linked list when passed up to `BatchWrite`.

📝 mzumsande opened a pull request: "rpc, rest: Improve getblock error when only header is available"
(https://github.com/bitcoin/bitcoin/pull/30410)
Fixes #20978

If a block was pruned, `getblock` already returns a specific error: "Block not available (pruned data)".
But if we haven't received the full block yet (e.g. in a race with block downloading after a new block was received headers-first, or during IBD) we just return an unspecific "Block not found on disk" error and log
`ERROR: ReadBlockFromDisk: OpenBlockFile failed for FlatFilePos(nFile=-1, nPos=0) `
which suggest something went wrong even though this is a completely normal an
...

💬 mzumsande commented on issue "RPC `getblock` resulted in 500 and ReadBlockFromDisk: OpenBlockFile failed for FlatFilePos(nFile=-1, nPos=0)":
(https://github.com/bitcoin/bitcoin/issues/20978#issuecomment-2216427835)
see #30410

💬 TheCharlatan commented on pull request "rpc, rest: Improve getblock error when only header is available":
(https://github.com/bitcoin/bitcoin/pull/30410#issuecomment-2216485352)
Concept ACK