🚀 fanquake merged a pull request: "Update leveldb subtree to latest upstream"
(https://github.com/bitcoin/bitcoin/pull/30281)

🤔 vasild reviewed a pull request: "net: Allow -proxy=[::1] on nodes with IPV6 lo only"
(https://github.com/bitcoin/bitcoin/pull/30245#pullrequestreview-2117955181)
Concept ACK on allowing usage of `[::1]` on nodes with IPv6 lo only.

A workaround is to use `-dns` (which will avoid `AI_ADDRCONFIG` but will make it impossible to use hostnames).

I can reproduce the problem on Linux. FreeBSD treats the loopback address as valid, so this problem is non-existent on FreeBSD.

I think there is a merit in this for our use cases of `getaddrinfo()` / `Lookup*()`:

> IPv4 addresses are returned in the list pointed to by res only if the local system has at
...

💬 vasild commented on pull request "net: Allow -proxy=[::1] on nodes with IPV6 lo only":
(https://github.com/bitcoin/bitcoin/pull/30245#discussion_r1639560684)
There is a comment above which has to be removed if this patch makes it as it is:
```
// If we allow lookups of hostnames, use the AI_ADDRCONFIG flag to only
// return addresses whose family we have an address configured for.
```

💬 tdb3 commented on pull request "test: Added test coverage to listsinceblock rpc":
(https://github.com/bitcoin/bitcoin/pull/30195#discussion_r1639697112)
Then it sounds like it would be overkill. If something went wrong then rename would throw and the test would fail.

💬 marcofleon commented on pull request "fuzz: FuzzedSock::Recv() don't lose bytes from MSG_PEEK read":
(https://github.com/bitcoin/bitcoin/pull/30273#discussion_r1639721875)
Why would `m_peek_data` be guaranteed to be empty here? I've tested this with the I2P harness and this assert fails. The `m_peek_data` doesn't get erased, so there's still some random bytes from the previous `Recv` call. The length of the copied data is just whatever was left, which isn't to equal to `len`.

💬 vasild commented on pull request "netbase: extend CreateSock() to support creating arbitrary sockets":
(https://github.com/bitcoin/bitcoin/pull/30202#issuecomment-2167914300)
`5f549c35d9...1245d1388b`: rebase due to (silent) merge conflict

💬 fanquake commented on pull request "macOS: rewrite some docs & swap `mmacosx-version-min` for `mmacos-version-min`":
(https://github.com/bitcoin/bitcoin/pull/30287#issuecomment-2167932945)
Guix Build (aarch64):
```bash
df01ba57dd26dc4ef6c88a9d3538b92d7edfe96edca021b8fc16bb2f146ce438 guix-build-7c298fe0df38/output/aarch64-linux-gnu/SHA256SUMS.part
c19ce42ffe95497f7e4383dd2009413f45bc02e602adf33361eab40ffe1c98ce guix-build-7c298fe0df38/output/aarch64-linux-gnu/bitcoin-7c298fe0df38-aarch64-linux-gnu-debug.tar.gz
73eb0d6887cc9b67a207c486f76a001b38d22d2ffee93f398dd6b01dbf18208f guix-build-7c298fe0df38/output/aarch64-linux-gnu/bitcoin-7c298fe0df38-aarch64-linux-gnu.tar.gz
f1ed10
...

💬 vasild commented on issue "RPC wont bind without an IP address on a non-localhost interface":
(https://github.com/bitcoin/bitcoin/issues/13155#issuecomment-2167939959)
> one of the two default rpcbinds (:: and 0.0.0.0) will fail

Which one? Is it always `::` or always `0.0.0.0` or randomly one or the other? I guess there is some mistake here because the default rpcbinds are `::1` and `127.0.0.1` (not `::` and `0.0.0.0`).

💬 tdb3 commented on pull request "test: Added test coverage to listsinceblock rpc":
(https://github.com/bitcoin/bitcoin/pull/30195#discussion_r1639777921)
Yeah, looks like we'd get a `FileNotFoundError` (induced with the code below, `blk_dat_moved.rename()` throws).

An assert to check that `blk_dat_moved.exists()` before `blk_dat_moved.rename()` would be overkill, so not needed.

```python
# Restoring block file
blk_dat_moved.unlink()
assert not blk_dat_moved.exists()
blk_dat_moved.rename(self.nodes[0].blocks_path / "blk00000.dat")
assert blk_dat.exists()
```

💬 vasild commented on pull request "fuzz: FuzzedSock::Recv() don't lose bytes from MSG_PEEK read":
(https://github.com/bitcoin/bitcoin/pull/30273#discussion_r1639787804)
This assert is too strong! Removed and adjusted the code afterwards to expect that `m_peek_data` may contain some bytes.

Btw, I ran `FUZZ=i2p ./src/test/fuzz/fuzz` for some time and it did not crash, maybe I did not run it long enough.

💬 vasild commented on pull request "fuzz: FuzzedSock::Recv() don't lose bytes from MSG_PEEK read":
(https://github.com/bitcoin/bitcoin/pull/30273#issuecomment-2167983116)
`f4793257cd...4d81b4de33`: rebase and resolve https://github.com/bitcoin/bitcoin/pull/30273#discussion_r1639721875

⚠️ ryanofsky opened an issue: "RFC: Assumeutxo and large forks and reorgs"
(https://github.com/bitcoin/bitcoin/issues/30288)
(tl;dr This is mainly a question about when an assumeutxo snapshot is loaded, if it makes more sense for the original chainstate to continue downloading and attaching blocks in the normal way, or if it should only download and attach blocks leading up to the snapshot block.)

---

It seems unclear how validation code should behave when an assumeutxo snapshot is loaded, and then new headers are received pointing to a forked chain with more proof of work than any known chain including the snap
...

💬 marcofleon commented on pull request "fuzz: FuzzedSock::Recv() don't lose bytes from MSG_PEEK read":
(https://github.com/bitcoin/bitcoin/pull/30273#discussion_r1639813563)
Nice, I'll retest.

> Btw, I ran `FUZZ=i2p ./src/test/fuzz/fuzz` for some time and it did not crash, maybe I did not run it long enough.

Interesting, mine crashed very quickly. Did you run it with the I2P dictionary?

💬 willcl-ark commented on pull request "rename TransactionErrors: MISSING_INPUTS and ALREADY_IN_CHAIN":
(https://github.com/bitcoin/bitcoin/pull/30212#issuecomment-2168023304)
Rebased on master to fix merge conflict.

Added an extra commit to cover `PSBTError::MISSING_INPUTS`.

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#issuecomment-2168024936)
I have split off the optimizations for candidate search to PR #30286, and the merging & postprocessing algorithms to PR #30285, and renamed the PR. It is now focused on just adding the `Linearize()` function, with its eventual interface (including passing in an old linearization, and a randomization seed), but without optimizations beyond that.

💬 willcl-ark commented on pull request "Multiprocess bitcoin":
(https://github.com/bitcoin/bitcoin/pull/10102#issuecomment-2168028486)
Wow, sounds sounds like exactly the bug I hit @ryanofsky, great debugging; sorry I couldn't provide any followup for you sooner.

I'll rebase my `ipc + -ipcconnect` branch on this one, update my `libmultiprocess` installation, and see how it goes from there.

Thanks!

⚠️ sipa opened an issue: "Cluster mempool tracking issue"
(https://github.com/bitcoin/bitcoin/issues/30289)
What to review next:

* #30126

Plan:
* Generic utilities:
* [x] bitset: #30160
* [x] vecdeque: #30161
* Linearization algorithms:
* [ ] cluster linearization: #30126
* [ ] optimized candidate search (follow-up to 30126): #30286
* [ ] merging and postprocessing of linearizations (depends on 30126): #30285
* Cluster mempool implementation:
* [ ] #28676

🤔 glozow reviewed a pull request: "Cluster size 2 package rbf"
(https://github.com/bitcoin/bitcoin/pull/28984#pullrequestreview-2118444350)
reACK 94ed4fbf8e via range-diff

🤔 murchandamus reviewed a pull request: "bumpfee: ignore WALLET_INCREMENTAL_RELAY_FEE when user specifies fee_rate"
(https://github.com/bitcoin/bitcoin/pull/27969#pullrequestreview-2118458522)
ACK f58beabe754363cb7d5b24032fd392654b9514ac

💬 tdb3 commented on pull request "netbase: extend CreateSock() to support creating arbitrary sockets":
(https://github.com/bitcoin/bitcoin/pull/30202#issuecomment-2168123034)
re ACK 1245d1388b003c46092937def7041917aecec8de