📝 hebasto opened a pull request: "refactor: Move sock from util to common"
(https://github.com/bitcoin/bitcoin/pull/27989)
Networking code should not be required by the kernel.

💬 MarcoFalke commented on issue "index: ThreadSanitizer: data race on vptr ":
(https://github.com/bitcoin/bitcoin/issues/27355#issuecomment-1611154752)
This is getting too frequent. I recently encountered this 8 times in a row.

Maybe https://github.com/bitcoin/bitcoin/pull/27988 makes it less frequent for now, by only modifying test code?

👍 fanquake approved a pull request: "guix: Update `python-lief` package to 0.13.2"
(https://github.com/bitcoin/bitcoin/pull/27813#pullrequestreview-1502778035)
ACK 529c92e837b28169b501562efe7b5b7120a2ebbb

💬 MarcoFalke commented on issue "Add maxrelaytxfee":
(https://github.com/bitcoin/bitcoin/issues/27983#issuecomment-1611162386)
> The miner may have a contract with someone who pays the fees for such recycling service off-chain.

If the fee is paid off-chain anyway and doesn't exists within the tx, then this whole feature request doesn't make sense either, because there is no fee to check.

Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base. General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.co
...

🚀 fanquake merged a pull request: "guix: Update `python-lief` package to 0.13.2"
(https://github.com/bitcoin/bitcoin/pull/27813)

💬 stickies-v commented on pull request "httpserver, rest: improving URI validation":
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1242236262)
nit: no need to use a C-style string here I think
```suggestion
const std::string err{"URI parsing failed, it likely contained RFC 3986 invalid characters"};
```

💬 stickies-v commented on pull request "httpserver, rest: improving URI validation":
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1243780038)
Do we need this?

💬 stickies-v commented on pull request "httpserver, rest: improving URI validation":
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1245038873)
I don't think it's great that we're not doing the address-based checks before anything else. Since we're now adding validation into the constructor, how about we do it consistently and do it for all validation, so we can also control what we validate first? I'm still feeling a bit uneasy about coupling the construction of `HTTPRequest` with validation, but if we're doing it we might as well do it more consistently? Curious to hear @vasild's thoughts on this too.

<details>
<summary>git diff</
...

💬 MarcoFalke commented on pull request "init: return error when block index is non-contiguous, fix feature_init.py file perturbation":
(https://github.com/bitcoin/bitcoin/pull/27823#issuecomment-1611186437)
Could rebase for CI?

💬 MarcoFalke commented on pull request "refactor: Continue moving application data from CNode to Peer":
(https://github.com/bitcoin/bitcoin/pull/26621#issuecomment-1611188048)
Needs rebase if still relevant

💬 MarcoFalke commented on pull request "p2p: Drop m_recently_announced_invs bloom filter":
(https://github.com/bitcoin/bitcoin/pull/27675#issuecomment-1611189572)
Could rebase for CI?

💬 MarcoFalke commented on pull request "wallet: Pass through transaction locktime and preset input sequences and scripts to CreateTransaction":
(https://github.com/bitcoin/bitcoin/pull/25273#issuecomment-1611191360)
Needs rebase if still relevant

💬 fanquake commented on pull request "build: produce a .zip for macOS distribution":
(https://github.com/bitcoin/bitcoin/pull/27099#discussion_r1245046746)
Applied.

💬 MarcoFalke commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#issuecomment-1611194968)
CI failure in feature_proxy.py:

https://cirrus-ci.com/task/4981950109188096?logs=ci#L5325

```
node0 stderr net.cpp:1142:113: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'value_type' (aka 'unsigned int')
#0 0x55dbd8047436 in CConnman::DisconnectNodes() src/net.cpp:1142:113
#1 0x55dbd807d233 in CConnman::ThreadSocketHandler() src/net.cpp:1393:9
#2 0x55dbd807d233 in CConnman::Start(CScheduler&, CConnman::Options const&)::$_1::operator()() con
...

💬 vasild commented on pull request "test: remove race in the user-agent reception check":
(https://github.com/bitcoin/bitcoin/pull/27986#issuecomment-1611195730)
`44d71cfd0e...9c46f3ba19`: do https://github.com/bitcoin/bitcoin/pull/27986#discussion_r1244951363

💬 vasild commented on pull request "test: remove race in the user-agent reception check":
(https://github.com/bitcoin/bitcoin/pull/27986#discussion_r1245048980)
Done!

👍 fanquake approved a pull request: "http: update libevent workaround to correct version"
(https://github.com/bitcoin/bitcoin/pull/27949#pullrequestreview-1502843856)
ACK 79d343a642f985801da463b03a0627a59a095238

💬 fanquake commented on pull request "build: no-longer disable WARN_CXXFLAGS when CXXFLAGS is set":
(https://github.com/bitcoin/bitcoin/pull/25972#issuecomment-1611216402)
> though there are others popping up as well ...

I think at least for the (windows) ones coming out of leveldb, we could filter them out, as we do with other warnings there.

💬 MarcoFalke commented on pull request "util: Don't derive secure_allocator from std::allocator":
(https://github.com/bitcoin/bitcoin/pull/27930#issuecomment-1611219016)
> > I'm guessing we should consider doing the same for [`zero_after_free_allocator`](https://github.com/bitcoin/bitcoin/blob/0c84a0e4841f00d931aa7339e9aa8f26eb2f3a61/src/support/allocators/zeroafterfree.h#L15)? Even though it doesn't seem to be affected by this particular issue.
>
> That's probably a good idea, yes.

Looks like this wasn't addressed yet?

🚀 fanquake merged a pull request: "http: update libevent workaround to correct version"
(https://github.com/bitcoin/bitcoin/pull/27949)