💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1566889900)
Yes exactly, this is to bound computation (imagine if somebody sent us 100 fake orphans descended from 1 transaction and we processed them all here). My idea was to do something similar to regular orphan processing, where we have a work queue and limit to 1 item per `ProcessMessages`.

There is no work queue here, though, and we drop the parent as soon as we try 1 (pass or fail). At coredev, we discussed adding a work queue for 1p1c as well. However, since it involves finding a way to store th
...

💬 fanquake commented on issue "ci: feature_proxy failing in MSVC job":
(https://github.com/bitcoin/bitcoin/issues/29090#issuecomment-2058480638)
https://github.com/bitcoin/bitcoin/actions/runs/8690581373/job/23830847391:
```bash
test 2024-04-15T15:06:28.426000Z TestFramework.node3 (DEBUG): Stopping node
test 2024-04-15T15:06:28.426000Z TestFramework (ERROR): Assertion failed
Traceback (most recent call last):
File "D:\a\bitcoin\bitcoin\test\functional\test_framework\test_framework.py", line 565, in start_nodes
node.
...

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1566907728)
Yes I think we could use either `m_recent_rejects_reconsiderable` and `m_recent_rejects` right now to get the same behavior.

I suppose one mild benefit of using `m_recent_rejects_reconsiderable` is that our `m_recent_rejects` bloom filter churns less frequently.

The other benefit is extensibility in the future. In more general ancestor package relay, we could reject a parent+child for being too low feerate, but later accept it as parent+child+grandchild (where the grandchild is very high f
...

💬 maflcko commented on issue "ci: feature_proxy failing in MSVC job":
(https://github.com/bitcoin/bitcoin/issues/29090#issuecomment-2058490446)
Maybe related to the races seen in https://github.com/bitcoin/bitcoin/issues/29871#issuecomment-2057480445 ?

📝 fanquake opened a pull request: "doc: archive 27.0 release notes"
(https://github.com/bitcoin/bitcoin/pull/29886)

💬 laanwj commented on pull request "guix: replace GCC unaligned VMOV patch with binutils patch":
(https://github.com/bitcoin/bitcoin/pull/29846#issuecomment-2058516921)
- I get the same output (for win32) as @hebasto
- I've checked the resulting binaries for instructions that enforce aligned memory accesses, and didn't find any dangerous ones

Code review ACK a0dc2ebcda9e33aa5320221cd4ea371f84d221fd

🤔 glozow reviewed a pull request: "fuzz: explicitly cap the vsize of RBFs for diagram checks"
(https://github.com/bitcoin/bitcoin/pull/29879#pullrequestreview-2002964571)
Approach of breaking when adding another tx would overflow seems fine to me. Did you forget to squash?

⚠️ OkSang88 opened an issue: "Oksang"
(https://github.com/bitcoin/bitcoin/issues/29887)
https://github.com/bitcoin/bitcoin/blob/71b63195b30b2fa0dff20ebb262ce7566dd5d673/src%2Fnet_processing.cpp

✅ fanquake closed an issue: "Oksang"
(https://github.com/bitcoin/bitcoin/issues/29887)

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

💬 maflcko commented on pull request "test: Add missing Assert(mock_time_in >= 0s) to SetMockTime":
(https://github.com/bitcoin/bitcoin/pull/29872#discussion_r1566955575)
Both can be used. In this context they are exactly the same.

💬 fanquake commented on issue "Release schedule for 27.0":
(https://github.com/bitcoin/bitcoin/issues/29028#issuecomment-2058539546)
v27.0 has now been tagged: https://github.com/bitcoin/bitcoin/releases/tag/v27.0.

✅ fanquake closed an issue: "Release schedule for 27.0"
(https://github.com/bitcoin/bitcoin/issues/29028)

💬 laanwj commented on pull request "doc: archive 27.0 release notes":
(https://github.com/bitcoin/bitcoin/pull/29886#issuecomment-2058543218)
ACK c08754971d207bd2b60ba9c4faf34396a97bbc26
No output for
```
git diff c08754971d207bd2b60ba9c4faf34396a97bbc26:doc/release-notes/release-notes-27.0.md v27.0:doc/release-notes.md
```

📝 fanquake opened a pull request: "[27.x] Backports"
(https://github.com/bitcoin/bitcoin/pull/29888)
Backports:
* https://github.com/bitcoin/bitcoin/pull/29691
* https://github.com/bitcoin/bitcoin/pull/29747
* https://github.com/bitcoin/bitcoin/pull/29856
* https://github.com/bitcoin/bitcoin/pull/29869

💬 maflcko commented on pull request "guix: use GCC 13 to builds releases":
(https://github.com/bitcoin/bitcoin/pull/29881#issuecomment-2058544837)
For reference, the previous bump was e1ce5b8ae9124717c00dca71a5c5b43a7f5ad177, which is in master only and not yet in a release branch.

💬 hebasto commented on issue "`test/streams_tests.cpp` fails to compile on SunOS / illumos":
(https://github.com/bitcoin/bitcoin/issues/29884#issuecomment-2058578466)
> However, my preference would be to completely avoid `signed char` and just use `int8_t` in the serialization code. That is, fix the test to use `int8_t`.

I lean to agree, considering that `signed char` is used in tests only.

👍 hebasto approved a pull request: "guix: remove `gcc-toolchain static` from Windows build"
(https://github.com/bitcoin/bitcoin/pull/29828#pullrequestreview-2003064639)
ACK 05da2460db895374ea1fd89e4b8b4b73689f8faf,

My Guix build:
```
450c0c4f45f9cb7ed7fc2ef6e7557b6a23004b82c951399da3b7635e8451a076 guix-build-05da2460db89/output/dist-archive/bitcoin-05da2460db89.tar.gz
5df68ab18636090c387bc90297356d0e148b02931d3a99c0f6d33cd268aa072b guix-build-05da2460db89/output/x86_64-w64-mingw32/SHA256SUMS.part
13e979f60d9296aa11081fbbb360404da9fbb797bb4663ed2d1189d800659b4f guix-build-05da2460db89/output/x86_64-w64-mingw32/bitcoin-05da2460db89-win64-debug.zip
d1cc
...

💬 maflcko commented on issue "`test/streams_tests.cpp` fails to compile on SunOS / illumos":
(https://github.com/bitcoin/bitcoin/issues/29884#issuecomment-2058600361)
Happy to review a pull, if someone creates one.

💬 hebasto commented on pull request "util: remove unused cpp-subprocess options":
(https://github.com/bitcoin/bitcoin/pull/29865#issuecomment-2058610414)
> FWIW I think it's a valid choice to remove what we're not using and re-introduce it when we do, the code is out there there's little point in keeping unused code in the repository.

I agree.