💬 stickies-v commented on pull request "blockstorage: do not flush block to disk if it is already there":
(https://github.com/bitcoin/bitcoin/pull/27039#discussion_r1171578190)
nit: unintuitive name, it's not a block
```suggestion
FlatFilePos last_block_pos;
```

💬 stickies-v commented on pull request "blockstorage: do not flush block to disk if it is already there":
(https://github.com/bitcoin/bitcoin/pull/27039#discussion_r1164077010)
Is this a reliable way to check for a FAT filesystem? WIN32 could also use other filesystems I think (e.g. NTFS), and likewise - FAT could still be used without WIN32, I think?

I think I agree with [LarryRuane](https://github.com/bitcoin/bitcoin/pull/27039/files#r1122400769) that comparing files is probably more robust and portable, which I think is reasonable with these small file sizes? But perhaps you've found this is too much of a performance hit?

You could also check the filesystem di
...

💬 glozow commented on pull request "rpc: Add importmempool RPC":
(https://github.com/bitcoin/bitcoin/pull/27460#discussion_r1172766671)
Sorry for being pedantic, yes please. Something like "fee delta priority from the file is added on top of any priority already present in the mempool"

💬 achow101 commented on pull request "p2p: update hardcoded mainnet seeds for 25.x":
(https://github.com/bitcoin/bitcoin/pull/27488#issuecomment-1516558561)
ACK 31b1798d2c3fa3c479eb2d1896240e0b7fad600b

I think we should reconsider how we do the tor, i2p, and cjdns seeds for the next release.

💬 mzumsande commented on pull request "p2p: update hardcoded mainnet seeds for 25.x":
(https://github.com/bitcoin/bitcoin/pull/27488#issuecomment-1516561832)
reACK 31b1798d2c3fa3c479eb2d1896240e0b7fad600b

After running the (now bugfixed) script based on sipa's seeder data locally, I have fewer differences compared to my ACK from yesterday for IPv4/6.

💬 MarcoFalke commented on pull request "blockstorage: do not flush block to disk if it is already there":
(https://github.com/bitcoin/bitcoin/pull/27039#issuecomment-1516564787)
.test.ignore.

💬 glozow commented on pull request "mempool / rpc: add getprioritisationmap, delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/27501#discussion_r1172792521)
Done

💬 glozow commented on pull request "mempool / rpc: add getprioritisationmap, delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/27501#discussion_r1172799613)
Fixed

💬 ariard commented on issue "Document CoreDev organization":
(https://github.com/bitcoin/bitcoin/issues/27497#issuecomment-1516584111)
@fanquake Without a desire to make more noise here, just to clarify your position you think it's not a discussion we should have as a project or it's more the unclarity of the outcome ?

For the place, of course there is https://github.com/coredev-tech/coredev-tech.github.io which might a better place. Just no contributors are looking on this repository.

For the outcome, we could have a `COREDEV.md`, detailing the process:
- reach out to past organisers to check if there is someone already
...

💬 ajtowns commented on pull request "Allow configuring target block time for a signet":
(https://github.com/bitcoin/bitcoin/pull/27446#issuecomment-1516588784)
> @ajtowns I don't think I am properly communicating my usecase correctly,

When I asked what [you were trying to solve](https://github.com/bitcoin/bitcoin/pull/27446#issuecomment-1502605806), you [didn't respond](https://github.com/bitcoin/bitcoin/pull/27446#issuecomment-1503777153) to that question at all...

The example listed on [the mutinynet blog entry](https://blog.mutinywallet.com/mutinynet/) is "The most obvious win here is we can have a channel "confirmed" much more quickly." -- b
...

⚠️ dergoegge opened an issue: "meta: Isolated fuzzing of net processing"
(https://github.com/bitcoin/bitcoin/issues/27502)
Efficient isolated fuzzing of our message processing code (net processing) would be very valuable. However, to make that deterministic, fast and fuzzer friendly it appears that extensive refactoring is required. There are three main blockers: module separation (net/net processing/validation split), determinism, performance.

I am gonna use this issue to track and motivate the work that needs to be done. It would be great if we can achieve the same outcome with less refactoring but I don't see
...

💬 hebasto commented on pull request "depends: reuse _config_opts for CMake options":
(https://github.com/bitcoin/bitcoin/pull/27496#issuecomment-1516598966)
My Guix builds:
```
45d96de0248ec8b604cc5c980f1abbc780862d497f195a795c6088087d646c73 guix-build-63c0c4ff10b2/output/aarch64-linux-gnu/SHA256SUMS.part
ebdd087cbb45f1fa337b717c0d7bd53c8b7d0bc78d4e9693de2430a1ab9e03d9 guix-build-63c0c4ff10b2/output/aarch64-linux-gnu/bitcoin-63c0c4ff10b2-aarch64-linux-gnu-debug.tar.gz
e09206e6a70068036ea52731e0f8122665525a132e85f2798662ff9d7644dd8b guix-build-63c0c4ff10b2/output/aarch64-linux-gnu/bitcoin-63c0c4ff10b2-aarch64-linux-gnu.tar.gz
20e71234d2e90386
...

💬 dergoegge commented on pull request "mempool / rpc: add getprioritisationmap, delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/27501#issuecomment-1516600484)
Maybe add a short description for what `mapDeltas` is to the PR description under "motivation / background"? afaict `mapDeltas` also doesn't have any code documentation.

💬 ajtowns commented on pull request "Allow configuring target block time for a signet":
(https://github.com/bitcoin/bitcoin/pull/27446#issuecomment-1516600820)
> If we want to allow for more configurable signet consensus rules, then I think we need to do it in a more robust way

I think the easy, mostly backwards compatible way of doing this would just be to have the signetchallenge contain the data directly, eg making it be the script `OP_RETURN PUSHDATA<params> PUSHDATA<actual challenge>`. Then you're still just passing around a hex "challenge" string that completely defines the signet consensus behaviour, and will get different magic when there a
...

👍 MarcoFalke approved a pull request: "mempool / rpc: add getprioritisationmap, delete a mapDeltas entry when delta==0"
(https://github.com/bitcoin/bitcoin/pull/27501#pullrequestreview-1394327087)
lgtm ACK. Left two nits.

💬 MarcoFalke commented on pull request "mempool / rpc: add getprioritisationmap, delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/27501#discussion_r1172806194)
clang-format new code (only if you retouch)

💬 MarcoFalke commented on pull request "mempool / rpc: add getprioritisationmap, delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/27501#discussion_r1172814908)
```suggestion
result.try_emplace(txid, delta, in_mempool);
```

nit: `try_emplace` should avoid duplicate and unneeded (move) constructor calls? Also, it is shorter.

💬 achow101 commented on pull request "wallet: improve IBD sync time by skipping block scanning prior birth time":
(https://github.com/bitcoin/bitcoin/pull/27469#discussion_r1172817209)
> Hmm, wasn't the timestamp window created to extend the grace period enough so we can use the block time directly?.

AFAIK it exists for accepting blocks with future timestamps, and we only use it in the wallet because it's convenient.

But my comment isn't really about the accuracy of the timestamp, but rather about the possibility of skipping a block after we have already started scanning. A block's timestamp can be before its parent. The code as written would let us skip scanning a block
...

💬 fanquake commented on issue "Document CoreDev organization":
(https://github.com/bitcoin/bitcoin/issues/27497#issuecomment-1516608574)
> Without a desire to make more noise here, just to clarify your position

There's no problem with having any discussion about how to organize a developer meetup, I just don't think having it in this issue tracker is the right place, or going to be particularly productive.

💬 MarcoFalke commented on issue "meta: Isolated fuzzing of net processing":
(https://github.com/bitcoin/bitcoin/issues/27502#issuecomment-1516620806)
I don't think that #https://github.com/bitcoin/bitcoin/pull/27499 is going to increase fuzz performance. Parsing should currently only be done at the beginning once, before any fuzzing happens. Even if parsing were in the hot loop, it probably wouldn't be noticeable. And if you want to construct a PeerManager for each fuzzing iteration, it seems too slow either way, unless you find a way to skip the memory allocations (as you said yourself).

💬 ariard commented on issue "Document CoreDev organization":
(https://github.com/bitcoin/bitcoin/issues/27497#issuecomment-1516640923)
Okay, I'll propose a document draft during the coming future to make things more productive. Sorry for the issue tracker usage, unclear where "meta-discussions" should go between the mailing list and here.