💬 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

🚀 achow101 merged a pull request: "refactor, kernel: Remove gArgs accesses from dbwrapper and txdb"
(https://github.com/bitcoin/bitcoin/pull/25862)

💬 mzumsande commented on pull request "p2p, rpc: Manual block-relay-only connections with addnode":
(https://github.com/bitcoin/bitcoin/pull/24170#discussion_r1110405441)
Not sure about this: Currently, the help for "addnode" states that only `=manual-block-relay` is possible (manual is the default). Adding this to the help might only complicate things for the user, because there would be no difference between `=manual` and no argument at all?

💬 mzumsande commented on pull request "p2p, rpc: Manual block-relay-only connections with addnode":
(https://github.com/bitcoin/bitcoin/pull/24170#discussion_r1110406081)
I agree that it would be more consistent and added a commit to do this - I'll check how many additional conflicts this introduces...

💬 mzumsande commented on pull request "p2p, rpc: Manual block-relay-only connections with addnode":
(https://github.com/bitcoin/bitcoin/pull/24170#discussion_r1110406730)
It's used in `net_processing` in places suchas `ConsiderEviction()` where we wouldn't want to consider manual connections.
I think the name "IsOutboundOrBlockRelayConn" isn't ideal (even before this PR, because manual connections are also outbound connections), maybe the name "IsAutomaticOutboundOrBlockRelayConn" would be better. I added a commit to do that.

💬 TheCharlatan commented on pull request "refactor: make some BlockManager members const":
(https://github.com/bitcoin/bitcoin/pull/26664#issuecomment-1435327146)
Concept ACK

It won't make a difference to any callers of the `BlockManager`, but I think you could mark `FlushUndoFile` as `const` as well.

💬 mzumsande commented on pull request "p2p, rpc: Manual block-relay-only connections with addnode":
(https://github.com/bitcoin/bitcoin/pull/24170#discussion_r1110407979)
Yes, I think it makes sense as a follow-up! Though, if I'm not missing something we don't even support regular MANUAL connections there, so adding support for these would make sense as well?

💬 mzumsande commented on pull request "p2p, rpc: Manual block-relay-only connections with addnode":
(https://github.com/bitcoin/bitcoin/pull/24170#discussion_r1110408410)
I think I prefer the more concise version here, especially when most of the args are just defaults that are set to their actual values in the following lines.

💬 mzumsande commented on pull request "p2p, rpc: Manual block-relay-only connections with addnode":
(https://github.com/bitcoin/bitcoin/pull/24170#discussion_r1110408474)
done

💬 mzumsande commented on pull request "p2p, rpc: Manual block-relay-only connections with addnode":
(https://github.com/bitcoin/bitcoin/pull/24170#discussion_r1110408583)
done

💬 mistercx commented on issue "Hidden fee (about 15% of sum) while send":
(https://github.com/bitcoin/bitcoin/issues/27120#issuecomment-1435331129)
Thanks to all! The main meaning is here:

`Because the client manages coins in a particular way, it doesn't make sense to try to view coins it is managing with any kind of explorer. It's specifically trying to obscure the fact that all the coins are related. Those kinds of services are intended to monitor recieved funds, not managed funds.`