💬 ismaelsadeeq commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2073509605)
Contrary to the PR title and description we still have a capacity of the maximum standard tx weight?

So could this be clarified to indicate that we still maintain the standardness limit?

---
_"hypothetical" but what if we see in the future "transaction landscape has rendered this cap ineffective" as well?_

💬 ismaelsadeeq commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2073574032)
nit:
```suggestion
// Multiple TxoutType::NULL_DATA are permitted
```

💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2073627850)
This should be a no-op at default due to `MAX_STANDARD_TX_WEIGHT`, but if it's clearer to set it to int max or similar, I can do that

💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2073633213)
Personally, I'm fine with the option being subset over a longer period. I'll let other people weigh in on that as a possibility.

💬 starius commented on pull request "Extend signetchallenge to set target block spacing":
(https://github.com/bitcoin/bitcoin/pull/29365#issuecomment-2851339649)
@pinheadmz The failure is from commit https://github.com/starius/bitcoin/commit/60a7042a7219fcfc35e3fea28d038f96a11efcea
It doesn't include this PR, it just the master (slightly outdated, commit eba5f9c4b63fe46261fbb3e71b9a94832d105b23) + the patch I posted above.
The command I'm running is `build/test/functional/test_runner.py feature_signet.py --nocleanup`

💬 hebasto commented on pull request "cmake: Add application manifests when cross-compiling for Windows":
(https://github.com/bitcoin/bitcoin/pull/32396#issuecomment-2851344013)
My Guix build:
```
164958d8c5292ef876e3454725888a488565a414af690a568caedae31215db6c guix-build-b074ae1b4f52/output/dist-archive/bitcoin-b074ae1b4f52.tar.gz
145be7d02fd3d967351ad5944ffe4ceb885e3f7bed6677be657b1c0aa125b40c guix-build-b074ae1b4f52/output/x86_64-w64-mingw32/SHA256SUMS.part
2794ba8c24e64ca1068e04b73748e1406df51089a149a8b0a70637d0bf8e120a guix-build-b074ae1b4f52/output/x86_64-w64-mingw32/bitcoin-b074ae1b4f52-win64-codesigning.tar.gz
627119d12ba969849ed7727d105ec7d756e201415c99
...

👋 hebasto's pull request is ready for review: "cmake: Add application manifests when cross-compiling for Windows"
(https://github.com/bitcoin/bitcoin/pull/32396)

💬 moth-oss commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851349215)
Concept NACK

I've read the justifications but remain unconvinced the timing as well as the decision to altogether remove the option to configure is the right one.

Increasing the default and giving node runners the option to change that is the right way to go. And a few versions layers maybe the discussion to remove it altogether can be restarted. Current PR is way too sudden. It seems we did not learn the lesson from the unintentional effect lifting the witness script size limit had on th
...

💬 andrewtoth commented on pull request "validation: write chainstate to disk every hour":
(https://github.com/bitcoin/bitcoin/pull/30611#issuecomment-2851366217)
Just tested with `-dbcache=45000 -connect=<local_node>` and after about an hour I have
`[warning] Flushing large (7 GiB) UTXO set to disk, it may take several minutes`.

💬 mzumsande commented on issue "Verify AssumeUTXO snapshot hashes during full validation as well":
(https://github.com/bitcoin/bitcoin/issues/32377#issuecomment-2851372290)
Removing the existing checkpoints is something that has been done to a large part for ideological reasons (devs shouldn't prescribe / hardcode what the "correct" chain is), so introducing something similar back in (and not just historical but new ones) just for the sake of AssumeUxto would be quite contentious I think - I view AssumeUtxo as a nice feature, but a second-class citizen to normal IBD.

I guess if we'd just log a warning in case of a mismatch there is no harm (except for the added t
...

💬 polespinasa commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2073676011)
Oh right my bad should be `InitWarning(_("Warning: ..."))`!

Anyway yes you should be able to do so. You have to specify the expected `stderr` like:
https://github.com/bitcoin/bitcoin/blob/baa848b8d38187ce6b24a57cfadf1ea180209711/test/functional/wallet_create_tx.py#L72

By default is set to an empty string:
https://github.com/bitcoin/bitcoin/blob/baa848b8d38187ce6b24a57cfadf1ea180209711/test/functional/test_framework/test_framework.py#L607

💬 Sjors commented on pull request "validation: write chainstate to disk every hour":
(https://github.com/bitcoin/bitcoin/pull/30611#issuecomment-2851385717)
Indeed I also saw the `chaintate` dir grow after 1 hour, will keep an eye on it.

💬 l0rinc commented on issue "Verify AssumeUTXO snapshot hashes during full validation as well":
(https://github.com/bitcoin/bitcoin/issues/32377#issuecomment-2851395816)
> second-class citizen to normal IBD

Agree, IBD would validate that the AssumeUTXO hashes are correct - lending its credibility to the quicker alternative.

✅ polespinasa closed a pull request: "rpc, logging: return "verificationprogress" of 1 when up to date"
(https://github.com/bitcoin/bitcoin/pull/31177)

💬 polespinasa commented on pull request "rpc, logging: return "verificationprogress" of 1 when up to date":
(https://github.com/bitcoin/bitcoin/pull/31177#issuecomment-2851418794)
I will close this PR for the moment as I don't think I will get enough ACKs with the current approach.
Will be happy to review new approaches to solve this.

💬 Eunovo commented on pull request "[EXPERIMENTAL] Schnorr batch verification for blocks":
(https://github.com/bitcoin/bitcoin/pull/29491#issuecomment-2851542917)
While testing this, I observed a decline in performance as the number of threads increased. I'm not sure why this happens, but I suspect these play a role:
- Doing batch-verification work within the critical section https://github.com/bitcoin/bitcoin/pull/29491/files#diff-0f68d4063c2fb11000f9048e46478e26c0ea2622f7866d00b574f429c3a4db61R151
- Copy operations in https://github.com/bitcoin/bitcoin/pull/29491/files#diff-612abe4a74f2e9f6903cebff057d47bfe4f8a57507c175743f4b62fde0d3cc58R95-R99

I m
...

💬 caesrcd commented on issue "Apparently CJDNS network does not work with Tor on mainnet.":
(https://github.com/bitcoin/bitcoin/issues/24450#issuecomment-2851546390)
I’ve been studying the multi-network support in Bitcoin Core (Clearnet, Tor, I2P, CJDNS), especially from a resilience and redundancy perspective. I’d like to raise a concern regarding the current behavior of routing CJDNS through the general `-proxy` setting.

While it's understandable that `-proxy` applies broadly to IPv4, IPv6, and CJDNS, this design unintentionally breaks a core benefit of multi-network support: **redundancy through independence**.

Unlike Tor or I2P, which are anonymity-foc
...

💬 miketwenty1 commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851569165)
Concept ACK.

I believe this is a marginal improvement over #32359. It's better to err on the side of a normal deprecation path with more knobs rather than fewer, especially since this knob (`-datacarriersize`) was previously available. Its removal has been a specific point of controversy, explicitly described by some as core compelling speech. However, this conceptual change will likely affect only a small percentage of previous NACKers, since the intent and outcome seem clear and unchanged i
...

💬 ryanofsky commented on pull request "cmake: Respect user-provided configuration-specific flags":
(https://github.com/bitcoin/bitcoin/pull/32356#issuecomment-2851586658)
Concept ACK.

I think I agree with @purpleKarrot that it is bad to override CMAKE_ variables, and in general the build does too much overriding (which I've mentioned before in places like https://github.com/bitcoin/bitcoin/issues/30813#issuecomment-2329412411).

But it seems like the PR is moving in the right direction and making a strict improvement by overriding less aggressively than before. I think hebasto's point about wanting CMAKE_BUILD_TYPE=Release (and release builds in multi-config
...

💬 fjahr commented on pull request "[EXPERIMENTAL] Schnorr batch verification for blocks":
(https://github.com/bitcoin/bitcoin/pull/29491#issuecomment-2851688561)
> While testing this, I observed a decline in performance as the number of threads increased.

Can you share the setup for these benchmarks so I can test them? Thanks!