💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1444359794)
taken
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1444359794)
taken
💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1444359931)
taken
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1444359931)
taken
💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1444360019)
fixed
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1444360019)
fixed
💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1444360107)
taken, thanks
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1444360107)
taken, thanks
💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1444360587)
because otherwise it is always 0
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1444360587)
because otherwise it is always 0
💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1444360834)
taken
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1444360834)
taken
✅ glozow closed an issue: "."
(https://github.com/bitcoin/bitcoin/issues/29201)
(https://github.com/bitcoin/bitcoin/issues/29201)
:lock: fanquake locked an issue: "."
(https://github.com/bitcoin/bitcoin/issues/29201)
(https://github.com/bitcoin/bitcoin/issues/29201)
💬 maflcko commented on pull request "test: Treat msg_version.relay as unsigned, Remove `struct` packing in messages.py":
(https://github.com/bitcoin/bitcoin/pull/29067#issuecomment-1880721233)
> over int.from_bytes(bs, "little")
In python3.11, one could also write `int.from_bytes(bs)` for single-byte conversions.
(https://github.com/bitcoin/bitcoin/pull/29067#issuecomment-1880721233)
> over int.from_bytes(bs, "little")
In python3.11, one could also write `int.from_bytes(bs)` for single-byte conversions.
💬 glozow commented on pull request "mempool / rpc: followup to getprioritisedtransactions and delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/28885#issuecomment-1880722797)
Still working on this? I'll be available to re-review quickly after comments are addressed.
(https://github.com/bitcoin/bitcoin/pull/28885#issuecomment-1880722797)
Still working on this? I'll be available to re-review quickly after comments are addressed.
💬 maflcko commented on pull request "ci: Switch native macOS CI job to Xcode 15.0":
(https://github.com/bitcoin/bitcoin/pull/29195#issuecomment-1880726651)
pull title should be "build: Fix -Xclang -internal-isystem option"? Otherwise lgtm
(https://github.com/bitcoin/bitcoin/pull/29195#issuecomment-1880726651)
pull title should be "build: Fix -Xclang -internal-isystem option"? Otherwise lgtm
💬 hebasto commented on pull request "build: Fix `-Xclang -internal-isystem` option":
(https://github.com/bitcoin/bitcoin/pull/29195#issuecomment-1880728913)
> pull title should be "build: Fix -Xclang -internal-isystem option"? Otherwise lgtm
Done.
(https://github.com/bitcoin/bitcoin/pull/29195#issuecomment-1880728913)
> pull title should be "build: Fix -Xclang -internal-isystem option"? Otherwise lgtm
Done.
💬 fanquake commented on pull request "build: Fix `-Xclang -internal-isystem` option":
(https://github.com/bitcoin/bitcoin/pull/29195#issuecomment-1880736065)
> The same Xcode version is used for the release binaries.
Can probably drop this, or be more specific, because we don't use Xcode to build release binaries (only the SDK, which is versioned differently).
(https://github.com/bitcoin/bitcoin/pull/29195#issuecomment-1880736065)
> The same Xcode version is used for the release binaries.
Can probably drop this, or be more specific, because we don't use Xcode to build release binaries (only the SDK, which is versioned differently).
💬 fanquake commented on pull request "ci: Do not set inane value for `LD_LIBRARY_PATH`":
(https://github.com/bitcoin/bitcoin/pull/29196#issuecomment-1880740854)
> For example, in the native macOS CI job,
Unless there's a downside to having this set, I don't think it's worth the extra code / shellcheck exceptions. i.e in this example, ld64 will never read this ENV var?
(https://github.com/bitcoin/bitcoin/pull/29196#issuecomment-1880740854)
> For example, in the native macOS CI job,
Unless there's a downside to having this set, I don't think it's worth the extra code / shellcheck exceptions. i.e in this example, ld64 will never read this ENV var?
💬 hebasto commented on pull request "build: Fix `-Xclang -internal-isystem` option":
(https://github.com/bitcoin/bitcoin/pull/29195#issuecomment-1880740932)
> > The same Xcode version is used for the release binaries.
>
> Can probably drop this, or be more specific, because we don't use Xcode to build release binaries (only the SDK, which is versioned differently).
Dropped.
(https://github.com/bitcoin/bitcoin/pull/29195#issuecomment-1880740932)
> > The same Xcode version is used for the release binaries.
>
> Can probably drop this, or be more specific, because we don't use Xcode to build release binaries (only the SDK, which is versioned differently).
Dropped.
🚀 glozow merged a pull request: "RPC/Blockchain: scanblocks: Accept named param for filter_false_positives"
(https://github.com/bitcoin/bitcoin/pull/29184)
(https://github.com/bitcoin/bitcoin/pull/29184)
💬 ismaelsadeeq commented on pull request "RPC: Add maxfeerate and maxburnamount args to submitpackage":
(https://github.com/bitcoin/bitcoin/pull/28950#discussion_r1444456650)
Should enable passing `maxfeerate` and `maxburnamount` as a config variables since it is used by various RPC, downstream might prefer this?
(https://github.com/bitcoin/bitcoin/pull/28950#discussion_r1444456650)
Should enable passing `maxfeerate` and `maxburnamount` as a config variables since it is used by various RPC, downstream might prefer this?
💬 ismaelsadeeq commented on pull request "RPC: Add maxfeerate and maxburnamount args to submitpackage":
(https://github.com/bitcoin/bitcoin/pull/28950#discussion_r1444397171)
Shoulbe we testi `maxfeerate` and `maxburnamount` for `testmempoolaccept` with a package also?
(https://github.com/bitcoin/bitcoin/pull/28950#discussion_r1444397171)
Shoulbe we testi `maxfeerate` and `maxburnamount` for `testmempoolaccept` with a package also?
💬 ismaelsadeeq commented on pull request "RPC: Add maxfeerate and maxburnamount args to submitpackage":
(https://github.com/bitcoin/bitcoin/pull/28950#discussion_r1444464488)
To turn off for maxfeerate you should pass 0 fee rate, you cant turn off the restriction of `maxburnamount`
nit: maybe reword to relax?
```suggestion
# Relax the restrictions and send it; parent gets through as own subpackage
```
(https://github.com/bitcoin/bitcoin/pull/28950#discussion_r1444464488)
To turn off for maxfeerate you should pass 0 fee rate, you cant turn off the restriction of `maxburnamount`
nit: maybe reword to relax?
```suggestion
# Relax the restrictions and send it; parent gets through as own subpackage
```
💬 ismaelsadeeq commented on pull request "RPC: Add maxfeerate and maxburnamount args to submitpackage":
(https://github.com/bitcoin/bitcoin/pull/28950#discussion_r1444454903)
My understanding of package submission is that a child with unconfirmed parents is bundled together as a package for incentive compatibility. Should this instead check the package fee rate against `maxfeerate`?
If I understand correctly, currently, we are checking the package transaction fee rate individually against `maxfeerate`. The child transactions might be greater than the `maxfeerate`, but as a package might not be. In this case, we might reject the child transactions and accept the su
...
(https://github.com/bitcoin/bitcoin/pull/28950#discussion_r1444454903)
My understanding of package submission is that a child with unconfirmed parents is bundled together as a package for incentive compatibility. Should this instead check the package fee rate against `maxfeerate`?
If I understand correctly, currently, we are checking the package transaction fee rate individually against `maxfeerate`. The child transactions might be greater than the `maxfeerate`, but as a package might not be. In this case, we might reject the child transactions and accept the su
...