💬 ryanofsky commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1962322579)
> Sure, while calling `waitNext`, but after it returns, isn't it the case that the current `BlockTemplate` becomes useless?

It's not useless if submitSolution can still be called. This should be the case as long as the tip hasn't changed and miners are still mining with this template. If the tip has changed or miners are no longer mining with this template, the client can discard it.

💬 achow101 commented on pull request "guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries":
(https://github.com/bitcoin/bitcoin/pull/31407#issuecomment-2669709312)
> I'm having an issue codesigning:

Fixed in https://github.com/achow101/signapple/commit/0c087854fd2822ab63512cbfa3b55706239b27c2. Note that this only affects code signers so I will hold off on updating signapple in guix for now.

💬 sipa commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1962357905)
Oh, great, that answers my question.

💬 pinheadmz commented on pull request "guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries":
(https://github.com/bitcoin/bitcoin/pull/31407#issuecomment-2669745876)
Updated detached codesigs:

https://github.com/pinheadmz/bitcoin-detached-sigs/tree/achow101-macos-notarization-e181bda


## all.SHA256SUMS
```

09160970e038df29d6c2ae3da69adf77ac496f65e114e3bbb56272465b9c230a bitcoin-e181bda061ca-aarch64-linux-gnu-debug.tar.gz
f94c5f7734858dfc77717849934112cceef44a80b06fb1c21f41a78733092c6a bitcoin-e181bda061ca-aarch64-linux-gnu.tar.gz
44dcd5864d1c529c431f5e80966d4efe74a14330182460ac945852bc67ad7e84 bitcoin-e181bda061ca-arm-linux-gnueabihf-debug.ta
...

💬 pinheadmz commented on pull request "guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries":
(https://github.com/bitcoin/bitcoin/pull/31407#issuecomment-2669764500)
Reviewers can also try downloading these signed binaries to see what their browsers think ... ?

https://www.dropbox.com/scl/fo/zpz3gjtzz66gtejnqkrfs/AIWbAU_Y3pY_O93cy9Q6vds?rlkey=oucgyfg4sm5p9pa2c0gum2kxa&dl=0

🚀 fanquake merged a pull request: "cmake: Exclude generated sources from translation"
(https://github.com/bitcoin/bitcoin/pull/31899)

📝 fanquake locked a pull request: "."
(https://github.com/bitcoin/bitcoin/pull/31909)
Currently testing the PR assignment. No issue ID yet😊

:lock: fanquake locked an issue: "."
(https://github.com/bitcoin/bitcoin/issues/31876)

💬 TheCharlatan commented on pull request "qa: clarify and document assumeutxo tests":
(https://github.com/bitcoin/bitcoin/pull/31907#issuecomment-2669777720)
The third paragraph in the first commit messages mentions commits that don't exist here. I'm guessing that is a reference to the original patchset you developed this with?

📝 darosior opened a pull request: "qa: fix an off-by-one in utxo snapshot fuzz target and sanity check its snapshot data"
(https://github.com/bitcoin/bitcoin/pull/31910)
The assumeutxo data for the fuzz target could change and invalidate the hash silently, preventing the fuzz target from reaching some code paths. Fix this by introducing a unit test which would break if the snapshot data the fuzz target relies on were to change.

In implementing this i noticed the height used for coins in the fuzz target is actually off-by-one (as if the first block in the created chain was the genesis but it's block `1`), so fix that too.

💬 darosior commented on pull request "qa: fix an off-by-one in utxo snapshot fuzz target and sanity check its snapshot data":
(https://github.com/bitcoin/bitcoin/pull/31910#issuecomment-2669783139)
cc @mzumsande. This was also suggested by @ryanofsky in https://github.com/bitcoin/bitcoin/pull/30329#discussion_r1671160670.

👍 ismaelsadeeq approved a pull request: "Add waitNext() to BlockTemplate interface"
(https://github.com/bitcoin/bitcoin/pull/31283#pullrequestreview-2627579088)
Code review ACK cadbd4137d84b71be26effd6a2ae177d5031345e

💬 ismaelsadeeq commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1962136020)
We run both checks in each tick.

💬 davidgumberg commented on pull request "guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries":
(https://github.com/bitcoin/bitcoin/pull/31407#issuecomment-2669794942)
## unsigned
[bitcoin-e181bda061ca-arm64-apple-darwin-unsigned.zip](https://github.com/user-attachments/files/18875760/bitcoin-e181bda061ca-arm64-apple-darwin-unsigned.zip)
[bitcoin-e181bda061ca-x86_64-apple-darwin-unsigned.zip](https://github.com/user-attachments/files/18875759/bitcoin-e181bda061ca-x86_64-apple-darwin-unsigned.zip)


## codesigned
[bitcoin-e181bda061ca-arm64-apple-darwin.zip](https://github.com/user-attachments/files/18875745/bitcoin-e181bda061ca-arm64-apple-darwin.zip)
[
...

💬 darosior commented on issue "Gracefully handle dropped UPnP support ":
(https://github.com/bitcoin-core/gui/issues/843#issuecomment-2669805584)
> Will take a look.

@laanwj did you get a chance to look into this? Else i guess it falls on me to take care of this before deadline..

💬 darosior commented on pull request "qa: clarify and document assumeutxo tests":
(https://github.com/bitcoin/bitcoin/pull/31907#issuecomment-2669809538)
Ugh yes it is indeed. Will fix.

💬 achow101 commented on pull request "guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries":
(https://github.com/bitcoin/bitcoin/pull/31407#issuecomment-2669848285)
```
d043dbd79662ee324ab809061405c71ecb4dbd9c1100ea7fcfc72bfb8e775a20 guix-build-e181bda061ca/output/aarch64-linux-gnu/SHA256SUMS.part
09160970e038df29d6c2ae3da69adf77ac496f65e114e3bbb56272465b9c230a guix-build-e181bda061ca/output/aarch64-linux-gnu/bitcoin-e181bda061ca-aarch64-linux-gnu-debug.tar.gz
f94c5f7734858dfc77717849934112cceef44a80b06fb1c21f41a78733092c6a guix-build-e181bda061ca/output/aarch64-linux-gnu/bitcoin-e181bda061ca-aarch64-linux-gnu.tar.gz
a28ae11a5585624e18c9c85f5c4a0fb09
...

💬 maflcko commented on pull request "Revert merge of PR #31826":
(https://github.com/bitcoin/bitcoin/pull/31908#issuecomment-2669892943)
> > Ostensibly we do though, as the code is part of the aarch64 platform which we do have CI for. However, it appears that our ARM CI does not have HWCAP2_RNG, but it could if we switched to using AWS Graviton instances.
>
> Having the ARM64 RNG code in the first place makes sense, and we could test this on Graviton instances.

I don't think they have a 32-bit mode, so we'd have to drop that:

https://github.com/bitcoin/bitcoin/blob/e606c577cb257d0927ca6ea939aab06cf0639aad/ci/test/00_setu
...

🤔 ryanofsky reviewed a pull request: "scripted-diff: Type-safe settings retrieval"
(https://github.com/bitcoin/bitcoin/pull/31260#pullrequestreview-2628216843)
Updated 215f55567b2af1677f9971a0ca03e86d09fbb726 -> 31fe4c6f994697dd027be8064c27dde800ebcb65 ([`pr/scripty.15`](https://github.com/ryanofsky/bitcoin/commits/pr/scripty.15) -> [`pr/scripty.16`](https://github.com/ryanofsky/bitcoin/commits/pr/scripty.16), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/scripty.15..pr/scripty.16)) changing HelpFn arguments as suggested to make them more extensible and support querying default values

💬 ryanofsky commented on pull request "scripted-diff: Type-safe settings retrieval":
(https://github.com/bitcoin/bitcoin/pull/31260#discussion_r1962529752)
re: https://github.com/bitcoin/bitcoin/pull/31260#discussion_r1959711651

> This means that the `HelpFn` would (ideally) have a way to query the default value as well.

This is now implemented in the latest push.