⚠️ rleed opened an issue: "Add config option to set external P2P port to facilitate incoming connections"
(https://github.com/bitcoin/bitcoin/issues/32657)
### Please describe the feature you'd like to see added.

Add config option to set external P2P port to facilitate incoming connections, complementary to the `externalip` option.

### Is your feature related to a problem, if so please describe it.

Without being able to specify the external port, it is impossible to receive incoming connections when the node is behind a port-forwarding system unless the same port number is used both externally and internally, which may not always be an option o
...

💬 sipa commented on issue "Add config option to set external P2P port to facilitate incoming connections":
(https://github.com/bitcoin/bitcoin/issues/32657#issuecomment-2928051271)
Does `-port` not work for this?

💬 pinheadmz commented on pull request "[28.x] Backport #31407":
(https://github.com/bitcoin/bitcoin/pull/32563#discussion_r2119694409)
This is the issue maybe? Is https://github.com/bitcoin/bitcoin/pull/31161 merged into 28.x at this point? There isn't a `bin/` directory `codesigning.tar.gz` archive, just a `dist/`

💬 rleed commented on issue "Add config option to set external P2P port to facilitate incoming connections":
(https://github.com/bitcoin/bitcoin/issues/32657#issuecomment-2928101091)
> Does `-port` not work for this?

As I understand it, the value specified by `-port` is currently advertised along with that of `-externalip` to allow incoming connections to a non-default port, but in a port-forwarding situation, this only works when the external forwarded port is identical to the local listening port. However, there are situations where this is not practical. Being able to specify the external port independently would provide a general solution.

💬 ajtowns commented on pull request "init: deprecate `-blockmaxweight` startup option":
(https://github.com/bitcoin/bitcoin/pull/32654#issuecomment-2928112394)
> The reservedweight isn’t just for the coinbase it also applies to the block header and transaction count. It seems reasonable to use the blockreservedweight option to lower the block weight to the desired magnitude.

Well, you can't pad the block header or transaction count encoding? :)

I think it makes sense to combine the two values into one internal option that controls the maximum cumulative tx weight, but I think the options both individually make sense from a user's point of view. (
...

💬 pinheadmz commented on pull request "[28.x] Backport #31407":
(https://github.com/bitcoin/bitcoin/pull/32563#discussion_r2119730809)
By contrast, the 29.0 codesigning tar had `./bitcoin-29.0/bin/`

💬 sipa commented on issue "Add config option to set external P2P port to facilitate incoming connections":
(https://github.com/bitcoin/bitcoin/issues/32657#issuecomment-2928207022)
I see. I believe this already works, you can add a port number to the `externalip=` argument.

💬 John-zhan commented on issue "windows: depends config fails":
(https://github.com/bitcoin/bitcoin/issues/32578#issuecomment-2928225261)
> [@John-zhan](https://github.com/John-zhan)
>
> You could use the same workaround as we use in the CI. See [#32184](https://github.com/bitcoin/bitcoin/pull/32184).



> [@John-zhan](https://github.com/John-zhan) does that work for you?
Oh, no. I'm so sorry. I just execute `rd /s /q build && del /f /q CMakeCache.txt && rd /s /q CMakeFiles`。
Then `cmake -B build --preset vs2022-static` and now the same error log in the output.

build\vcpkg_installed\vcpkg\blds\libevent\config-x64-windows-static-
...

💬 sipa commented on pull request "Replace cluster linearization algorithm with SFL":
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-2928370752)
If people are interested in a much larger scale comparison between the old and the new algorithm:

```
# build bench_bitcoin
wget https://bitcoin.sipa.be/clusters/clusters.tgz
tar -xzf clusters.tgz
for F in clusters_sim2023_large clusters_medium clusters_spanning clusters_bipartite; do time ./build/bin/bench_bitcoin --filter="LinearizeDataSet" <~/$F >~/$F.out; done
tar -czf clusters.out.tgz clusters_*.out
```

And publish the resulting clusters.out.tgz file somewhere. The whole process
...

💬 maflcko commented on pull request "fee estimate test: fix #31944 by handling a legitimate scenario that …":
(https://github.com/bitcoin/bitcoin/pull/32615#discussion_r2120212961)
@tnndbtc I am wondering, are you using an "AI agent" or LLM to generate the iterations on this pull request?

💬 maflcko commented on pull request "wip: Split fuzz binary (take 2)":
(https://github.com/bitcoin/bitcoin/pull/30882#issuecomment-2929138831)
cc @dergoegge . the issue https://github.com/bitcoin/bitcoin/issues/28971 is still open, so I guess this pull can be closed or rebased?

💬 maflcko commented on pull request "wallet: Track no-longer-spendable TXOs separately":
(https://github.com/bitcoin/bitcoin/pull/27865#discussion_r2120269086)

“with it's default” -> “with its default” [“it's” is a contraction of “it is,” but here the possessive “its” is required]

💬 maflcko commented on pull request "cmake: Move internal binaries from bin/ to libexec/":
(https://github.com/bitcoin/bitcoin/pull/31679#discussion_r2120285755)

noticable -> noticeable [correct spelling]

💬 maflcko commented on pull request "Added rescan option for import descriptors":
(https://github.com/bitcoin/bitcoin/pull/31668#discussion_r2111188374)
nit: new code should put the `}` before the `else if`

💬 maflcko commented on pull request "Added rescan option for import descriptors":
(https://github.com/bitcoin/bitcoin/pull/31668#discussion_r2120302899)
not sure why this was marked resolved?

💬 l0rinc commented on pull request "headerssync: Keep tests ahead of increasing params":
(https://github.com/bitcoin/bitcoin/pull/32579#discussion_r2120449098)
> not sure about the structured bindings

That's what helped me in [noticing](https://github.com/bitcoin/bitcoin/pull/32579#discussion_r2108817538) that we weren't checking `request_more`

💬 l0rinc commented on pull request "headerssync: Keep tests ahead of increasing params":
(https://github.com/bitcoin/bitcoin/pull/32579#discussion_r2120449675)
* they're simpler/less specific
* they're shorter (matters for these long lines)
* you're already changing them in other places

i.e. what's the point of keeping them as vectors when we don't actually need so much power?

💬 l0rinc commented on pull request "headerssync: Keep tests ahead of increasing params":
(https://github.com/bitcoin/bitcoin/pull/32579#discussion_r2120450540)
Based on the [Sonarcloud](https://corecheck.dev/bitcoin/bitcoin/pulls/32579) recommendations I eagerly checked which other constructors can be explicit, but [exploring](https://cplusplus.com/forum/general/168292/) your question in more detail it seems there's barely any advantage in explicit default constructors.

💬 l0rinc commented on pull request "headerssync: Keep tests ahead of increasing params":
(https://github.com/bitcoin/bitcoin/pull/32579#discussion_r2120450728)
It seems to be a mix indeed:
```bash
% find . -name "*.h" | grep '_' | wc -l
185
```
vs
```bash
% find . -name "*.h" | grep '-' | wc -l
39
```
and most of those are from the recent `ipc` changes:
```bash
% find . -name "*.h" | grep '-' | grep -v ipc | wc -l
11
```

it's just a nit from my part, but standard lib also uses underscores mostly (e.g. `string_view`) and in many [regexes](https://www.w3schools.com/jsref/jsref_regexp_wordchar.asp) the `\w`, i
...

✅ dergoegge closed a pull request: "wip: Split fuzz binary (take 2)"
(https://github.com/bitcoin/bitcoin/pull/30882)