💬 brunoerg commented on pull request "p2p: return `CSubNet` in `LookupSubNet`":
(https://github.com/bitcoin/bitcoin/pull/26078#issuecomment-1435068141)
Force-pushed addressing @vasild's review.

💬 brunoerg commented on pull request "Handle CJDNS from LookupSubNet()":
(https://github.com/bitcoin/bitcoin/pull/27071#issuecomment-1435079192)
> Subnetting does not make sense for tor/i2p/cjdns
> It follows that banman is doing something that does not make sense (e.g. subnetting tor). This is the root of the problem. I think if that is eradicated, then the rest will untangle by itself.

`CConnman::DisconnectNode` also handles addresses as subnets. Is this a problem?

🚀 achow101 merged a pull request: "net: avoid overriding non-virtual ToString() in CService and use better naming"
(https://github.com/bitcoin/bitcoin/pull/25619)

💬 yancyribbens commented on pull request "refactor: Move coin_control variable to test setup section":
(https://github.com/bitcoin/bitcoin/pull/26154#issuecomment-1435080650)
@jonatack thanks for the response. I agree with you that feedback is not just a technical process but also a social one. You're links also help as well.

@achow101 @MarcoFalke thanks for taking the time to review.

💬 yancyribbens commented on pull request "refactor: Move coin_control variable to test setup section":
(https://github.com/bitcoin/bitcoin/pull/26154#issuecomment-1435081051)
s/you're/your

✅ pinheadmz closed an issue: "on OSX, bitcoind chooses different data directory than Bitcoin-Qt"
(https://github.com/bitcoin/bitcoin/issues/27119)

💬 pinheadmz commented on issue "on OSX, bitcoind chooses different data directory than Bitcoin-Qt":
(https://github.com/bitcoin/bitcoin/issues/27119#issuecomment-1435081900)
This is my fault, there were old Qt preferences saved and the custom directory was recalled from there

💬 yancyribbens commented on pull request "wallet: Guard against undefined behaviour":
(https://github.com/bitcoin/bitcoin/pull/25982#issuecomment-1435094706)
@MarcoFalke it looks like the following test_case [here](https://github.com/bitcoin/bitcoin/blob/35fbc972082eca0fc848fba77360ff35f1ba69e1/src/wallet/test/coinselector_tests.cpp#L949) was added after I made the PR (that test doesn't exist in my PR branch).

The `cost_of_change` should always be greater than zero so something is wrong with the test case. However, there doesn't seem to be much enthusiasm for this PR so its probably not worth it for me to spend time fixing it unless I get feed
...

💬 achow101 commented on pull request "p2p: ProcessAddrFetch(-seednode) is unnecessary if -connect is specified":
(https://github.com/bitcoin/bitcoin/pull/20018#issuecomment-1435121819)
ACK 2555a3950f0304b7af7609c1e6c696993c50ac72

🚀 achow101 merged a pull request: "p2p: ProcessAddrFetch(-seednode) is unnecessary if -connect is specified"
(https://github.com/bitcoin/bitcoin/pull/20018)

💬 ryanofsky commented on pull request "refactor, kernel: Remove gArgs accesses from dbwrapper and txdb":
(https://github.com/bitcoin/bitcoin/pull/25862#issuecomment-1435133240)
This has 2 code reviews. Not sure if it might be ready for merge, or if it needs another reviewer.

💬 Xekyo commented on pull request "Detect and ignore transactions that were CPFP'd in the fee estimator":
(https://github.com/bitcoin/bitcoin/pull/25380#issuecomment-1435138448)
Concept ACK

Did some light review, looks reasonable

💬 ryanofsky commented on pull request "RPC: Accept options as named-only parameters":
(https://github.com/bitcoin/bitcoin/pull/26485#issuecomment-1435149596)
Rebased d936e991a63db798c9ac68238c5c48d42cdd65c7 -> 7fd1401d8116323adfa2a87bbcf6ea41437cd0fa ([`pr/nonly.10`](https://github.com/ryanofsky/bitcoin/commits/pr/nonly.10) -> [`pr/nonly.11`](https://github.com/ryanofsky/bitcoin/commits/pr/nonly.11), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/nonly.10-rebase..pr/nonly.11)) due to conflict with #25344

💬 ponury1990 commented on pull request "p2p: ProcessAddrFetch(-seednode) is unnecessary if -connect is specified":
(https://github.com/bitcoin/bitcoin/pull/20018#issuecomment-1435256582)
Boje się spytać o wymagania systemowe sprzętu użytkownika w tym wypadku mnie

📝 sipa opened a pull request: "BIP341 txdata cannot be precomputed without spent outputs"
(https://github.com/bitcoin/bitcoin/pull/27122)
In `PrecomputedTransactionData::Init`, if `force` is set to `true`, `m_bip341_taproot_ready` is always set to true, suggesting that all its BIP341-relevant members (including `m_spent_amounts_single_hash`) are correct. If however no `spent` array of spent previous `CTxOut`s is provided, some of these members will be incorrect.

That doesn't actually hurt, as without prevout data, it's fundamentally impossible to generate correct BIP341 signatures anyway, and https://github.com/bitcoin/bitcoin/
...

💬 sipa commented on pull request "BIP341 txdata cannot be precomputed without spent outputs":
(https://github.com/bitcoin/bitcoin/pull/27122#issuecomment-1435298751)
Note that this shouldn't affect any consensus logic, as `spent` is always provided in that setting.

💬 mistercx commented on issue "Hidden fee (about 15% of sum) while send":
(https://github.com/bitcoin/bitcoin/issues/27120#issuecomment-1435299225)
Thanks for your help. I read about UTXO-model, so wallets with sum 0.0199924 and 0.00997949 is my addresses too, but for changes? I will be very grateful if you explain to me: how did these changes formed? From what amount? On my specific example, if possible. I do not understand the algorithm of this process for now.

💬 sipa commented on issue "Hidden fee (about 15% of sum) while send":
(https://github.com/bitcoin/bitcoin/issues/27120#issuecomment-1435307940)
Questions about how Bitcoin works are off-topic here, but you can find resource in other places. For example see https://bitcoin.stackexchange.com/a/738/208 about how change works.

✅ sipa closed an issue: "Hidden fee (about 15% of sum) while send"
(https://github.com/bitcoin/bitcoin/issues/27120)

💬 achow101 commented on pull request "refactor, kernel: Remove gArgs accesses from dbwrapper and txdb":
(https://github.com/bitcoin/bitcoin/pull/25862#issuecomment-1435311822)
ACK aadd7c5b9b43a38beaa954b4cb8c2fff55f2200f