💬 sipa commented on pull request "bitcoin-cli: Add -ipcconnect option":
(https://github.com/bitcoin/bitcoin/pull/32297#issuecomment-2842236281)
Concept ACK
(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
...
(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
...
(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.
(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
(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)
(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.
(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
...
(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
...
(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.
(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
(https://github.com/bitcoin-core/gui/pull/870#issuecomment-2842456975)
friendly ping @Sjors
💬 maflcko commented on issue "build: x86 afl++ ASan build broken "error: inline assembly requires more registers than available"":
(https://github.com/bitcoin/bitcoin/issues/31913#issuecomment-2842593676)
> Now that we've removed `ENABLE_HARDENING` this is happening again. The suggested workaround of injecting flags manually via `APPEND_*` does not work.
To clarify, now it is a configure failure, as opposed to a build (make) failure?
(https://github.com/bitcoin/bitcoin/issues/31913#issuecomment-2842593676)
> Now that we've removed `ENABLE_HARDENING` this is happening again. The suggested workaround of injecting flags manually via `APPEND_*` does not work.
To clarify, now it is a configure failure, as opposed to a build (make) failure?
💬 fanquake commented on issue "build: x86 afl++ ASan build broken "error: inline assembly requires more registers than available"":
(https://github.com/bitcoin/bitcoin/issues/31913#issuecomment-2842608674)
> To clarify, now it is a configure failure, as opposed to a build (make) failure?
It's still a build failure, with no way to override the offending flag, as the APPEND options don't currently work properly.
(https://github.com/bitcoin/bitcoin/issues/31913#issuecomment-2842608674)
> To clarify, now it is a configure failure, as opposed to a build (make) failure?
It's still a build failure, with no way to override the offending flag, as the APPEND options don't currently work properly.
💬 hebasto commented on issue "build: x86 afl++ ASan build broken "error: inline assembly requires more registers than available"":
(https://github.com/bitcoin/bitcoin/issues/31913#issuecomment-2842616077)
> > To clarify, now it is a configure failure, as opposed to a build (make) failure?
>
> It's still a build failure, with no way to override the offending flag, as the APPEND options don't currently work properly.
Could someone provide a configuration options and a line from the verbose build to show what exactly is broken?
(https://github.com/bitcoin/bitcoin/issues/31913#issuecomment-2842616077)
> > To clarify, now it is a configure failure, as opposed to a build (make) failure?
>
> It's still a build failure, with no way to override the offending flag, as the APPEND options don't currently work properly.
Could someone provide a configuration options and a line from the verbose build to show what exactly is broken?
💬 davidgumberg commented on pull request "Add checkBlock() to Mining interface":
(https://github.com/bitcoin/bitcoin/pull/31981#discussion_r2069106692)
```suggestion
CCoinsViewCache view_dummy(&chainstate.CoinsTip());
```
(https://github.com/bitcoin/bitcoin/pull/31981#discussion_r2069106692)
```suggestion
CCoinsViewCache view_dummy(&chainstate.CoinsTip());
```
💬 maflcko commented on issue "ctest -C Debug fails on vs2022 (miniscript_tests (SEGFAULT))":
(https://github.com/bitcoin/bitcoin/issues/32341#issuecomment-2842716175)
> A third question would be, why the fuzz output is https://github.com/hebasto/bitcoin/actions/runs/14650416249/job/41114604643#step:14:60: `subprocess timed out: Currently only libFuzzer is supported`. A timeout should not happen for this process call, and the expected outcome should be an immediate stderr of `test/fuzz/fuzz.cpp:269 main: Assertion 'read_file(input_path, buffer)' failed. Error processing input "-help=1"` and an ignored exit code.
Looks like the assertions fails, but the progra
...
(https://github.com/bitcoin/bitcoin/issues/32341#issuecomment-2842716175)
> A third question would be, why the fuzz output is https://github.com/hebasto/bitcoin/actions/runs/14650416249/job/41114604643#step:14:60: `subprocess timed out: Currently only libFuzzer is supported`. A timeout should not happen for this process call, and the expected outcome should be an immediate stderr of `test/fuzz/fuzz.cpp:269 main: Assertion 'read_file(input_path, buffer)' failed. Error processing input "-help=1"` and an ignored exit code.
Looks like the assertions fails, but the progra
...
💬 maflcko commented on issue "build: x86 afl++ ASan build broken "error: inline assembly requires more registers than available"":
(https://github.com/bitcoin/bitcoin/issues/31913#issuecomment-2842751761)
I checked the original non-afl asan dockerfile and the existing workaround should still apply there (Don't use `-O0`, or disable secp256k1 asm).
Thus, my guess is the new issue is about afl only and the new dockerfile is https://github.com/dergoegge/fuzzamoto/blob/master/Dockerfile?
(https://github.com/bitcoin/bitcoin/issues/31913#issuecomment-2842751761)
I checked the original non-afl asan dockerfile and the existing workaround should still apply there (Don't use `-O0`, or disable secp256k1 asm).
Thus, my guess is the new issue is about afl only and the new dockerfile is https://github.com/dergoegge/fuzzamoto/blob/master/Dockerfile?
💬 achow101 commented on pull request "util: Remove `fsbridge::get_filesystem_error_message()`":
(https://github.com/bitcoin/bitcoin/pull/32383#issuecomment-2842817151)
ACK 97eaadc3bf9f621ba397e29bb1c0cd99af55f2e3
(https://github.com/bitcoin/bitcoin/pull/32383#issuecomment-2842817151)
ACK 97eaadc3bf9f621ba397e29bb1c0cd99af55f2e3
🚀 achow101 merged a pull request: "util: Remove `fsbridge::get_filesystem_error_message()`"
(https://github.com/bitcoin/bitcoin/pull/32383)
(https://github.com/bitcoin/bitcoin/pull/32383)
📝 maflcko opened a pull request: "fuzz: Remove unused TimeoutExpired catch in fuzz runner"
(https://github.com/bitcoin/bitcoin/pull/32388)
Currently, the way to check for libFuzzer is to search the stderr of the fuzz executable when passed `-help=1` for the string `libFuzzer`. See also https://github.com/bitcoin/bitcoin/blob/14b8dfb2bd5e2ca2b7c0c9a7f7d50e1e60adf75c/contrib/devtools/deterministic-fuzz-coverage/src/main.rs#L90-L101
The python test runner additionally includes a timeout catch, which was needed before the plain `read_file` fallback was implemented, see https://github.com/bitcoin/bitcoin/blob/14b8dfb2bd5e2ca2b7c0c9a7
...
(https://github.com/bitcoin/bitcoin/pull/32388)
Currently, the way to check for libFuzzer is to search the stderr of the fuzz executable when passed `-help=1` for the string `libFuzzer`. See also https://github.com/bitcoin/bitcoin/blob/14b8dfb2bd5e2ca2b7c0c9a7f7d50e1e60adf75c/contrib/devtools/deterministic-fuzz-coverage/src/main.rs#L90-L101
The python test runner additionally includes a timeout catch, which was needed before the plain `read_file` fallback was implemented, see https://github.com/bitcoin/bitcoin/blob/14b8dfb2bd5e2ca2b7c0c9a7
...