💬 jlopp commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518705299)
I'll note that message signing is an important feature we leverage for Casa clients to perform health checks on their keys and hardware devices without requiring them to actually sign a transaction. While at the software level, arbitrary signing of data with private keys could be accomplished pretty much however one wishes, it's important to us that a message signing standard exists so that there's a well defined spec for hardware device companies to support.

💬 theStack commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518711328)
> BIP 322 is great, but isn't super practical to verify unless you have a full script interpreter (ie are Core).

In theory, using [libconsensus](https://github.com/bitcoin/bitcoin/blob/master/doc/shared-libraries.md) for that shouldn't be too hard, especially if a proper language binding is available? (Though admittedly, it still lacks Taproot support -- https://github.com/bitcoin/bitcoin/pull/21158 is up for grabs).

💬 sipa commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518711858)
BIP322 doesn't actually need full script validation if partiality is acceptable (e.g. a verifier can just implement a specific templated subset of scripts, and reply inconclusive for anything beyond that). That may sound suboptimal, but a scheme that's restricted by design to some subset cannot do better either.

💬 mzumsande commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518718755)
some previous discussion in #24186.

💬 harding commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518723971)
> Signing arbitrary messages with Bitcoin private keys was always a bit strange. It was designed to handle only the narrow case of single-sig keys, and isn't well-defined for new address types. Worse, it doesn't allow for signing messages with more arbitrary scripts

LN requires channel owners sign their gossip messages in order to use the costliness of acquiring a UTXO to prevent DoS attacks. Both currently and in [proposed changes](https://lists.linuxfoundation.org/pipermail/lightning-dev/2
...

💬 dimitaracev commented on pull request "validation: Replace MinBIP9WarningHeight with MinBIP9WarningStartTime":
(https://github.com/bitcoin/bitcoin/pull/27427#discussion_r1174466477)
I think `std::max(MinBIP9WarningHeight, nMinerConfirmationWindow)` is unnecessary since I doubt that `nMinerConfirmationWindow` would be higher than `MinBIP9WarningHeight`. As for the rest, it makes sense since it removes the burden of having to keep in mind that a parameter would need adjusting in the future. I initially changed it to a timestamp due to your comment on the other PR :smile:.

💬 yashviradia commented on issue "listtransactions results order unkown":
(https://github.com/bitcoin/bitcoin/issues/17739#issuecomment-1518889742)
Hi,
Is this issue still open? Then I would like to work on it.

📝 theStack opened a pull request: "test: simplify uint256 (de)serialization routines"
(https://github.com/bitcoin/bitcoin/pull/27516)
These routines look fancy, but do nothing more than converting between byte objects of length 32 to/from integers in little endian byte order and can be replaced by simple one-liners, using the `int.{from,to}_bytes` methods (available since Python 3.2).

💬 NicolasDorier commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518921583)
Just mentioning here that I removed the ability for message signing from NBitcoin a long time ago for same reasons.

People who really need it just have to code it themselves. (which is just a few lines you can get looking the history of NBitcoin's code)

💬 michaelfolkson commented on pull request "MiniTapscript: port Miniscript to Tapscript":
(https://github.com/bitcoin/bitcoin/pull/27255#discussion_r1174534364)
Is there a reason why the only two options are P2WSH and P2TR? Should there be a case statement for P2SH (`sh`) too?

💬 vasild commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1519011804)
@mzumsande, right, ideally, after the initial broadcast via the short-lived connection, the node should behave as if it does not know the tx:
* before it gets `INV` for that tx, exclude it from `GETDATA` and `MEMPOOL` replies
* if it gets `INV` for that tx, request the entire tx via `GETDATA`
* broadcast to others

🚀 fanquake merged a pull request: "build: use latest config.{guess,sub} in depends"
(https://github.com/bitcoin/bitcoin/pull/27508)

💬 fanquake commented on pull request "build: Use newest `config.{guess,sub}` available":
(https://github.com/bitcoin/bitcoin/pull/26422#issuecomment-1519022138)
Want to rebase this?

💬 hebasto commented on pull request "build: Use newest `config.{guess,sub}` available":
(https://github.com/bitcoin/bitcoin/pull/26422#issuecomment-1519026224)
> Want to rebase this?

Done.

📝 hebasto opened a pull request: "qt: 25.0rc2 translations update"
(https://github.com/bitcoin/bitcoin/pull/27517)
This PR follows our [Release Process](https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#before-every-release-candidate) and pulls the recent translations from the [Transifex.com](https://www.transifex.com/bitcoin/bitcoin) using the [`bitcoin-maintainer-tools/update-translations.py`](https://github.com/bitcoin-core/bitcoin-maintainer-tools/blob/main/update-translations.py) tool.

Unfortunately, it wasn't done before `v25.0rc1` tagging. Therefore, it is expected to be merged
...

⚠️ rebroad opened an issue: "I2P: connection issues"
(https://github.com/bitcoin/bitcoin/issues/27518)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Using the list of nodes in #23018 I am getting every single one failing:-

2023-04-23T11:34:39.798 I2P: Error connecting to gehtac45oaghz54ypyopim64mql7oad2bqclla74l6tfeolzmodq.b32.i2p:0: Unexpected reply to "NAMING LOOKUP NAME=gehtac45oaghz54ypyopim64mql7oad2bqclla74l6tfeolzmodq.b32.i2p": "NAMING REPLY RESULT=KEY_NOT_FOUND NAME=gehtac45oaghz54ypyopim64mql7oad2bqclla74l6tfeolzmodq.b32.i2
...

💬 fanquake commented on issue "I2P: connection issues":
(https://github.com/bitcoin/bitcoin/issues/27518#issuecomment-1519045483)
> Using the list of nodes in #23018
> expected a connection to succeed

I don't think expecting being able to connect to some 2 year old list of 2 (random) nodes is exactly reasonable.

💬 jonatack commented on issue "I2P: connection issues":
(https://github.com/bitcoin/bitcoin/issues/27518#issuecomment-1519055199)
Do you have other I2P connections working? If not, you may need to restart (or upgrade) your I2P router. What router and version are you using?

Some of the nodes no longer exist, but I'm connected to several of them right now. If you're looking for seed nodes, try the ones in `contrib/seeds/nodes_main_manual.txt`.

✅ fanquake closed an issue: "I2P: connection issues"
(https://github.com/bitcoin/bitcoin/issues/27518)

💬 hebasto commented on pull request "build: Use newest `config.{guess,sub}` available":
(https://github.com/bitcoin/bitcoin/pull/26422#issuecomment-1519056686)
The PR description has been updated with the recent Guix build hashes.