💬 ismaelsadeeq commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1477819038)
Fixed, thanks

💬 ismaelsadeeq commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1477819954)
fixed

💬 ismaelsadeeq commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1477823064)
I've implemented your suggestion 👍🏾

💬 ismaelsadeeq commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1477823251)
Fixed

💬 ismaelsadeeq commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1477823771)
Added thanks

💬 ismaelsadeeq commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1477828459)
Yes its 10'000 sat/vb, I agree its high indeed Should I reduce it to maybe 1000 s/vb instead?

---
This is configurable option can be reduced by users to threshold they want.

💬 glozow commented on issue "When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked":
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1926494531)
Is it blocked forever or until the block is finished processing? Can you provide more details about what your highly concurrent request is?

✅ willcl-ark closed an issue: "`libbitcoinconsensus.a` is unusable"
(https://github.com/bitcoin/bitcoin/issues/28779)

💬 willcl-ark commented on issue "`libbitcoinconsensus.a` is unusable":
(https://github.com/bitcoin/bitcoin/issues/28779#issuecomment-1926512812)
Closing following #29189

It seems like the rust-bitcoinconsensus folks are sufficiently aware of the deprecation of this lib and migration to libbitcoinkernel, and plan to possibly start a [new crate](https://github.com/rust-bitcoin/rust-bitcoinconsensus/issues/66#issuecomment-1925928670) based on the kernel libs.

💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1926573232)
> I’m interested if there is a full-branch with package-relay + v3 tx policy available somewhere.

To be clear, package relay with package RBF is meant to be resistant to these kinds of network topology aware (NTA) pinning scenarios. With correctly implemented package relay it doesn't matter that a CPFP tx did a CPFP on top of a commitment transaction that no-one but the originator has: provided the fee (or with RBFR, fee-rate) outbids the competing commitment transaction, it will be replaced
...

💬 fanquake commented on issue "When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked":
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1926579486)
> Package manager

Which package manager?

Can you provide any debug.log output?

💬 maflcko commented on pull request "util: check for errors after close and read in AutoFile":
(https://github.com/bitcoin/bitcoin/pull/29307#issuecomment-1926582804)
> > This class could `Assume` that the file was flushed/closed before the destructor is called?
>
> `Assume` is more for code correctness, not for external errors (like IO error).

The assumption would be that the close was called *before* the destructor is called. This is a code correctness question and seems like the perfect fit for Assume. That is, if the Assume fails, the code was missing a close, and the code must be changed to fix the internal bug. The Assume does not in any way check
...

💬 ismaelsadeeq commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1477927227)
> compare it with the resulting mining score instead of the new transaction’s individual feerate?

🤔 Not sure how to implement the change you suggested honestly.
The current behavour is checking if target fee rate of user wants to bump the transaction to is greater than `maxfeerate` which I believe is the new mining score of the bumped transaction no?
I might be wrong on my assumption though, would you clarify your comment please? thanks.

⚠️ hebasto opened an issue: "build: `CPPFLAGS` usage in OSS-Fuzz"
(https://github.com/bitcoin/bitcoin/issues/29385)
In OSS-Fuzz, dependencies are built with `DEBUG=1`, which implies usage of the additional preprocessor definitions:

```
$ make -C depends print-host_debug_CPPFLAGS HOST=x86_64-pc-linux-gnu DEBUG=1
...
host_debug_CPPFLAGS=-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC -D_LIBCPP_ENABLE_DEBUG_MODE=1
```

However, explicit setting `CPPFLAGS` breaks this assumption:
```
$ make -C depends print-host_debug_CPPFLAGS HOST=x86_64-pc-linux-gnu DEBUG=1 CPPFLAGS="-DBOOST_MULTI_INDEX_ENABLE_SAFE_MODE"
...

💬 maflcko commented on issue "build: `CPPFLAGS` usage in OSS-Fuzz":
(https://github.com/bitcoin/bitcoin/issues/29385#issuecomment-1926623041)
Reference: https://github.com/google/oss-fuzz/blob/c801e7aab5822e0c305fdb88dbe21b834d45afea/projects/bitcoin-core/build.sh#L38

💬 maflcko commented on issue "build: `CPPFLAGS` usage in OSS-Fuzz":
(https://github.com/bitcoin/bitcoin/issues/29385#issuecomment-1926627045)
Same in `ci/test/00_setup_env_native_fuzz_with_msan.sh`?

💬 Sjors commented on pull request "Stratum v2 Template Provider (take 2)":
(https://github.com/bitcoin/bitcoin/pull/28983#issuecomment-1926654400)
I rebased on top of #29346 and pushed the result to: https://github.com/Sjors/bitcoin/tree/2024/02/sv2-poll-ellswift

Once EllSwift lands on the SRI side (or if I make a revert commit for it) I'll update this PR.

👋 maflcko's pull request is ready for review: "refactor: Allow CScript construction from any std::input_iterator"
(https://github.com/bitcoin/bitcoin/pull/29369)

💬 maflcko commented on pull request "refactor: Allow CScript construction from any std::input_iterator":
(https://github.com/bitcoin/bitcoin/pull/29369#issuecomment-1926712573)
Removed unused `value_type`, which was wrong anyway, since it was cv qualified when it shouldn't.

👍 maflcko approved a pull request: "assumeutxo: Get rid of faked nTx and nChainTx values"
(https://github.com/bitcoin/bitcoin/pull/29370#pullrequestreview-1862394105)
lgtm