👍 dergoegge approved a pull request: "fuzz: Deglobalize signature cache in sigcache test"
(https://github.com/bitcoin/bitcoin/pull/30447#pullrequestreview-2188536419)
utACK fae0db0360466aed536f4ce96d357cf579100080

📝 Sjors opened a pull request: "ci: skip Github CI on branch pushes for forks"
(https://github.com/bitcoin/bitcoin/pull/30487)
Similar to e9bfbb5414ab14ca14d8edcfdf77f28c9ed67c33 for Cirrus, but not opt-in, because Github CI lacks custom variables.

This was was originally part of #29274, but left out in order for that PR to be entirely about Cirrus CI. It was suggested as a followup in https://github.com/bitcoin/bitcoin/pull/29274#issuecomment-2214759087.

I've been using this commit in #29432 (on this repo) and https://github.com/Sjors/bitcoin/pull/48 (my fork).

💬 Sjors commented on pull request "Fix issues with CI on forks":
(https://github.com/bitcoin/bitcoin/pull/29274#issuecomment-2239482323)
Picked @ryanofsky's first suggestion into #30487.

So far ARM jobs have not been a source of headaches on my own fork (only TSAN and MSAN are atm).

💬 t-bast 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-2239486786)
> FYI anchor channels having two anchor outputs is actually a design oversight. Only one anchor output is needed in almost all cases: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004246.html

Right, we discussed that in this thread, but the responses to that thread show that it's not a design oversight, using a single anchor has drawbacks as well. But it's quite off-topic for this PR though.

👋 fanquake's pull request is ready for review: "guix: bump time-machine to 1aa8dfaeec3c6e4e587aadf7440246f7c5c04b9f"
(https://github.com/bitcoin/bitcoin/pull/30452)

💬 fanquake commented on pull request "guix: bump time-machine to 1aa8dfaeec3c6e4e587aadf7440246f7c5c04b9f":
(https://github.com/bitcoin/bitcoin/pull/30452#issuecomment-2239495817)
Fixed the cross-arch non-determinism by patching the store patch out of winpthreads.

💬 t-bast commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#issuecomment-2239497457)
> Forcing them to be put towards the keyless ephemeral output potentially creates incentive problems around stealing that output.

Not really, because it will always be the miner that will steal it (since they can replace any spend by a spend to themselves). As was detailed in the delving post you're referencing, putting HTLC values in the keyless ephemeral output ensures that it's spent and doesn't pollute the utxo set, while putting the fees directly to the commitment transaction doesn't in
...

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684577252)
Not a typo. There can be multiple distinct optimal linearizations; we just check for optimality, not that it is actually identical to the exhaustive solutions.

💬 petertodd commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#issuecomment-2239528767)
Stealing an ephemeral anchor output can only be done in certain conditions, at specific ranges of values. It is not always profitable due to overheads, and you can reduce those overheads by doing complex things.

The game theory is much simpler if the dust HTLC funds go directly to fees.

On July 19, 2024 5:50:49 PM GMT+02:00, Bastien Teinturier ***@***.***> wrote:
>> Forcing them to be put towards the keyless ephemeral output potentially creates incentive problems around stealing that output.

...

💬 petertodd 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-2239532688)
I responded to all those points, as you can see in the thread. Anyway, it's clearly an on topic FYI as it impacts how useful this feature actually is. But no need to discuss it further than the FYI link.

On July 19, 2024 5:43:53 PM GMT+02:00, Bastien Teinturier ***@***.***> wrote:
>> FYI anchor channels having two anchor outputs is actually a design oversight. Only one anchor output is needed in almost all cases: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004246.htm
...

💬 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
...