💬 fjahr commented on pull request "Embedded ASMap [3/3]: Build binary dump header file":
(https://github.com/bitcoin/bitcoin/pull/28792#discussion_r2530154158)
I can't remember encountering such a tool but primarily I was going by our style guide, which I thought had mentioned that we don't do new lines before EOF but I guess it doesn't (anymore?) since I couldn't find it right now. At least we have `InsertNewlineAtEOF: false` in our `.clang-format`.

💬 sipa commented on pull request "refactor, docs: Embedded ASMap [2/3]: Refactor asmap internals and add documentation":
(https://github.com/bitcoin/bitcoin/pull/33878#discussion_r2530246100)
All the documentation changes in this commit look correct to me.

One thing that may be worth mentioning early on is that it's a bit-packed format, i.e., the entire compressed mapping is treated as a sequence of bits, packed together at 8 per byte, which are concatenated encodings of instructions.

📝 fjahr opened a pull request: "test: Fix race condition in IPC interface block progation test"
(https://github.com/bitcoin/bitcoin/pull/33880)
CI failed on this condition here: https://github.com/bitcoin/bitcoin/actions/runs/19395398994/job/55494696022?pr=33878#step:9:3983

The check was added not too long ago in https://github.com/bitcoin/bitcoin/pull/33745 and it seems like an easy fix to wait a bit but I am not sure if the check could also not just be removed. Afaict it doesn't make a difference whether the regression below it is hit or not.

💬 fjahr commented on pull request "test: Fix race condition in IPC interface block progation test":
(https://github.com/bitcoin/bitcoin/pull/33880#issuecomment-3536959684)
cc: @Sjors

📝 thelonestar63 opened a pull request: "Snailcoin rebrand"
(https://github.com/bitcoin/bitcoin/pull/33881)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

⚠️ roconnor-blockstream opened an issue: "Standardness policy rules for legacy Multisig script is incoherent"
(https://github.com/bitcoin/bitcoin/issues/33882)
Over the years policy surrounding multisig scripts, particularly for legacy multisig scripts, has evolved in a haphazard way with various PRs affecting legacy multisig script policy without considering the ramifications.

The current status of legacy multisig script policy is as follows:

* Legacy multisig outputs in transactions can be at most *m*-of-3. All pubkeys in such outputs must be of the form of a compressed pubkey, and uncompressed pubkey, or a hybrid pubkey.
* Legacy multisig inputs
...

💬 roconnor-blockstream commented on issue "Standardness policy rules for legacy Multisig script is incoherent":
(https://github.com/bitcoin/bitcoin/issues/33882#issuecomment-3537392532)
## How did we get here

I've compiled a list of what I believe are all the relevant PRs related to policy surrounding multisig scripts, listed in chronological order.
This work is based on previous work done by @ajtowns

### PR #669; merged 2011-12-20
This PR introduces *m*-of-*n* checkmultisig as a solvable script for the first time.
Solvability requires *m* and *n* to be at most 16.
Per BIP 11, standardness requires solvable MULTISIG tx outputs to be at most *m*-of-3 and *m* to be less than *
...

⚠️ ofry opened an issue: ""Send" text field has too little amount"
(https://github.com/bitcoin/bitcoin/issues/33883)
### Is there an existing issue for this?

- [x] I have searched the existing issues

### Current behaviour

The "Amount" input field on the "Send" tab is too narrow; the user can only see a single digit.

The screenshot is below:

<img width="1280" height="1024" alt="Image" src="https://github.com/user-attachments/assets/2c75a951-609d-4c87-b62e-8aa3d31494cc" />

### Expected behaviour

User should see all digits on payment amount.

### Steps to reproduce

1. Download latest release from https://
...

💬 yuvicc commented on pull request "kernel: Add block header support and validation":
(https://github.com/bitcoin/bitcoin/pull/33822#issuecomment-3537983534)
Thanks for the review @TheCharlatan
- Removed some unnecessary comments and indentation
- Added inline doc [comment](https://github.com/bitcoin/bitcoin/pull/33822#discussion_r2528773169)

🤔 yuvicc reviewed a pull request: "kernel: Rename in-memory DB option setters and simplify API"
(https://github.com/bitcoin/bitcoin/pull/33877#pullrequestreview-3469677908)
Concept ACK

Makes sense to refractor update to set and remove the int parameter here.

💬 yuvicc commented on pull request "kernel: Rename in-memory DB option setters and simplify API":
(https://github.com/bitcoin/bitcoin/pull/33877#discussion_r2531456075)
I think these options are set by default?

💬 yuvicc commented on pull request "kernel, validation: Refactor ProcessNewBlock(Headers) to return BlockValidationState":
(https://github.com/bitcoin/bitcoin/pull/33856#discussion_r2531493620)
The problem is that `ActivateBestChain` would overwrite the `state` result, when the background chain's `ActivateBestChain` succeeds, it would overwrite state with its own `state`. Then at line 4554, we'd be returning the background chain's `state` instead of the active chainstate's `state`. So by separating out, we preserve the active chainstate result.

💬 yuvicc commented on pull request "kernel, validation: Refactor ProcessNewBlock(Headers) to return BlockValidationState":
(https://github.com/bitcoin/bitcoin/pull/33856#discussion_r2531525257)
Correct, we will definitely need that.

💬 yuvicc commented on pull request "kernel, validation: Refactor ProcessNewBlock(Headers) to return BlockValidationState":
(https://github.com/bitcoin/bitcoin/pull/33856#issuecomment-3538243414)
Thanks for the review @hodlinator
- Added `Assume(!headers.empty())` before instantiating validation state as suggested in [comment](https://github.com/bitcoin/bitcoin/pull/33856#discussion_r2517354777)
- Removed shadow `state` [comment](https://github.com/bitcoin/bitcoin/pull/33856#discussion_r2517333716)

⚠️ yuvicc opened an issue: "interface_ipc functional test failing in CI"
(https://github.com/bitcoin/bitcoin/issues/33884)
## Summary

The `interface_ipc` functional test is failing in CI but passes when run locally.

Affected PR's: #33856 and #33878

💬 stringintech commented on pull request "kernel: Rename in-memory DB option setters and simplify API":
(https://github.com/bitcoin/bitcoin/pull/33877#discussion_r2531820732)
Yes they are. No strong opinion, but it might be better to also explicitly set the default values here (in the kernel code - `ChainstateManagerOptions` ctor) for options we have setters for. Looks more intentional and readable to me this way.
But `coins_error_cb = {}` is to make the [compiler](https://github.com/bitcoin/bitcoin/pull/33877#issuecomment-3536504585) happy.

💬 romanz commented on pull request "rest: allow reading partial block data from storage":
(https://github.com/bitcoin/bitcoin/pull/33657#issuecomment-3538691286)
Updated PR description with query performance and external offset index size for mainnet:
<img width="1093" height="297" alt="image" src="https://github.com/user-attachments/assets/88ade527-c26d-4572-af9d-cdca166ba7dd" />

💬 pinheadmz commented on issue ""Send" text field has too little amount":
(https://github.com/bitcoin/bitcoin/issues/33883#issuecomment-3538709055)
Weird! Would you mind moving this issue to the GUI repo?

https://github.com/bitcoin-core/gui

💬 ofry commented on issue ""Send" text field has too little amount":
(https://github.com/bitcoin/bitcoin/issues/33883#issuecomment-3538748689)
Ah, it's already created by another user. https://github.com/bitcoin-core/gui/issues/906

💬 stringintech commented on pull request "kernel: handle null or empty directories in implementation":
(https://github.com/bitcoin/bitcoin/pull/33867#issuecomment-3538851999)
ACK 6657bcb