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

The options `datacarrier` and `datacarriersize` should not be removed. Instead only limits should be removed. Some people may want to use them for different reasons.

Maintaining core with a patch is not easy. Running older versions is not safe either.

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

The silencing of dissenting comments here is worrying because they're not being addressed. There are many valid reasons already expressed in this PR that are valid enough to close this and reject the proposal, but the team has refused so far. Larger data has been tried in other chains, but isn't what Bitcoin is for. We should be focusing on removing opportunities for spammers, not make their lives easier.

💬 laanwj commented on pull request "Remove the legacy wallet and BDB dependency":
(https://github.com/bitcoin/bitcoin/pull/28710#issuecomment-2842132320)
Some small berkeleydb (AFAIK, non-migration) related cruft after this:
```
src/wallet/load.cpp: // The canonical path cleans the path, preventing >1 Berkeley environment instances for the same directory
test/sanitizer_suppressions/tsan:race:BerkeleyBatch
vcpkg.json: "berkeleydb",
vcpkg.json: "berkeleydb": {
vcpkg.json: "berkeleydb"
```

💬 Sjors commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2842149495)
> Maintaining core with a patch is not easy.

Knots already does this, plus all the other mempool filtering stuff people demand. The extra maintenance for them is negligible.

> Some people may want to use them for different reasons.

Such as?

💬 Sjors commented on pull request "mining: rename gbt_force and gbt_force_name":
(https://github.com/bitcoin/bitcoin/pull/32386#issuecomment-2842186970)
I also documented some of the `!` behavior in #26201. It might be worth including that here, along with @ajtowns's explanation.

Behavior (3) is implemented here (code below is in master, so not renamed):

https://github.com/bitcoin/bitcoin/blob/14b8dfb2bd5e2ca2b7c0c9a7f7d50e1e60adf75c/src/rpc/mining.cpp#L965-L970

This seems potentially dangerous when combined with forced signalling, which IIRC has occasionally been proposed _after_ Bitcoin Core already shipped activation code. Once somet
...

💬 BrazyDevelopment commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2842197226)
>
> This is so incredibly vague that it reads like an LLM output. @BrazyDevelopment nothing in your comment actually specifies a novel attack vector. Nodes already have resource management logic that mitigates the issues you outlined.

Apologies for the "vagueness", it was not an LLM output, allow me to clarify...

I’m not worried about some brand-new attack vector popping up, my concern is that scrapping OP_RETURN limits could make existing ones, like flood-and-loot or mempool spam, way
...

💬 0ceanSlim commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2842208778)
@BrazyDevelopment Who is the arbiter of "low value" here?

💬 jlopp commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2842211803)
> This clogs things up, delays real transactions, and jacks up fees as users compete.

This is literally how the market for block space operates. You haven't described anything different.

> Massive OP_RETURN data could push smaller nodes to their memory or bandwidth limits, making it harder for them to kick out junk transactions and keep things running smoothly.

What, specifically, would make mempool eviction "harder?" The lowest fee rate paying transactions get automatically evicted reg
...

💬 darosior commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2842235910)
@jesterhodl conceptual discussions should go on the mailing list. If you do take it there please understand the topic before sharing your strong opinion, this has nothing to do with Taproot witnesses. I just blocked you, which should prevent you from commenting further on this PR and wasting everyone's time.

💬 sipa commented on pull request "bitcoin-cli: Add -ipcconnect option":
(https://github.com/bitcoin/bitcoin/pull/32297#issuecomment-2842236281)
Concept ACK

💬 stevanlohja commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2842294831)
I like this proposal, however, **a moderate increase in the limit is the most prudent path to harness the benefits while managing the downsides** because the idea of removing the arbitrary limit is dependent on execution.

Obvious benefits of removing the limit size is innovation and efficiency because we already have to workaround with multiple UTXO sets and I can see this limit increase making that more streamlined. So, great for the Bitcoin economy imo.

More data heavy applications will
...

📝 D33r-Gee opened a pull request: "[DRAFT] Expose AssumeUTXO Load Snapshot Functionality To The GUI"
(https://github.com/bitcoin-core/gui/pull/870)
based on the QML PR [424](https://github.com/bitcoin-core/gui-qml/pull/424). For evaluation purposes only!

# GUI Integration for UTXO Snapshot Loading

## Overview
This PR adds initial GUI support for loading a UTXO snapshot, building on Bitcoin Core's `assumeutxo` infrastructure.

## What This PR Does

1. Adds a basic GUI interface for loading UTXO snapshots via the Options Dialog panel
2. Provides visual confirmation of snapshot activation
3. Adds a snapshot progress notification b
...

💬 vasild commented on pull request "net: replace manual reference counting of CNode with shared_ptr":
(https://github.com/bitcoin/bitcoin/pull/32015#issuecomment-2842363137)
I am incorporating your feedback here, looks good so far.

💬 D33r-Gee commented on pull request "interface: Expose load utxo snapshot functionality":
(https://github.com/bitcoin-core/gui/pull/869#issuecomment-2842364549)
Thanks @Sjors and @jarolrod for your feedback.

After consideration I am opening a PR in this repo to expose the AssumeUTXO Load Snapshot functionality. It can be found in PR #870

✅ D33r-Gee closed a pull request: "interface: Expose load utxo snapshot functionality"
(https://github.com/bitcoin-core/gui/pull/869)

💬 sipa commented on pull request "cluster mempool: add txgraph diagrams/mining/eviction":
(https://github.com/bitcoin/bitcoin/pull/31444#discussion_r2068920561)
Done.

💬 ajtowns commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2842373160)
Approach NACK for me -- there's no point having a limit that's trivially avoided by just having many OP_RETURNs, and forcing people to waste blockspace by encoding redundant nValue and `OP_RETURN OP_PUSH` instructions when they would have been happy with the same data in a single output doesn't seem desirable either.

IMO it would make sense to:
* raise the default limit to a value that avoids people creating unprunable burn addresses,
* remove the (unconfigurable) limit on number of OP_RE
...

💬 sipa commented on pull request "cluster mempool: add txgraph diagrams/mining/eviction":
(https://github.com/bitcoin/bitcoin/pull/31444#discussion_r2068925137)
The `TxGraph` interface doesn't promise a specific order, only a diagram. The implementation may be doing something more specific right now, but since the interface does not promise that, the test shouldn't be relying on it.

In what follows, `main_cmp_diagram` and `stage_cmp_diagram` will not be treated a diagrams, but as sets of FeeFrac objects, and they'll be compared against the sets of FeeFrac objects in `main_real_diagram` and `staged_real_diagram` respectively. In order to do that, they
...

💬 sipa commented on pull request "cluster mempool: add txgraph diagrams/mining/eviction":
(https://github.com/bitcoin/bitcoin/pull/31444#discussion_r2068926072)
Done, and added some more `real_` and `sim_` prefixes to variables here.

💬 D33r-Gee commented on pull request "[DRAFT] Expose AssumeUTXO Load Snapshot Functionality To The GUI":
(https://github.com/bitcoin-core/gui/pull/870#issuecomment-2842456975)
friendly ping @Sjors