👍 hebasto approved a pull request: "ci: move ASan job to GitHub Actions from Cirrus CI"
(https://github.com/bitcoin/bitcoin/pull/30193#pullrequestreview-2122625080)
ACK 9eea51d9058ad638861aa4b94c1c6e71caeb8765.

💬 Sjors commented on pull request "Introduce Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30200#issuecomment-2173170961)
Oops, `'TestBlockValidity failed: bad-txns-inputs-missingorspent'`...

💬 glozow commented on pull request "test: Add Compact Block Encoding test `ReceiveWithExtraTransactions` covering non-empty `extra_txn`":
(https://github.com/bitcoin/bitcoin/pull/30237#discussion_r1642697581)
really not a fan of these magic numbers, would prefer `rand_ctx.rand64()`

💬 glozow commented on pull request "test: Add Compact Block Encoding test `ReceiveWithExtraTransactions` covering non-empty `extra_txn`":
(https://github.com/bitcoin/bitcoin/pull/30237#discussion_r1642694693)
What about always requiring a `FastRandomContext` and getting a `rand64()` for the nonce that way? peerman would pass in its own `m_rng. Making the rng a param feels preferable to adding a test-only version of the ctor.

💬 rkrux commented on pull request "test: expand LimitOrphan and EraseForPeer coverage":
(https://github.com/bitcoin/bitcoin/pull/30082#discussion_r1642703544)
Can you please share how exactly is this being done `check timeout logic` here?

I see from the `AddTx` code that if the tx size is more than the standard weight, then it will not be added in the orphanage. Is the timeout logic here that the size of this tx is less than the standard weight and therefore it's inserted?

👍 rkrux approved a pull request: "test: expand LimitOrphan and EraseForPeer coverage"
(https://github.com/bitcoin/bitcoin/pull/30082#pullrequestreview-2122597073)
tACK [eaf4de0](https://github.com/bitcoin/bitcoin/pull/30082/commits/eaf4de028de8fa13227b6089785889f1c6c15b4d)

Make successful, so are all the unit tests and functional test. Asked couple questions for my understanding.

💬 rkrux commented on pull request "test: expand LimitOrphan and EraseForPeer coverage":
(https://github.com/bitcoin/bitcoin/pull/30082#discussion_r1642629997)
Nit: Tying it to `expected_num_orphans` like `expected_num_orphans -3` in the `LimitOrphans` call would make it more explicit (but not necessarily in the `BOOST_CHECK`), otherwise it made me wonder whether the current count is more than 40 or not.

💬 rkrux commented on pull request "test: expand LimitOrphan and EraseForPeer coverage":
(https://github.com/bitcoin/bitcoin/pull/30082#discussion_r1642703875)
+1 on moving these to the header file!

💬 rkrux commented on pull request "test: expand LimitOrphan and EraseForPeer coverage":
(https://github.com/bitcoin/bitcoin/pull/30082#discussion_r1642625331)
Took me a while to understand why only the first 3 peers announced 2 txs each, but it's infact the first 10 peers as per the above 3 loops that announced 2 txs each - the third tx for each of them being ignored because of its large size.

💬 glozow commented on pull request "test: expand LimitOrphan and EraseForPeer coverage":
(https://github.com/bitcoin/bitcoin/pull/30082#discussion_r1642717383)
orphans are expired in the first part of `LimitOrphans`

✅ Sjors closed an issue: "Add bitcoind and bitcoin-cli to macOS release"
(https://github.com/bitcoin/bitcoin/issues/30262)

💬 Sjors commented on issue "Add bitcoind and bitcoin-cli to macOS release":
(https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2173236827)
> the `bitcoin-cli` utility is included in the macOS tar

Oh, it's in the tar but not in the zip. That's confusing, but a matter of improving documentation.

In that case I'll close this and will defer to #29749 (assuming we also sign x86 binaries).

💬 Sjors commented on issue "release: ship codesigned MacOS arm64 binaries":
(https://github.com/bitcoin/bitcoin/issues/29749#issuecomment-2173242397)
If we code-sign in the tar file, let's also sign them for x86. Otherwise the user has to right-click -> option & open them once.

💬 brunoerg commented on pull request "test: write functional test results to csv":
(https://github.com/bitcoin/bitcoin/pull/30291#discussion_r1642762119)
It creates the file if it doesn't exist, right?

💬 tdb3 commented on pull request "test: write functional test results to csv":
(https://github.com/bitcoin/bitcoin/pull/30291#discussion_r1642765022)
Yes, and overwrites the existing file if it does

💬 maflcko commented on pull request "test: write functional test results to csv":
(https://github.com/bitcoin/bitcoin/pull/30291#discussion_r1642765478)
See https://docs.python.org/3.8/library/functions.html#open

💬 brunoerg commented on pull request "test: write functional test results to csv":
(https://github.com/bitcoin/bitcoin/pull/30291#discussion_r1642768763)
Cool. Thanks.

💬 tdb3 commented on pull request "test: write functional test results to csv":
(https://github.com/bitcoin/bitcoin/pull/30291#discussion_r1642784926)
Yeah, at first glance showing `ALL,Failed` is not ideal, but in this case the CSV output is matching the approach taken by stdout printing, so it seems appropriate for now.

Since the scope of this PR is to focus on adding the CSV output capability, I'll leave it as-is for now. Perhaps a future discussion for how `ALL` is treated in both the stdout printing and the CSV could be had?

```
TEST | STATUS | DURATION

feature_blocksdir.py | ✓ Passed | 1 s
feature_conf
...

🤔 brunoerg reviewed a pull request: "test: write functional test results to csv"
(https://github.com/bitcoin/bitcoin/pull/30291#pullrequestreview-2122861389)
ACK ad06e68399da71c615db0dbf5304d0cd46bc1f40

<details>
<summary>csv output</summary>
<br>
test,status,duration(seconds)
example_test.py,Passed,4
feature_abortnode.py,Passed,2
feature_addrman.py,Passed,5
feature_anchors.py,Passed,4
feature_asmap.py,Passed,8
feature_assumeutxo.py,Passed,45
feature_assumevalid.py,Passed,4
feature_bip68_sequence.py,Passed,7
feature_block.py,Passed,45
feature_blocksdir.py,Passed,1
feature_cltv.py,Passed,2
feature_coinstatsindex.py,Passed,7
feature_
...

💬 tdb3 commented on pull request "test: write functional test results to csv":
(https://github.com/bitcoin/bitcoin/pull/30291#discussion_r1642788308)
Good thought. Since the approach is to allow the user to specify the filename/extension as they see fit (rather than force a particular extension), this seems ok as-is. If others feel that forcing the extension `.csv` would be more ideal, then will keep this in mind.