💬 willcl-ark commented on pull request "guix: build for Linux HOSTS with `-static-libgcc`":
(https://github.com/bitcoin/bitcoin/pull/33181#issuecomment-3513602175)
ACK f06c6e18983139dd63873b3537d2f87b8c6ec752

> i'm wondering if this build uses more than 38 GiB, my guix build just failed for this PR. it just has slightly more than 38 GiB available so it passes the check but just failed on no more space on disk.
>
> Will do another run to check :)

I don't know exactly how much space it needs, but my `/gnu` partition is at 36.8GiB total after this build, which certainly seems close to your figure...

💬 waketraindev commented on pull request "Prevent re-execution of sensitive commands from console history":
(https://github.com/bitcoin-core/gui/pull/909#issuecomment-3513665716)
Extended the blocking filter to include transaction-related RPCs `send`, `sendall`, `sendmany` and
`sendtoaddress` as these can also cause unintended effects.

Test covereage added for them

💬 instagibbs commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#discussion_r2511867396)
Maybe misunderstanding, but this just means it's purely an optimzation?

If it's not in the main graph, it still is able to gather ancestors via more expensive mempool queries.

💬 JeremyRubin commented on pull request "Extend signetchallenge to set target block spacing":
(https://github.com/bitcoin/bitcoin/pull/29365#discussion_r2511884930)
I would change this to read "Unknown Signet Challenge Version %d, versions [0x01] supported"

and read the first field as a VarInt or CompactSize.

💬 JeremyRubin commented on pull request "Extend signetchallenge to set target block spacing":
(https://github.com/bitcoin/bitcoin/pull/29365#discussion_r2511885878)
this should come _after_ the version check

💬 sipa commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#discussion_r2511906918)
@instagibbs Oh, you're right - the mutation just causes the code to always use the fallback path, which needs to exist for non-mempool transactions anyway.

💬 JeremyRubin commented on pull request "Extend signetchallenge to set target block spacing":
(https://github.com/bitcoin/bitcoin/pull/29365#discussion_r2511906920)
i would probably make parsing work by doing a SERIALIZE_METHODS on a struct, and have any extensions in the future be done by failing to deserialize unknown versions...

💬 JeremyRubin commented on pull request "Extend signetchallenge to set target block spacing":
(https://github.com/bitcoin/bitcoin/pull/29365#issuecomment-3513831449)
Concept ACK.

We use something like this for testing and it's quite helpful.

it's nice being able to ship a parameter pack in a single hex for a signet.

I think the future version flexibility can be simplified, reducing @Sjors concern of the wrapper complexity. A good ol' serialize_methods chunk can probably make this trivial :)

e.g.:


```
SERIALIZE_METHODS(WrappedSignetChallenge, obj)
{
READWRITE(obj.version);
if (obj.version == 0) {
READW
...

💬 sdaftuar commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#discussion_r2511994968)
Ah, no -- if we `Apply()` the changes from a changeset then the staging goes away before the destructor is called.

💬 sdaftuar commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#discussion_r2512009883)
I'll update the comment to match (and just as an fyi, there was some discussion that we might relax this assumption in the future but we can update the comment at that point).

💬 sdaftuar commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#discussion_r2512014507)
I tried to improve this code in #33591, in commit https://github.com/bitcoin/bitcoin/commit/ee92868eb112ce59e385650f4bd0daf96eb715ab.

🤔 sipa reviewed a pull request: "bitcoin-cli: Add -ipcconnect option"
(https://github.com/bitcoin/bitcoin/pull/32297#pullrequestreview-3445284961)
Concept ACK and mild code review ACK.

✅ waketraindev closed an issue: "Ability to retrieve peer info by peer id"
(https://github.com/bitcoin/bitcoin/issues/33478)

✅ waketraindev closed an issue: "No way to clear command history in RPC console or reset the console without restarting the node"
(https://github.com/bitcoin-core/gui/issues/897)

💬 sdaftuar commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#discussion_r2512154527)
Neat idea-- however it looks like I also use this in `CTxMemPool::GetFeerateDiagram()`, where we want the size to be accurate.

I do like getting rid of the rounding error, but perhaps that would be best accomplished by changing the internal units of things like the blockminfeerate to be in terms of fee-per-weight, in a followup PR?

💬 sdaftuar commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#discussion_r2512156434)
I'm planning to take @glozow's suggestion above (https://github.com/bitcoin/bitcoin/pull/33629#issuecomment-3499901560).

💬 sipa commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#discussion_r2512170504)
Fair enough, and that's easier to do more granuarly then all-at-once guaranteeing that all uses of `FeePerVSize` are size-independent right now.

💬 instagibbs commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#discussion_r2512171225)
https://github.com/glozow/bitcoin/commit/85895de30cc09db2b1f6be5f1057f79a68a6ccc9#r170215881

note that the suggested branch has at least one behavior change

💬 hebasto commented on pull request "build: add `-W*-whitespace`":
(https://github.com/bitcoin/bitcoin/pull/32482#issuecomment-3514168708)
> > Thanks. I've pulled those two in here.
>
> Looking at the CI. Those commits are not going to work as implemented (essentially anywhere we are using Clang).

Here is a branch with the fixed commit: https://github.com/hebasto/bitcoin/commits/pr32482/1110.1/.

💬 sdaftuar commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#discussion_r2512204607)
I believe we've always thought about feerate in our RPCs/user interface as being fee-per-vsize, so I'd be reluctant to make that change as a one-off here; if we don't follow through and make fee-per-weight the norm, then I think our interface would feel more confusing for users.