:lock: fanquake locked an issue: "I believe #10072 should help with bip9-softforks."
(https://github.com/bitcoin/bitcoin/issues/27514)
(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
...
(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).
(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.
```
(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)
(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.
(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
...
(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)
(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.
(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.
(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.
(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.
(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
...
(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.
(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.
💬 GregTonoski commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518560156)
> Sadly, the message signing feature is now being abused to "verify wallets" as a part of withdraw flows
Abusers may resolve the issue themselves and there isn't any Bitcoin Core change that could stop them. I suggest contacting abusers instead of Bitcoin Core community.
Besides, users like the message signing feature. Not only in Bitcoin Core. There are many wallets that implement it.
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518560156)
> Sadly, the message signing feature is now being abused to "verify wallets" as a part of withdraw flows
Abusers may resolve the issue themselves and there isn't any Bitcoin Core change that could stop them. I suggest contacting abusers instead of Bitcoin Core community.
Besides, users like the message signing feature. Not only in Bitcoin Core. There are many wallets that implement it.
💬 furszy commented on pull request "wallet: when a block is disconnected, update transactions that are no longer conflicted":
(https://github.com/bitcoin/bitcoin/pull/27145#discussion_r1174395264)
Yeah, nothing biggie, just:
```c++
auto try_updating_state = [disconnect_height](CWalletTx& tx) {
```
so only the required elements are provided to the lambda.
(https://github.com/bitcoin/bitcoin/pull/27145#discussion_r1174395264)
Yeah, nothing biggie, just:
```c++
auto try_updating_state = [disconnect_height](CWalletTx& tx) {
```
so only the required elements are provided to the lambda.
💬 furszy commented on pull request "wallet: when a block is disconnected, update transactions that are no longer conflicted":
(https://github.com/bitcoin/bitcoin/pull/27145#discussion_r1174393895)
Can remove the context ref.
```suggestion
auto try_updating_state = [](CWalletTx& wtx) EXCLUSIVE_LOCKS_REQUIRED(cs_wallet) {
```
(https://github.com/bitcoin/bitcoin/pull/27145#discussion_r1174393895)
Can remove the context ref.
```suggestion
auto try_updating_state = [](CWalletTx& wtx) EXCLUSIVE_LOCKS_REQUIRED(cs_wallet) {
```
💬 amtriorix commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518646177)
Are you nuts or what?!
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518646177)
Are you nuts or what?!
💬 aceofbitcoin commented on issue "Consider Removing Message Signing":
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518653817)
You can indeed use your private keys of bitcoin to digitally sign messages. If You don't understand the basics of assymetric keys used to sign/verify transactions, messages or any text, You should first read more books about pgp, bitcoin and assymmetric encryption. I really don't like such noob proposals. #satoshin
(https://github.com/bitcoin/bitcoin/issues/27515#issuecomment-1518653817)
You can indeed use your private keys of bitcoin to digitally sign messages. If You don't understand the basics of assymetric keys used to sign/verify transactions, messages or any text, You should first read more books about pgp, bitcoin and assymmetric encryption. I really don't like such noob proposals. #satoshin
💬 Tracachang commented on issue "Export a watch wallet only (with descriptors and without private keys) for an air gap setup":
(https://github.com/bitcoin/bitcoin/issues/24829#issuecomment-1518657586)
> > Just tried again following this commands and I am still unable to see taproot in GUI
>
> at all? or just in the watch-only wallet?
Just on GUI with the watch-only wallet, but on console using watch-only I can create taproot receiving addresses.
(https://github.com/bitcoin/bitcoin/issues/24829#issuecomment-1518657586)
> > Just tried again following this commands and I am still unable to see taproot in GUI
>
> at all? or just in the watch-only wallet?
Just on GUI with the watch-only wallet, but on console using watch-only I can create taproot receiving addresses.