💬 vasild commented on pull request "Split CConnman":
(https://github.com/bitcoin/bitcoin/pull/30988#discussion_r1944904841)
Done.
(https://github.com/bitcoin/bitcoin/pull/30988#discussion_r1944904841)
Done.
👍 laanwj approved a pull request: "feefrac: add support for evaluating at given size"
(https://github.com/bitcoin/bitcoin/pull/30535#pullrequestreview-2598982998)
Code review ACK f6aa28cf8fad6a3240498b500524bb380855b18e, mul/division code looks correct, testing and fuzzing coverage seems very good
(https://github.com/bitcoin/bitcoin/pull/30535#pullrequestreview-2598982998)
Code review ACK f6aa28cf8fad6a3240498b500524bb380855b18e, mul/division code looks correct, testing and fuzzing coverage seems very good
💬 jonatack commented on pull request "doc: improve NODE_NETWORK_LIMITED documentation per BIP159":
(https://github.com/bitcoin/bitcoin/pull/31805#discussion_r1944917982)
Thanks, updated.
(https://github.com/bitcoin/bitcoin/pull/31805#discussion_r1944917982)
Thanks, updated.
💬 jonatack commented on pull request "doc: improve NODE_NETWORK_LIMITED documentation per BIP159":
(https://github.com/bitcoin/bitcoin/pull/31805#issuecomment-2640132380)
Updated per review feedback (thanks!)
> It's good to clarify the description, because the term `NODE_NETWORK_LIMITED` has confused me before into assuming that a node that isn't limited doesn't use the flag. But instead it signals the minimum capability, and `NODE_NETWORK` is added when ready to signal full capability. Too late to rename them.
Well said -- same for me.
(https://github.com/bitcoin/bitcoin/pull/31805#issuecomment-2640132380)
Updated per review feedback (thanks!)
> It's good to clarify the description, because the term `NODE_NETWORK_LIMITED` has confused me before into assuming that a node that isn't limited doesn't use the flag. But instead it signals the minimum capability, and `NODE_NETWORK` is added when ready to signal full capability. Too late to rename them.
Well said -- same for me.
👍 instagibbs approved a pull request: "TxOrphanage: account for size of orphans and count announcements"
(https://github.com/bitcoin/bitcoin/pull/31810#pullrequestreview-2598861794)
ACK 76af0b4d993c3a5a4a9c37f40d85b9996b38e7a0
Agree with https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1944888846
and up for litigating the naming of size vs weight.
(https://github.com/bitcoin/bitcoin/pull/31810#pullrequestreview-2598861794)
ACK 76af0b4d993c3a5a4a9c37f40d85b9996b38e7a0
Agree with https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1944888846
and up for litigating the naming of size vs weight.
💬 instagibbs commented on pull request "TxOrphanage: account for size of orphans and count announcements":
(https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1944832866)
can we at least internally call it weight, even if externally we don't?
(https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1944832866)
can we at least internally call it weight, even if externally we don't?
💬 instagibbs commented on pull request "TxOrphanage: account for size of orphans and count announcements":
(https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1944908395)
extra period?
(https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1944908395)
extra period?
💬 instagibbs commented on pull request "TxOrphanage: account for size of orphans and count announcements":
(https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1944903683)
nit: can assert number of announcers must be non-0 while we're here.
(https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1944903683)
nit: can assert number of announcers must be non-0 while we're here.
💬 instagibbs commented on pull request "TxOrphanage: account for size of orphans and count announcements":
(https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1944911351)
can use wtxid here
(https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1944911351)
can use wtxid here
💬 instagibbs commented on pull request "TxOrphanage: account for size of orphans and count announcements":
(https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1944911842)
can use `wtxid` here
(https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1944911842)
can use `wtxid` here
💬 instagibbs commented on pull request "TxOrphanage: account for size of orphans and count announcements":
(https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1944927518)
while we're here could also assert `m_total_announcements >= m_total_orphan_size`
(https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1944927518)
while we're here could also assert `m_total_announcements >= m_total_orphan_size`
💬 Sjors commented on pull request "doc: improve NODE_NETWORK_LIMITED documentation per BIP159":
(https://github.com/bitcoin/bitcoin/pull/31805#discussion_r1944933102)
We should probably try to keep the output lines of `bitcoin-cli -netinfo help` below 80 characters. It doesn't wrap in a nice way.
(https://github.com/bitcoin/bitcoin/pull/31805#discussion_r1944933102)
We should probably try to keep the output lines of `bitcoin-cli -netinfo help` below 80 characters. It doesn't wrap in a nice way.
💬 jonatack commented on pull request "doc: improve NODE_NETWORK_LIMITED documentation per BIP159":
(https://github.com/bitcoin/bitcoin/pull/31805#discussion_r1944940106)
Don't disagree but that would require reformatting most of the help.
(https://github.com/bitcoin/bitcoin/pull/31805#discussion_r1944940106)
Don't disagree but that would require reformatting most of the help.
💬 jonatack commented on pull request "doc: improve NODE_NETWORK_LIMITED documentation per BIP159":
(https://github.com/bitcoin/bitcoin/pull/31805#discussion_r1944942184)
For here kept it shorter than the longest line ("If that argument is passed...")
(https://github.com/bitcoin/bitcoin/pull/31805#discussion_r1944942184)
For here kept it shorter than the longest line ("If that argument is passed...")
👍 stickies-v approved a pull request: "Prepare "Open Transifex translations for v29.0" release step"
(https://github.com/bitcoin/bitcoin/pull/31809#pullrequestreview-2599059064)
ACK 2f27c910869e301b7e7669e81a0878da64e49957
I'm not sure how necessary 864386a7444fb5cf16613956ce8bf335f51b67d5 is (has this lead to an issue before?), but the rationale makes sense, and it seems harmless and a minimal change.
I reviewed 2f27c910869e301b7e7669e81a0878da64e49957 without `depends` and with `-DWITH_MULTIPROCESS=OFF` because the sources lists of `bitcoin-qt` and `bitcoin-gui` are currently identical. Diff is the same.
(https://github.com/bitcoin/bitcoin/pull/31809#pullrequestreview-2599059064)
ACK 2f27c910869e301b7e7669e81a0878da64e49957
I'm not sure how necessary 864386a7444fb5cf16613956ce8bf335f51b67d5 is (has this lead to an issue before?), but the rationale makes sense, and it seems harmless and a minimal change.
I reviewed 2f27c910869e301b7e7669e81a0878da64e49957 without `depends` and with `-DWITH_MULTIPROCESS=OFF` because the sources lists of `bitcoin-qt` and `bitcoin-gui` are currently identical. Diff is the same.
💬 theuni commented on pull request "build: set build type and per-build-type flags as early as possible":
(https://github.com/bitcoin/bitcoin/pull/31711#discussion_r1944952072)
Not critically, no. I just figured it should for consistency. Is there a downside to this?
(https://github.com/bitcoin/bitcoin/pull/31711#discussion_r1944952072)
Not critically, no. I just figured it should for consistency. Is there a downside to this?
💬 theuni commented on pull request "build: set build type and per-build-type flags as early as possible":
(https://github.com/bitcoin/bitcoin/pull/31711#issuecomment-2640196265)
> The `CMAKE_BUILD_TYPE` cache variable lost its help string:
>
Ugh, presumably because it's enabling c++ that sets this?
I guess that's a downside, and there may be other side-affects as well. I suppose it'd be safer to do this after enabling c++, which means letting that check be done with the wrong build type. Which realistically shouldn't ever be a problem. Agreed?
(https://github.com/bitcoin/bitcoin/pull/31711#issuecomment-2640196265)
> The `CMAKE_BUILD_TYPE` cache variable lost its help string:
>
Ugh, presumably because it's enabling c++ that sets this?
I guess that's a downside, and there may be other side-affects as well. I suppose it'd be safer to do this after enabling c++, which means letting that check be done with the wrong build type. Which realistically shouldn't ever be a problem. Agreed?
💬 hebasto commented on pull request "build: set build type and per-build-type flags as early as possible":
(https://github.com/bitcoin/bitcoin/pull/31711#issuecomment-2640206091)
> > The `CMAKE_BUILD_TYPE` cache variable lost its help string:
>
> Ugh, presumably because it's enabling c++ that sets this?
>
> I guess that's a downside, and there may be other side-effects as well. I suppose it'd be safer to do this after enabling c++, which means letting that check be done with the wrong build type. Which realistically shouldn't ever be a problem. Agreed?
Given https://github.com/bitcoin/bitcoin/pull/31711#discussion_r1944952072, yes, I agree.
(https://github.com/bitcoin/bitcoin/pull/31711#issuecomment-2640206091)
> > The `CMAKE_BUILD_TYPE` cache variable lost its help string:
>
> Ugh, presumably because it's enabling c++ that sets this?
>
> I guess that's a downside, and there may be other side-effects as well. I suppose it'd be safer to do this after enabling c++, which means letting that check be done with the wrong build type. Which realistically shouldn't ever be a problem. Agreed?
Given https://github.com/bitcoin/bitcoin/pull/31711#discussion_r1944952072, yes, I agree.
💬 achow101 commented on pull request "wallet: Utilize IsMine() and CanProvide() in migration to cover edge cases":
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1944976427)
Descriptor wallets never show `iswatchonly` for individual addresses. They are only `ismine` or not. That's that whole point. The watchonly distinction lives at the wallet level, not that address level.
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1944976427)
Descriptor wallets never show `iswatchonly` for individual addresses. They are only `ismine` or not. That's that whole point. The watchonly distinction lives at the wallet level, not that address level.
💬 sr-gi commented on pull request "func test: Expand tx download preference tests":
(https://github.com/bitcoin/bitcoin/pull/31437#issuecomment-2640221382)
This seems to have heavily increased the run time of the rest (from ~30s to ~90s on my local setup) :/
(https://github.com/bitcoin/bitcoin/pull/31437#issuecomment-2640221382)
This seems to have heavily increased the run time of the rest (from ~30s to ~90s on my local setup) :/