💬 brunoerg commented on pull request "fuzz: Limit parse_univalue input length":
(https://github.com/bitcoin/bitcoin/pull/30473#discussion_r1684608209)
Nice

👍 brunoerg approved a pull request: "fuzz: Limit parse_univalue input length"
(https://github.com/bitcoin/bitcoin/pull/30473#pullrequestreview-2188623731)
utACK fa80b16b20dffcb85b80f75fee64ed333f2062f9

📝 fanquake converted_to_draft a pull request: "guix: bump time-machine to 1aa8dfaeec3c6e4e587aadf7440246f7c5c04b9f"
(https://github.com/bitcoin/bitcoin/pull/30452)
Needed for https://github.com/bitcoin/bitcoin/issues/30210. This doesn't switch runtimes, because upstream is
still configured to use the old runtime. See:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=17188be0f723e00377b21b767f5447d7938a116e.

git-mimimal 2.45.1 -> 2.45.2
Kernel Headers 6.1.92 -> 6.1.99
LLVM 18.1.6 -> 18.1.8
mingw-w64 11.0.1 -> 12.0.0
NSIS 3.09 -> 3.10
patch 2.7.6 -> 2.7.6-0.f144b35

💬 brunoerg commented on issue "scriptpubkeyman fuzz target TopUp is slow":
(https://github.com/bitcoin/bitcoin/issues/30476#issuecomment-2239617385)
Instead of calling `TopUp` every time we call `AddDescriptorKey`, maybe it could be done just one time per iteration. I can see it.

🤔 glozow reviewed a pull request: "cluster mempool: cluster linearization algorithm"
(https://github.com/bitcoin/bitcoin/pull/30126#pullrequestreview-2182496612)
code review ACK, planning to spend more time reviewing the tests

💬 glozow commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684495081)
```suggestion
* In this case, the possibilities are, in order:
```

💬 glozow commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684658967)
nit: maybe something like "explore and add a work item if there are any transactions left to split on" ?

💬 glozow commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684491008)
a53b7eb82c3: nitty nit
```suggestion
* The serialization format outputs information about transactions in a topological order (parents
```

🤔 BrandonOdiwuor reviewed a pull request: "test: Add arguments for creating a slimmer TestingSetup"
(https://github.com/bitcoin/bitcoin/pull/30399#pullrequestreview-2188743300)
Concept ACK

💬 hebasto commented on pull request "depends: build zeromq with CMake":
(https://github.com/bitcoin/bitcoin/pull/29723#issuecomment-2239718965)
My Guix build:
```
x86_64
c7aa6bd428ba4ea1c925dafe4df3505ad92e84a196b17c8cb7965d7db231e6a0 guix-build-0388ad0d65b6/output/aarch64-linux-gnu/SHA256SUMS.part
944e734a719886ec26aff12a80be67d28f2c4b7781a341894d3e2ca8477e3497 guix-build-0388ad0d65b6/output/aarch64-linux-gnu/bitcoin-0388ad0d65b6-aarch64-linux-gnu-debug.tar.gz
087ac7a0c1d87a95adacb9fa138aced37a172d4d5199fc75c64831d9f6211972 guix-build-0388ad0d65b6/output/aarch64-linux-gnu/bitcoin-0388ad0d65b6-aarch64-linux-gnu.tar.gz
3b0105522
...

💬 instagibbs commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#issuecomment-2239730901)
Ok, the rework ended up being quite easy.

Pushed an update that generalizes to non-TRUC transactions, but as noted earlier, individual transactions have to meet minrelay for now unless they are TRUC, see/divert discussion here for that specific point: https://github.com/bitcoin/bitcoin/pull/26933 . If this restriction goes away, it will be usable(see tests I added with v2 transactions at the bottom where I checked it). Note that we are still constrained to 1P1C relay until we get general pack
...

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

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684698616)
We don't invoke ExhaustiveCandidateFinder for larger clusters because it just gets too computationally expensive to do so. I've added a comment to clarify this.

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

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

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

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684698968)
Did something like that.

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684699167)
I've added a comment to clarify.

💬 hodlinator commented on pull request "fix: Make TxidFromString() respect string_view length":
(https://github.com/bitcoin/bitcoin/pull/30436#discussion_r1684699856)
> Note: This line isn't directly equivalent to previous code because it trims whitespace from the end of the string, not just the beginning, but the net effect is the same because any whitespace at the end of the string would be ignored anyway.

@ryanofsky yes, that's why my first pushed implementation added `LeftTrimStringView` in 8f4293d892358ce145eb9a099f2e5f256c4d9c73. But got pushback in https://github.com/bitcoin/bitcoin/pull/30436#discussion_r1675658574 and trimming the end of the strin
...

📝 theuni opened a pull request: "depends: Fix CMake-generated `libevent*.pc` files"
(https://github.com/bitcoin/bitcoin/pull/30488)
Broken out of #30454. This is a backport of the merged upstream PR: https://github.com/libevent/libevent/pull/1622.

Note that after #29835 we might end up dropping pkg-config and using the installed CMake files directly, but that depends on whether or not enough distros actually ship those files.

Either way, having fixed up .pc files won't hurt.