💬 theuni commented on pull request "guix: replace GCC unaligned VMOV patch with binutils patch":
(https://github.com/bitcoin/bitcoin/pull/29846#issuecomment-2049597893)
Concept ACK, looks like a strict improvement.

💬 BrandonOdiwuor commented on pull request "test: Handle functional test disk-full error":
(https://github.com/bitcoin/bitcoin/pull/29335#issuecomment-2049602284)
Could you please take another look at this after incorporating the suggested changes

@achow101 @maflcko @kevkevinpal @davidgumberg @epiccurious @tdb3 @itornaza

📝 laanwj opened a pull request: "net: Decrease nMaxIPs when learning from DNS seeds"
(https://github.com/bitcoin/bitcoin/pull/29850)
Limit number of IPs learned from a single DNS seed to 32, to prevent the results from one DNS seed from dominating AddrMan. Note that the number of results from a UDP DNS query is bounded to 33 already, but it is possible for it to use TCP where a larger number of results can be returned.

Closes #16070.

💬 brunoerg commented on pull request "i2p: fix and improve logs":
(https://github.com/bitcoin/bitcoin/pull/29833#discussion_r1560968649)
Sounds good, I will change it.

🚀 glozow merged a pull request: "AcceptMultipleTransactions: Fix workspace not being set as client_maxfeerate failure"
(https://github.com/bitcoin/bitcoin/pull/29735)

⚠️ dergoegge opened an issue: "fuzz: Crash in `rpc` "CHECK_NONFATAL(last - first == 32)" "
(https://github.com/bitcoin/bitcoin/issues/29851)
```
$ echo "ZmluYWxpemVwc2J0XABwc2J0/wEAo6ujYwMDAwMDmAAAANUABQAAY2xlYXJiDAAAAAAAAABgAPX///8A6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACTAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAwoDAwMDAwMDAwMDAwAK8wEDAHFkAAAAAAAAAAAAZQAAAAAAAAAAANzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3NzcAAAAAD8/Pz8/Pz8/Pz8/Pz8/P0Y/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz89Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
...

💬 maflcko commented on pull request "test: Refactor fee calculation to remove satoshi_round function":
(https://github.com/bitcoin/bitcoin/pull/29566#discussion_r1560977607)
```suggestion
rand_fee = satoshi_round(fee_increment * (1.1892 ** random.randint(0, 28)), rounding=ROUND_DOWN)
```

Why the decimal?

💬 maflcko commented on pull request "test: Refactor fee calculation to remove satoshi_round function":
(https://github.com/bitcoin/bitcoin/pull/29566#discussion_r1560978096)
```suggestion
def satoshi_round(amount, *, rounding) -> Decimal:
```

why the default, if the goal is to not use a default?

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1560983729)
added something similar

💬 achow101 commented on issue "fuzz: Crash in `rpc` "CHECK_NONFATAL(last - first == 32)" ":
(https://github.com/bitcoin/bitcoin/issues/29851#issuecomment-2049639006)
The `CHECK_NONFATAL` is in `FromPKBytes`: https://github.com/bitcoin/bitcoin/blob/bdb33ec51986570ea17406c83bad2c955ae23186/src/script/sign.cpp#L298 which is called when getting the miniscript for a script.

This particular script is `173d36c8c9c9c9ffffffffffff0200000000021e1e37373721361818181818181e1e1e1e19000000000000000000b19292929292926b006c9b9b9292`

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#issuecomment-2049639073)
Rebased for #29735 and fixed failure.

💬 achow101 commented on issue "fuzz: Crash in `rpc` "CHECK_NONFATAL(last - first == 32)" ":
(https://github.com/bitcoin/bitcoin/issues/29851#issuecomment-2049640339)
cc @darosior

💬 maflcko commented on issue "fuzz: Crash in `rpc` "CHECK_NONFATAL(last - first == 32)" ":
(https://github.com/bitcoin/bitcoin/issues/29851#issuecomment-2049649573)
I don't think this is a fuzz issue. The RPC is `finalizepsbt` and it should be possible to hit it in `finalizepsbt` RPC as well.

💬 maflcko commented on issue "fuzz, rpc: Internal bug in `finalizepsbt` "CHECK_NONFATAL(last - first == 32)" ":
(https://github.com/bitcoin/bitcoin/issues/29851#issuecomment-2049678227)
Somewhat smaller input for the RPC:

```
$ ./src/bitcoin-cli finalizepsbt cHNidP8BAKOro2MDAwMDA5gAAAbVAAUAAGNsZWFyYgwAAAAAAAAAYAD1////AOgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkwAAAAAAAAAAAAAAYAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAADwAAAAAAAAAAAAAAAAAAAAAAAAMKAwMDAwMDAwMDAwMACvMBAwBxZAAAAAAAAAAAAGUAAAAODgAAAAEBKwL/ZABlcAAAIlEgAwMcHBwDAwAL8wEDJnBmAQAAAAAAAAAAAAAAAAAAgACiFQILCwsAAAAAAAAAAP////8AAACODg4ODg4ODg4ODgAADg5wAAAiUSADAxwcHAMDAAvzAQMmcGYBAAAAAAAAAAAAAAAAAACAAAAAAAAAACSJiYmJyon6AAAAgAAAAAAAAAD
...

💬 TheCharlatan commented on issue "Libbitcoinkernel Project Tracking":
(https://github.com/bitcoin/bitcoin/issues/27587#issuecomment-2049678827)
Updated with initial description of stage 2.

💬 laanwj commented on issue "ci: Lower and unify default stack size":
(https://github.com/bitcoin/bitcoin/issues/29840#issuecomment-2049719550)
FWIW, the command on Linux to set the stack size for a session is `ulimit -s 512`. Where the amount is in KiB. This sets the maximum for the main thread, as well as additional theads created.

> Any reason to not use half of the minimum, to more likely catch edge cases that would happen on unknown operating systems

i'm not sure, yes in principle this makes sense, but also the work that goes in having our code run with say a 256KiB stack seems unnecessary work if the lowest we know used is 5
...

📝 fanquake opened a pull request: "[WIP] build: remove need to test for endianness"
(https://github.com/bitcoin/bitcoin/pull/29852)
We can cherry-pick one commit from upstream leveldb, make the same change in crc32c, and then ultimately drop our build infra for testing endianness.

Not for merging until subtrees are updated etc. Would also mean less code that we need to port to CMake.

👍 BrandonOdiwuor approved a pull request: "test: remove duplicated ban test"
(https://github.com/bitcoin/bitcoin/pull/29688#pullrequestreview-1994237763)
ACK e30e8625bbc42045b8b757a8d7e80c20cc61cebf

Looks good to me

💬 sr-gi commented on pull request "Simplify network-adjusted time warning logic":
(https://github.com/bitcoin/bitcoin/pull/29623#discussion_r1561056518)
I removed it and this seems to run fine, at least in my system

💬 sr-gi commented on pull request "Simplify network-adjusted time warning logic":
(https://github.com/bitcoin/bitcoin/pull/29623#discussion_r1561059463)
Oh, my point was that it could have also been defined as `0s` there too, but I won't insist