💬 achow101 commented on pull request "util: improve FindByte() performance":
(https://github.com/bitcoin/bitcoin/pull/19690#issuecomment-1518201999)
ACK 0fe832c4a4b2049fdf967bca375468d5ac285563

👍 john-moffett approved a pull request: "util: improve FindByte() performance"
(https://github.com/bitcoin/bitcoin/pull/19690#pullrequestreview-1396277513)
ACK 0fe832c4a4b2049fdf967bca375468d5ac285563

💬 achow101 commented on pull request "blockstorage: do not flush block to disk if it is already there":
(https://github.com/bitcoin/bitcoin/pull/27039#discussion_r1174134793)
> The only way I could think of to do that is to read and checksum the file, and compare the checksums instead of the timestamps.

Isn't the point that the file contents aren't changing? So checksum wouldn't work because the files will be the same whether it's rewritten or not. The only things that can be different are the filesystem's metadata on the modification time.

💬 hebasto commented on pull request "build: use latest config.{guess,sub} in depends":
(https://github.com/bitcoin/bitcoin/pull/27508#issuecomment-1518321534)
My Guix builds:
```
fef9152d593aa1cb3243f37b8c069ef863f4e270962e17918cfa83e18c9eac3a guix-build-4a3f1db4ea5f/output/aarch64-linux-gnu/SHA256SUMS.part
3fa8236cea2ba1a08d0caf677de80f798f2594cb208f10e5dfe0a9a71de7978d guix-build-4a3f1db4ea5f/output/aarch64-linux-gnu/bitcoin-4a3f1db4ea5f-aarch64-linux-gnu-debug.tar.gz
36409f4fa6acfb577d6e6a43c2fda2d81f1fb6fb4e5d90cbaa65a2dbb26d1c23 guix-build-4a3f1db4ea5f/output/aarch64-linux-gnu/bitcoin-4a3f1db4ea5f-aarch64-linux-gnu.tar.gz
02a62c4cc2ecb63b
...

⚠️ inmortalbobz opened an issue: "I believe #10072 should help with bip9-softforks."
(https://github.com/bitcoin/bitcoin/issues/27514)
I believe #10072 should help with bip9-softforks.

_Originally posted by @jnewbery in https://github.com/bitcoin/bitcoin/issues/10052#issuecomment-289143384_

✅ fanquake closed an issue: "I believe #10072 should help with bip9-softforks."
(https://github.com/bitcoin/bitcoin/issues/27514)

:lock: fanquake locked an issue: "I believe #10072 should help with bip9-softforks."
(https://github.com/bitcoin/bitcoin/issues/27514)

💬 pinheadmz commented on pull request "blockstorage: do not flush block to disk if it is already there":
(https://github.com/bitcoin/bitcoin/pull/27039#discussion_r1174158220)
> The only things that can be different are the filesystem's metadata on the modification time, and these are not covered by a checksum.

It might be the same usefulness actually, I seem to remember that if file contents aren't changed, when you call `fwrite()` or `fflush()`, the modification timestamp won't be updated. I researched different ways to detect a `fflush()` and this unit test was the closest. Most systems flush when `fwrite()` is called, and then a subsequent `fflush()` doesn't do
...

👍 hebasto approved a pull request: "build: use latest config.{guess,sub} in depends"
(https://github.com/bitcoin/bitcoin/pull/27508#pullrequestreview-1396401127)
ACK 4a3f1db4ea5f90277cf7f57c051a2285e8b42468, I've got zero diff with files from the [upstream](https://git.savannah.gnu.org/gitweb/?p=config.git;a=tree).

💬 achow101 commented on pull request "util: improve FindByte() performance":
(https://github.com/bitcoin/bitcoin/pull/19690#issuecomment-1518398802)
Silent merge conflict with master:

```
../../../src/bench/streams_findbyte.cpp:7:10: fatal error: fs.h: No such file or directory
7 | #include <fs.h>
| ^~~~~~
compilation terminated.
```

👋 ishaanam's pull request is ready for review: "rpc: add `descriptorprocesspsbt` rpc"
(https://github.com/bitcoin/bitcoin/pull/25796)

💬 ishaanam commented on pull request "rpc: add `descriptorprocesspsbt` rpc":
(https://github.com/bitcoin/bitcoin/pull/25796#issuecomment-1518475401)
Now that #25939 has been merged, this is now ready for review.

⚠️ TheBlueMatt opened an issue: "Consider Removing Message Signing"
(https://github.com/bitcoin/bitcoin/issues/27515)
### Please describe the feature you'd like to see added.

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, and its not clear what the semantics for such things would be.

Sadly, the message signing feature is now being abused to "verify wallets" as a part of withdraw flows. This p
...

💬 achow101 commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518499610)
> If someone comes along with a proposal that considers a broader set of scripts and a more sensible design that could be considered.

[BIP 322](https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki)? (#24058)

💬 jaybny commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518502352)
what percentage of bitcoiners still use single-sig keys? P2PKH is perfect for most use cases. what is the problem? please stop this. leave the feature.

💬 weedcoder commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518506467)
as @achow101 said BIP322.
proof of funds is a must have.

💬 elkimek commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518524010)
You don't fight bullies with hiding and give up things. You push back like people did when Trezor implemented AOPP.

💬 thibistaken commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518529552)
What about key health checks? Allows a user to verify the key they control can still sign a given address, without broadcasting it to the network. It's free and private. Sounds pretty useful.

💬 vasild commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1518536516)
> potentially uniquely identifying UA comment, or other fingerprints in the version message

added to the TODO in the OP

> One shot connections + immediate tx broadcast without inv,getdata exchange leaks that the tx is likely being broadcast for the first time (easy to censor the tx as the receiver).

Yes. I was thinking its probably ok to broadcast to a few peers, not just one. And if they blackhole it, then the code will retry. We can retry more aggressively if it keeps being blackholed
...

💬 bitnorbert commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518538877)
> What about key health checks? Allows a user to verify the key they control can still sign a given address, without broadcasting it to the network.

Would arguably be better to do such checks by signing a transaction and not broadcasting it.