📝 sbhuiyan20 opened a pull request: "Create Genarsative Ai"
(https://github.com/bitcoin/bitcoin/pull/27713)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

✅ fanquake closed a pull request: "Create Genarsative Ai"
(https://github.com/bitcoin/bitcoin/pull/27713)

📝 fanquake locked a pull request: "Create Genarsative Ai"
(https://github.com/bitcoin/bitcoin/pull/27713)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

💬 hebasto commented on pull request "ci: Update "Win64 native" task":
(https://github.com/bitcoin/bitcoin/pull/26891#issuecomment-1556187285)
FWIW, the recent [ccache 4.8.1](https://ccache.dev/releasenotes.html#_ccache_4_8_1) seems broken. Note the cacheable calls ratio:
```
Cacheable calls: 264 / 617 (42.79%)
Hits: 264 / 264 (100.0%)
Direct: 264 / 264 (100.0%)
Preprocessed: 0 / 264 ( 0.00%)
Misses: 0 / 264 ( 0.00%)
Uncacheable calls: 353 / 617 (57.21%)
Local storage:
Cache size (GB): 0.2 / 0.2 (99.87%)
Hits: 264 / 264 (100.0%)
Misses: 0 / 264 ( 0.00%
...

💬 ddykeman1 commented on issue "crash on macOS 12.6.5":
(https://github.com/bitcoin-core/gui/issues/731#issuecomment-1556206697)
Not sure how to do that at the moment

💬 furszy commented on pull request "index: improve initialization and pruning violation check":
(https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1199788121)
yeah thx, this is a remanent from a previous version.

💬 furszy commented on pull request "index: improve initialization and pruning violation check":
(https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1199796712)
> Could the commit message clarify if any behavior is changing here? Would be good to label it a refactoring and say it does not change behavior if nothing is changing, and say what is changing otherwise.

yeah sure. https://github.com/bitcoin/bitcoin/commit/704c9e4cf67468708db655226a78489b92ef0523 introduces no behavior change.

> Also, it seems like new code that is added here just gets moved / deleted later in the PR in the last commit "index: verify blocks data existence only once" (http
...

💬 TheCharlatan commented on pull request "Allow configuring target block time for a signet":
(https://github.com/bitcoin/bitcoin/pull/27446#issuecomment-1556263037)
Approach NACK.

I get this - wasting time waiting for confirmations is more than annoying. Its effect usually lingers, because you loose context in the meantime and it slows down development in your entire organization. However, I also think supporting options that might lead to clients running disagreeing consensus rules on the same network is dangerous and might annoy developers in fresh ways. I would support the approach laid out by ajtowns in [this comment](https://github.com/bitcoin/bitc
...

👋 hebasto's pull request is ready for review: "ci, iwyu: Update mappings"
(https://github.com/bitcoin/bitcoin/pull/27710)

💬 benthecarman commented on pull request "Allow configuring target block time for a signet":
(https://github.com/bitcoin/bitcoin/pull/27446#issuecomment-1556271482)
> Approach NACK.
>
> I get this - wasting time waiting for confirmations is more than annoying. Its effect usually lingers, because you loose context in the meantime and it slows down development in your entire organization. However, I also think supporting options that might lead to clients running disagreeing consensus rules on the same network is dangerous and might annoy developers in fresh ways. I would support the approach laid out by ajtowns in [this comment](https://github.com/bitcoin
...

💬 mzumsande commented on pull request "index: improve initialization and pruning violation check":
(https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1199824807)
> Do you think the the main benefit of this commit is cleaner code, and the worse error detection a side effect? Or are there other benefits to this commit?

I think one minor downside could be that the indexes will be available a few minutes later because loadblk doesn't only do reindexing etc., it also loads the mempool - this could take several minutes depending on mempool size and there isn't really a reason why the indexes shouldn't be available before that has finished. This is already t
...

🤔 mzumsande reviewed a pull request: "Parallel compact block downloads, take 3"
(https://github.com/bitcoin/bitcoin/pull/27626#pullrequestreview-1435468460)
Concept ACK, code looks good on first walkthrough.

I want to run this code with some additional logging for a day or two before acking.

In particular, I wonder if the fact that we'll now try additional peers will lead to redundancies / increased traffic under non-adversarial conditions where there's no staller but delivering the block just needs some time - especially when blocks contain a large number of txns that weren't in our mempool, or on slower networks like Tor. Did you consider th
...

💬 mzumsande commented on pull request "Parallel compact block downloads, take 3":
(https://github.com/bitcoin/bitcoin/pull/27626#discussion_r1199689963)
missing `assert` here

💬 mzumsande commented on pull request "Parallel compact block downloads, take 3":
(https://github.com/bitcoin/bitcoin/pull/27626#discussion_r1199822582)
nit: `already_in_flight` could be just a bool here

🤔 mzumsande reviewed a pull request: "rpc: Add importmempool RPC"
(https://github.com/bitcoin/bitcoin/pull/27460#pullrequestreview-1435717252)
Should the rpc be executable before the mempool load from `ThreadImport` has finished? I tried importing another mempool before the mempool from the datadir was being loaded, and I didn't encounter any problems on first sight - but I'm not sure how useful that would be and I guess the final result would be dependent on races between the two mempools being loaded in parallel?

💬 furszy commented on pull request "index: improve initialization and pruning violation check":
(https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1199939444)
> This is already the case now in case of -reindex-chainstate after https://github.com/bitcoin/bitcoin/pull/25193 (I didn't think of that), but it could be easily changed in master by moving g_indexes_ready_to_sync = true up one line in ThreadImport.

yeah, I don't see why that would be a downside of this changes neither. Same as with `g_indexes_ready_to_sync` flag, the `StartIndexes()` call could be executed before the mempool load too.

It wouldn't be bad to rename `ThreadImport` to `Impo
...

💬 jarolrod commented on pull request "build: Do not define `ENABLE_ZMQ` when ZMQ is not available":
(https://github.com/bitcoin/bitcoin/pull/27696#issuecomment-1556549338)
hashes:

```
7091c64cada36ec2850f889978ae5fdc3cf4f28ec40bfb1fd16100c3f502fe6e guix-build-fa5831bd6f94/output/aarch64-linux-gnu/SHA256SUMS.part
e3b87e22e4cbd7a50aac4d5c982c12dd5b3f224ff4f9543dd3c331d424899287 guix-build-fa5831bd6f94/output/aarch64-linux-gnu/bitcoin-fa5831bd6f94-aarch64-linux-gnu-debug.tar.gz
96ffa1075a4b1d14c842bb8a5f5106cdb8f401eb173578c7376f6454b918e4eb guix-build-fa5831bd6f94/output/aarch64-linux-gnu/bitcoin-fa5831bd6f94-aarch64-linux-gnu.tar.gz
1bbe3a56784762b811eadc
...

👍 jarolrod approved a pull request: "build: Do not define `ENABLE_ZMQ` when ZMQ is not available"
(https://github.com/bitcoin/bitcoin/pull/27696#pullrequestreview-1435784103)
ACK fa5831bd6f940c4afb43ff625ba4fa6c641e999a

💬 ajtowns commented on pull request "Parallel compact block downloads, take 3":
(https://github.com/bitcoin/bitcoin/pull/27626#issuecomment-1556553095)
> In particular, I wonder if the fact that we'll now try additional peers will lead to redundancies / increased traffic under non-adversarial conditions where there's no staller but delivering the block just needs some time - especially when blocks contain a large number of txns that weren't in our mempool, or on slower networks like Tor. Did you consider the possibility of giving the original peer a few seconds to deliver before requesting from additional peers?

Yeah, this is the behaviour I
...

👍 MarcoFalke approved a pull request: "ci, iwyu: Double maximum line length for includes"
(https://github.com/bitcoin/bitcoin/pull/27707#pullrequestreview-1435841742)
lgtm