💬 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;
...
(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
...
(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.
(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
...
(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
(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
(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 👍🏾
(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
(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
(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.
(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?
(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)
(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.
(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
...
(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?
(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
...
(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.
(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"
...
(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
(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`?
(https://github.com/bitcoin/bitcoin/issues/29385#issuecomment-1926627045)
Same in `ci/test/00_setup_env_native_fuzz_with_msan.sh`?