🤔 ismaelsadeeq reviewed a pull request: "policy: uncap datacarrier by default"
(https://github.com/bitcoin/bitcoin/pull/32406#pullrequestreview-2814921270)
Concept ACK on relaxing the maximum capacity of the `OP_RETURN` size to the current transaction standardness limit.

1. This change will improve fee estimation in Bitcoin Core, as users will now be able to see the fee pressure from "data-carier" transactions that were previously broadcast out of band.

2. It will also improve block propagation time and make mining fairer, as data carrier transactions below standardness limit will now be relayed in nodes' mempools before being included in blo
...

💬 ismaelsadeeq commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2073589388)
From what I see from previous PR is that after deprecation; the feature will be removed in next release cycle, so maybe indicate that?
https://github.com/bitcoin/bitcoin/pull/31278#discussion_r1838749101

If we will eventually deprecate this then let's indicate that.

💬 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
...