🚀 hebasto merged a pull request: "qt, docs: Unify term "clipboard""
(https://github.com/bitcoin-core/gui/pull/871)

💬 k98kurz commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2870003040)
> > @BitcoinMechanic
> It does no harm to fee estimation or block propagation. Nodes can and do cache transactions they reject from their mempools making compact blocks just as quick to verify regardless of if some of their contents was filtered.

This is the first I have heard about this caching of non-standard transactions. If this is indeed the case, then the small-block-propagation-performance-degradation argument is largely invalidated, but this requires that the cache be sufficiently la
...

💬 polespinasa commented on pull request "rpc:generatetomany":
(https://github.com/bitcoin/bitcoin/pull/32468#discussion_r2083578626)
> this is now dead code, according to https://corecheck.dev/bitcoin/bitcoin/pulls/32468

Will delete it, was just added as all the else statement code is not needed for the simeple `generatetoaddress`.

> Generally, I am not sure about modifying real code to accommodate test-only code. It would be better to not modify `src/node` at all and just put the test-only code in the test-only code paths.

I'm not understanding this part, what do you mean by test-only code? I don't see a way to add
...

✅ hMsats closed an issue: "Self-compiled bitcoind 29.0 much slower than self-compiled 28.0 on my system"
(https://github.com/bitcoin/bitcoin/issues/32455)

💬 hMsats commented on issue "Self-compiled bitcoind 29.0 much slower than self-compiled 28.0 on my system":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2870019391)
Although the jury is still out, it might be related to what @sipa suggested: that the cache still hasn't warmed up enough and validation speed is temporarily slow. I'm testing different options like running with the pre-compiled bitcoind but every test takes quite a long time to come to a clear conclusion (days).

At least I got an answer to my questions of why my executables are so big. Closing for now, will reopen if this issue persists.

💬 polespinasa commented on pull request "rpc:generatetomany":
(https://github.com/bitcoin/bitcoin/pull/32468#issuecomment-2870019412)
> All fields with "remainder" to have the remainder split equally amongst them?

I don't see duplicating entries as a good option. Could lead to errors. I think is better to have two camps for each address entry, one for the amount (can be 0) and one for reminder (can be done with 0 or 1 or by setting "remainder" or an empty string)

💬 polespinasa commented on pull request "rpc:generatetomany":
(https://github.com/bitcoin/bitcoin/pull/32468#issuecomment-2870020026)
> @polespinasa @supertestnet Please check out [polespinasa#1](https://github.com/polespinasa/bitcoin/pull/1) with the discussed changes and let me know what you think.

left some comments on your proposal PR

💬 lollerfirst commented on pull request "rpc:generatetomany":
(https://github.com/bitcoin/bitcoin/pull/32468#issuecomment-2870027043)
> duplicating entries

How is it duplicating entries? In the example there is a different address for each entry.

💬 polespinasa commented on pull request "rpc:generatetomany":
(https://github.com/bitcoin/bitcoin/pull/32468#issuecomment-2870027925)
> How is it duplicating entries?

First address is duplicated. Anyway it is duplicated in case you want to assign an amount to an address + remainder.

👍 TheCharlatan approved a pull request: "checkqueue: make the queue non-optional for CCheckQueueControl and drop legacy locking macro usage"
(https://github.com/bitcoin/bitcoin/pull/32467#pullrequestreview-2831468672)
ACK 5aca850c205a20a0f198827f9797fb8053f2b3dd

💬 TheCharlatan commented on pull request "checkqueue: make the queue non-optional for CCheckQueueControl and drop legacy locking macro usage":
(https://github.com/bitcoin/bitcoin/pull/32467#discussion_r2083592266)
I think it would be nice if we could get some kind of locking warning here if a second `CCheckQueueControl` is created from the same `CCheckQueue`, instead of just deadlocking. Tried coming up with a combination of LOCK and UNLOCK_FUNCTION annotation, but could not find something that actually worked.

💬 Cyberwiz9000 commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2870050321)
Approach NACK

I can understand the technical reasons for lifting the `OP_RETURN` but I oppose the removal of node configurability. Both `-datacarrier` and `-datacarriersize` should be retained. Node operators should be able to choose what kind of data they relay without having to rely on other Node implementations that have less developper support.

Additionally, I object to allowing multiple `OP_RETURN` outputs per transaction. This may increase mempool complexity, raise attack surface, an
...

💬 liviu-liviu commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2870055985)
Concept NACK We should create more (and possibly easier) avenues that help node operators express their will. This PR is moving us in the opposite direction.

💬 liviu-liviu commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2870056177)
Concept NACK We should create more (and possibly easier) avenues that help node operators express their will. This PR is moving us in the opposite direction.

💬 stringintech commented on pull request "kernel: Separate UTXO set access from validation functions":
(https://github.com/bitcoin/bitcoin/pull/32317#discussion_r2083615207)
Oh, it makes sense. Thanks for the insights.

💬 l0rinc commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2870192790)
> I think we should have an option (default on) to obfuscate the block data files on startup if they are not yet obfuscated.

For the record, @andrewtoth pushed a separate tool to fix this issue since, see: https://github.com/bitcoin/bitcoin/pull/32451

---

As for removing the limit, I don't think it makes any meaningful difference either way; this discussion was way overblown for some reason. My only objection was how aggressively this was pushed - we should have started with a long and
...

💬 1440000bytes commented on pull request "[Policy] Discourage Unsigned Annexes":
(https://github.com/bitcoin/bitcoin/pull/32453#issuecomment-2870220123)
Concept ACK

I couldn't think of any legit use case that would require unsigned annex.

💬 1440000bytes commented on pull request "config: allow setting -proxy per network":
(https://github.com/bitcoin/bitcoin/pull/32425#issuecomment-2870221917)
Concept ACK

Multiple proxies for different networks would be useful. Might need release notes if this eventually gets merged.

💬 1440000bytes commented on pull request "wallet: init, don't error out when loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/32449#discussion_r2083631109)
Would this look better with a multi line comment?

💬 1440000bytes commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#issuecomment-2870224955)
Concept ACK

Could be a useful tool for paranoid users who can run this tool.

Is it possible to add this feature in bitcoin core itself?