👍 cbergqvist approved a pull request: "cli: Detect port errors in rpcconnect and rpcport"
(https://github.com/bitcoin/bitcoin/pull/29521#pullrequestreview-2046768298)
reACK 867a673bcfd3ca254c306d8cf0c68d4ceb163f97

Inspected `git range-diff cb4f9fc~2..cb4f9fc 867a673~2..867a673`.

Passed `--extended` functional tests (-`feature_dbcrash`, excluded, some others skipped due to configuration). Passed `make check`.

💬 cbergqvist commented on pull request "cli: Detect port errors in rpcconnect and rpcport":
(https://github.com/bitcoin/bitcoin/pull/29521#discussion_r1594717462)
(IMO it's slightly cleaner to split the test into `--ipv4` and `--ipv6` variants similar to `rpc_bind.py`, that way it becomes explicit whether that part of the test coverage is being skipped or not. This being more of a parsing-test, I guess it is not on the critical end of the spectrum. Also it's just a minor part of `interface_bitcoin_cli.py` so I completely understand the resistance to breaking it out).

🚀 achow101 merged a pull request: "rpc: improve submitpackage documentation and other improvements"
(https://github.com/bitcoin/bitcoin/pull/29292)

💬 IAmAdamRest commented on issue "Possible to Ban Clients by Name?":
(https://github.com/bitcoin/bitcoin/issues/30036#issuecomment-2101665505)
Pretty trashy to delete a message urging others with the same issue to contact the local secret service office, they are VERY aware of this issue. I wouldn't have known that comment was made had you guys not deleted it... have something to hide?

💬 IAmAdamRest commented on issue "Possible to Ban Clients by Name?":
(https://github.com/bitcoin/bitcoin/issues/30036#issuecomment-2101677490)
Ya'll are being so shady with this. I hope you know the secret service has found one of the core developers to be doing something highly illegal here and they are so dang close to coming down on ya'll for it.

:lock: fanquake locked an issue: "Possible to Ban Clients by Name?"
(https://github.com/bitcoin/bitcoin/issues/30036)

⚠️ gmart7t2 opened an issue: "decoderawtransaction should use hex or decimal, not both"
(https://github.com/bitcoin/bitcoin/issues/30067)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

I have two different op_return outputs, but they are shown identically in their "asm" decoding:

```
"scriptPubKey": {
"asm": "OP_RETURN 1431655765",
"hex": "6a051431655765",
}
```

```
"scriptPubKey": {
"asm": "OP_RETURN 1431655765",
"hex": "6a0455555555",
}
```

One shows the hex value. The other shows the decimal va
...

💬 sipa commented on issue "decoderawtransaction should use hex or decimal, not both":
(https://github.com/bitcoin/bitcoin/issues/30067#issuecomment-2101692041)
Duplicate of #27795 ?

📝 kevkevinpal opened a pull request: "test: assert can't activate snapshot based chainstate more than once"
(https://github.com/bitcoin/bitcoin/pull/30068)
In ActivateSnapshot we return false if there already exists a snapshot-based chainstate this is a test that asserts that happens

This adds coverage to [this part of the codebase](https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L5477)

🚀 fanquake merged a pull request: "build, test: Remove unused `TIMEOUT` environment variable"
(https://github.com/bitcoin/bitcoin/pull/30063)

💬 edilmedeiros commented on issue "RFC: "Insufficient review" tag for closed PRs":
(https://github.com/bitcoin/bitcoin/issues/29839#issuecomment-2101856850)
I like the idea.

Since we are brainstorming how to get more attention to review, what about also having a tag for PRs related to projects that the core developers defined as priority for the current release cycle (`priority`)?

This will tend to attract more review effort overall, even for those more complex changes. It's not required for experienced reviewers since they can easily identify those from context. On the other hand, it might indicate to newbies like me what to pick if I would like
...

⚠️ foolbear opened an issue: "Load PSBT error: Unable to decode PSBT"
(https://github.com/bitcoin/bitcoin/issues/30070)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

"Load PSBT from ..." from menu, error shows:
`Unable to decode PSBT
Unsigned tx does not have empty scriptSigs and scriptWitnesses.: unspecified iostream_category error`

decodepsbt and analyzepsbt show the same error too:
`TX decode failed Unsigned tx does not have empty scriptSigs and scriptWitnesses.: unspecified iostream_category error (code -22)`

### Expected behaviour

Load PS
...

💬 ajtowns commented on pull request "crypto: add `NUMS_H` const":
(https://github.com/bitcoin/bitcoin/pull/30048#discussion_r1594997390)
nit: Would it be better to make this a `static const` member of the `XOnlyPubKey` class?

💬 josibake commented on pull request "crypto: add `NUMS_H` const":
(https://github.com/bitcoin/bitcoin/pull/30048#discussion_r1595049543)
Can you elaborate? Not clear to me what the benefit would be.

💬 laanwj commented on issue "libxcb-xinerama0 Library required by bitcoin-qt":
(https://github.com/bitcoin/bitcoin/issues/30061#issuecomment-2102081195)
> @laanwj Does https://github.com/bitcoin/bitcoin/pull/29923 address this?

Potentially it could make the dependency on xcb-xinerama optional. There's only a few functions used from that library, for a specific purpose (multiple monitor support), if the library can't be loaded, it can be assumed that this functionality isn't needed. This does mean patching Qt though.

)i've handled the xcb/wayland switch in that way--if X libraries can't be found, don't exit, but fail loading the XCB platfor
...

💬 Sjors commented on pull request "Reintroduce external signer support for Windows":
(https://github.com/bitcoin/bitcoin/pull/29868#issuecomment-2102082445)
I assume you added b69b9e85e98cac2c7585c9b613185dc6c80320cc because it no longer uses an external dependency?

Is there something you can remove from cpp-subprocess based on your comment? https://github.com/bitcoin/bitcoin/pull/29961#issuecomment-2100521158

💬 laanwj commented on pull request "net: Replace libnatpmp with built-in PCP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#issuecomment-2102107669)
> Would prefer this in two steps (add PCP, then remove NAT-PMP)

i'm not planning to do this, the build system commits are already set up this way, but doing it throughout would involve adding another setting in Qt just to remove it later. Same for adding a third mechanism in `portmap.cpp`. Agree with @sjors that having a forest of different port mapping settings is confusing to the user.

💬 Sjors commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2102131750)
@emsit wrote:

> Is there a plan to replace the path '/testnet3' with '/testnet'?

That's a mistake in the documentation, the behavior isn't changed.

@wiz wrote:

> because his node doesn't know about any yet.

Or not anymore. The seed requires some amount of recent uptime. I had one running as well, but it was on an earlier genesis block. Fixed, there goes my premine :-)

My node found your peers and synced to the tip.

> If you were able to quickly cycle the difficulty back dow
...

📝 threewebcode opened a pull request: "chore: fix some typos"
(https://github.com/bitcoin/bitcoin/pull/30071)
fix some typos

<!--
*** 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
...

💬 josibake commented on pull request "crypto, refactor: add method for applying the taptweak":
(https://github.com/bitcoin/bitcoin/pull/30051#discussion_r1595092731)
Nice, thanks for the suggestion! This makes a ton more sense. I think it would be better to have the ctor take a pointer to the merkle root because `ApplyTapTweak` is something that you a) only want to do once over the lifetime of the object and b) will always be applied if a `merkle_root` is present (even if its `merkle_root.IsNull() == true`). I don't think this is actually a use case, but if for whatever reason you did need to do something with the key and then later apply a merkle root tweak
...