💬 Sjors commented on pull request "Stratum v2 Template Provider (take 2)":
(https://github.com/bitcoin/bitcoin/pull/28983#issuecomment-1914277528)
(I plan to rebase this after some other stuff is merged)

💬 vostrnad commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1914287655)
@theDavidCoen "Default off everything" is not at all how Bitcoin Core development works. If it did, the node would by default not communicate with the network (`-networkactive`), broadcast wallet transactions (`-walletbroadcast`), persist the mempool between restarts (`-persistmempool`) etc. It would also mean you can just rename an option (e.g. `-permitbaremultisig` to `-disablebaremultisig`) to force the opposite default.

How it actually (usually) works is the default parameters are changed
...

💬 glozow commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1469291356)
Maybe add tests where you (successfully) configure the node's wallet using `-maxfeerate`?

💬 glozow commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1469296961)
1000 is redundant

💬 glozow commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1469293744)
Similarly, it would be good to test that both maxfee and maxfeerate requirements must be met.

💬 Sjors commented on pull request "Silent payment index (for light wallets and consistency check)":
(https://github.com/bitcoin/bitcoin/pull/28241#issuecomment-1914312450)
Will do soon(tm)

✅ willcl-ark closed an issue: "Unable to open wallet UI with ubuntu 23.10"
(https://github.com/bitcoin/bitcoin/issues/29311)

💬 willcl-ark commented on issue "Unable to open wallet UI with ubuntu 23.10":
(https://github.com/bitcoin/bitcoin/issues/29311#issuecomment-1914316466)
I think we can close this out for now as it appears to have been a `fontconfig` issue which is now resolved.

💬 naumenkogs commented on pull request "Nuke adjusted time from validation (attempt 2)":
(https://github.com/bitcoin/bitcoin/pull/28956#issuecomment-1914324428)
ACK ff9039f6ea876bab2c40a06a93e0dd087f445fa2

After a few attempts, I haven't found a way to trigger a consensus fork through adjusted time. It's not like this could "infect" half of the network (legacy) through block propagation or something. Because of that, if there was/is a legacy way to exploit it (say an overflow in `nTimeOffset` calculation), this new code won't make it worse.

💬 naumenkogs commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#issuecomment-1914329134)
ACK bc9283c4415a932ec1eeb70ca2aa4399c80437b3

💬 naumenkogs commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1464523738)
This comes unexpectedly. This is merely an unintentional side-effect of saving LOC in this test, right?

💬 naumenkogs commented on pull request "addrman: delete addresses that don't belong to the supported networks":
(https://github.com/bitcoin/bitcoin/pull/29330#issuecomment-1914343607)
Having these records around might be useful too, if you go back to those networks.

Do we have any practical problems with these Select calls? Too much CPU time, orz disk reads, or memory use?

Not only this would motivate this code change and review use better, but also it would help us understand under which circumstances a node operator might actually want to do this....And then maybe the right thing would be to trigger this cleaning automatically rather than thinking a user will trigger
...

💬 fanquake commented on issue "Clang 14 emits `-Wunreachable-code` warnings":
(https://github.com/bitcoin/bitcoin/issues/29334#issuecomment-1914349106)
> It might require some efforts if building routines involve -Werror.

Wouldn't you just pass `-Wno-unreachable-code` ?

In any case, I don't think there's anything else we can do here, other than suggest using a fixed compiler and/or stop using `-Werror`.

💬 jsarenik commented on issue "Use different datadirs for different signets":
(https://github.com/bitcoin/bitcoin/issues/27494#issuecomment-1914401279)
I think that following scripts are related and may serve as inspiration while keeping backward-compatibility.

## bch.sh

For bitcoin-cli, this is bch.sh ("bitcoin cli here")

```sh
#!/bin/sh

test -d "$1" && { cd "$1"; shift; }
test -d .bitcoin && cd .bitcoin

# Handling of inside-the-wallet-dir cases
echo $PWD | grep -q '/wallets' && {
mypwd=$PWD
until test "${PWD##*/}" = "wallets"; do cd ..; done
wn=${mypwd##$PWD/}
w="-rpcwallet=${wn}"
test "$1" = "loadwallet" && a
...

👍 0xB10C approved a pull request: "test: create deterministic addrman in the functional tests"
(https://github.com/bitcoin/bitcoin/pull/29007#pullrequestreview-1848342275)
ACK 2cc8ca19f4185490f30a49516c890b2289fbab71

Code review and played around with the new `-test` option.

💬 0xB10C commented on pull request "test: create deterministic addrman in the functional tests":
(https://github.com/bitcoin/bitcoin/pull/29007#discussion_r1469388717)
nit: I think this makes the error slightly clearer
```suggestion
return InitError(Untranslated("-test=<option> can only be used when on regtest"));
```

💬 maflcko commented on pull request "test: Handle functional test disk-full error":
(https://github.com/bitcoin/bitcoin/pull/29335#discussion_r1469392954)
I wonder if the check could be done upfront, to not even run any test, if it is unclear whether the device will even hold enough to run the tests.

💬 stickies-v commented on pull request "test: ensure output is large enough to pay for its fees":
(https://github.com/bitcoin/bitcoin/pull/29283#discussion_r1469395573)
Thanks for reporting this @maflcko, need to round the minimum value to 8 decimals to fix this. Opening a pull now.

💬 josibake commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1469368423)
I think we should keep the word "wallet" here, since this is a client set option. If you look at the RPC call above, it differentiates between the node wide policy of `relayMinFee` and the wallet set policy `m_min_fee` by adding the world "wallet" to the RPC error.

🤔 josibake reviewed a pull request: "Wallet: Add `maxfeerate` wallet startup option"
(https://github.com/bitcoin/bitcoin/pull/29278#pullrequestreview-1848310090)
It seems odd to me that we would ever have `maxtxfee` and `maxfeerate` set together as they seem to cover entirely different scenarios.

For `maxtxfee`, a user is expressing "I don't or care what my transaction size is but I know I never want to spend more than X in total fees."

For `maxfeerate` as user is expressing "I know that my transactions will vary a lot in size, so I don't know what the total fees will be, but I do know that I don't want to pay more than X sats/per vbyte."

I am s
...