💬 mzumsande commented on issue "Post startup stalling":
(https://github.com/bitcoin/bitcoin/issues/29281#issuecomment-1900665438)
Another question is how to deal with it after having a separate detection criterion.
The stalling logic is designed such that if we are in a situation where other peers are blocked by the staller, the staller will be disconnected (hopefully downloading the missing block from someone else and unblocking the other peers with unused download slots). In the situation here, there is probably no other peer blocked; we just want to get to the tip faster, rather than waiting for 10+ minutes (`BLOCK_DOW
...

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459252934)
done

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459253057)
took some of hte language, and explicitly defined each term

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459253223)
done

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459253328)
done

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459253396)
We use subtraction, and should try to handle that?

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459253460)
done

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459253539)
added comment

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459253631)
done

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459253686)
done

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459253728)
done

👍 murchandamus approved a pull request: "wallet: fix coin selection tracing to return -1 when no change pos"
(https://github.com/bitcoin/bitcoin/pull/29272#pullrequestreview-1833088422)
tACK with nit: e701982c741edd2182690ddf4628e4c079a5185e

💬 murchandamus commented on pull request "wallet: fix coin selection tracing to return -1 when no change pos":
(https://github.com/bitcoin/bitcoin/pull/29272#discussion_r1459228682)
There were a couple transactions before, each sending 10 BTC to the wallet itself. So the wallet should still have a balance of 50 – fees BTC, and presumably 3 UTXOs of 10 BTC, 10 BTC, and 30 - fees BTC. I‘m not sure why APS (avoid partial spend) would make a difference here. APS just means that we’ll force use of all coins associated with the same scriptpubkey at once rather than a single UTXO if there is address reuse, but it seems to me that funds are always sent to new addresses here.

It
...

💬 maflcko commented on pull request "Support self-hosted Cirrus workers on forks (and multi-user)":
(https://github.com/bitcoin/bitcoin/pull/29274#issuecomment-1900694553)
As for the other commits, as mentioned previously, I am not sure if this is really needed. But no objection, of course. (https://github.com/bitcoin/bitcoin/pull/29259#issuecomment-1895822246)

💬 remyers commented on pull request "wallet: fix coin selection tracing to return -1 when no change pos":
(https://github.com/bitcoin/bitcoin/pull/29272#discussion_r1459266681)
Thanks for the explanation; although the next test after this one does what you suggest, it doesn't trigger the fall-through APS path. I'll see if I can rework this test to better match a real APS situation.

💬 TheCharlatan commented on pull request "kernel: Remove dependency on CScheduler":
(https://github.com/bitcoin/bitcoin/pull/28960#discussion_r1459267014)
Would have to capture it then in the lambda, which seems less clear to me.

✅ ismaelsadeeq closed an issue: "Enable `maxfeerate` and `maxburnamount` as startup config options."
(https://github.com/bitcoin/bitcoin/issues/29217)

💬 ismaelsadeeq commented on issue "Enable `maxfeerate` and `maxburnamount` as startup config options.":
(https://github.com/bitcoin/bitcoin/issues/29217#issuecomment-1900697766)
Closing this, after @glozow feedback here https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1459131869

💬 ismaelsadeeq commented on pull request "RPC: Wallet: Add `maxfeerate` and `maxburnamount` startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#issuecomment-1900699310)
Thanks @glozow for your review.
Will put this PR in draft while addressing Approach feedback

📝 ismaelsadeeq converted_to_draft a pull request: "RPC: Wallet: Add `maxfeerate` and `maxburnamount` startup option"
(https://github.com/bitcoin/bitcoin/pull/29278)
This PR attempts to fix two issues

#29217
#29220

Firstly,
- Both `sendrawtransaction` and `testmempoolaccept` have the optional parameter `maxfeerate`.
When passed, this parameter ensures that any transactions with a fee rate higher than the specified `maxfeerate` value are rejected.

- `maxburnamount` is also an optional parameter for `sendrawtransaction`. When passed, it rejects transactions with unspendable outputs (e.g., 'datacarrier' outputs using the OP_RETURN opcode) greater t
...