💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1477697683)
I have added a comment indicating this.

💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1477699351)
Good point, this comment is from a previous version of the PR. I have fixed it.

💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1477700028)
Should be fixed now.

⚠️ Rodert opened an 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)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked


### Expected behaviour

ok

### Steps to reproduce

When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked


### Relevant log output

_No response_

### How did you obtain Bitcoin Core

Package manager

### What version of Bi
...

🤔 stratospher reviewed a pull request: "test: fix intermittent failure in `rpc_setban.py --v2transport`, run it in CI"
(https://github.com/bitcoin/bitcoin/pull/29372#pullrequestreview-1861953032)
tested ACK cc87ee4. nice find!

💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#issuecomment-1926350798)
> Is it still possible to abandon a transaction with conflicts with the mempool?

Yes, because of [this](https://github.com/bitcoin/bitcoin/pull/27307/commits/3de89342dcd44bdde4027a91cb27793dc0231847#diff-1f2db0e4d5c12d109c7f0962333c245b49b696cb39ff432da048e9d6c08944d8L1313-R1313) change.

> If a transaction is already abandoned and we know it conflicts with the mempool does isMempoolConflicted still return false?

Yes

> Sure, but then I'm pretty sure we need to add a bool abandoned;
...

💬 ismaelsadeeq commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1477791006)
>I'm fairly certain we don't check relayMinFee when creating a transaction, but it would be good to confirm this (even better, to have a functional test!)

I've tested this, and it turns out that the wallet indeed prevents creating transactions below the `minrelaytxfee`
https://github.com/bitcoin/bitcoin/blob/a11585692e72cac468fb1496ea2c30e4c07f73e5/src/wallet/spend.cpp#L1055

Here is a test that confirms we can't create transactions with a fee rate below the minimum relay fee, and also t
...

💬 ismaelsadeeq commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1477793113)
Thanks @murchandamus, I agree with your suggestion and reorder the commits.

💬 ismaelsadeeq commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1477810958)
The reason is that the maximum fee rate check for [`sendrawtransaction`](https://github.com/bitcoin/bitcoin/blob/a11585692e72cac468fb1496ea2c30e4c07f73e5/src/rpc/mempool.cpp#L84-L94) is performed in `BroadcastTransaction` which returned [`MAX_FEE_EXCEEDED`](https://github.com/bitcoin/bitcoin/blob/a11585692e72cac468fb1496ea2c30e4c07f73e5/src/node/transaction.cpp#L71-L79) error type to `sendrawtransaction`.
If I change the `MAX_FEE_EXCEEDED` error message to "Fee exceeds maximum configured by use
...

💬 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?