💬 epiccurious commented on pull request "refactor: Use type-safe time in txorphanage":
(https://github.com/bitcoin/bitcoin/pull/30170#issuecomment-2130040435)
utACK fa6d4891c7815025ab1cd58d0906466af31bb648.
(https://github.com/bitcoin/bitcoin/pull/30170#issuecomment-2130040435)
utACK fa6d4891c7815025ab1cd58d0906466af31bb648.
💬 sipa commented on pull request "util: add VecDeque":
(https://github.com/bitcoin/bitcoin/pull/30161#discussion_r1613810244)
Renamed!
(https://github.com/bitcoin/bitcoin/pull/30161#discussion_r1613810244)
Renamed!
💬 BenWestgate commented on pull request "doc: Change GiB to GB in release-process.md":
(https://github.com/bitcoin/bitcoin/pull/30171#issuecomment-2130058903)
> Concept ACK [c04edce](https://github.com/bitcoin/bitcoin/commit/c04edce83db41cfce7a0a2f3418cf830c2e8afb5).
>
> This assumes the value should be displayed in GB. Is there a benefit to doing the calculation and displaying in GiB instead?
Software usually displays large sizes in GB because that's what the operating system and storage manufacturers use.
(https://github.com/bitcoin/bitcoin/pull/30171#issuecomment-2130058903)
> Concept ACK [c04edce](https://github.com/bitcoin/bitcoin/commit/c04edce83db41cfce7a0a2f3418cf830c2e8afb5).
>
> This assumes the value should be displayed in GB. Is there a benefit to doing the calculation and displaying in GiB instead?
Software usually displays large sizes in GB because that's what the operating system and storage manufacturers use.
💬 sdaftuar commented on pull request "Cluster size 2 package rbf":
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613803860)
My comment is just about the commit message for this commit, not this line of code (sorry):
> Relax assumptions aabout in-mempool children of in-mempool
"aabout" --> "about"
> TxA (in mempool) <- TxB' (in package, conflicts with TxB) <-
> TxD (in package)
s/TxD/TxC/ ?
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613803860)
My comment is just about the commit message for this commit, not this line of code (sorry):
> Relax assumptions aabout in-mempool children of in-mempool
"aabout" --> "about"
> TxA (in mempool) <- TxB' (in package, conflicts with TxB) <-
> TxD (in package)
s/TxD/TxC/ ?
💬 sdaftuar commented on pull request "Cluster size 2 package rbf":
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613810585)
Seems weird to loop through all the workspaces, when `GetEntriesForConflicts` is doing all the work that needs to be done on the first invocation? Maybe just invoke once with the child's txid, as is done further down?
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613810585)
Seems weird to loop through all the workspaces, when `GetEntriesForConflicts` is doing all the work that needs to be done on the first invocation? Maybe just invoke once with the child's txid, as is done further down?
💬 sdaftuar commented on pull request "Cluster size 2 package rbf":
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613820116)
s/V3 transactions/TRUC transactions/, perhaps?
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613820116)
s/V3 transactions/TRUC transactions/, perhaps?
💬 sdaftuar commented on pull request "Cluster size 2 package rbf":
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613817141)
Can you just add a comment here that references the comment on line 1520, as a reminder that we can't relax this without revisiting how we track available inputs when processing a package?
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613817141)
Can you just add a comment here that references the comment on line 1520, as a reminder that we can't relax this without revisiting how we track available inputs when processing a package?
💬 hebasto commented on pull request "[PoC] ci: Add FreeBSD GitHub Actions job":
(https://github.com/bitcoin/bitcoin/pull/30164#issuecomment-2130100585)
> @Sjors According to https://github.com/vmactions/freebsd-vm?tab=readme-ov-file#under-the-hood you can use `with: release:` to pick one.
By default, the latest release is used, which is 14.0. See https://github.com/hebasto/bitcoin/actions/runs/9215593397/job/25354268473#step:3:7032:
```
Config file: freebsd-14.0.conf
```
On my FreeBSD 14.0 machine, the default compiler is
```
$ c++ --version
FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cb
...
(https://github.com/bitcoin/bitcoin/pull/30164#issuecomment-2130100585)
> @Sjors According to https://github.com/vmactions/freebsd-vm?tab=readme-ov-file#under-the-hood you can use `with: release:` to pick one.
By default, the latest release is used, which is 14.0. See https://github.com/hebasto/bitcoin/actions/runs/9215593397/job/25354268473#step:3:7032:
```
Config file: freebsd-14.0.conf
```
On my FreeBSD 14.0 machine, the default compiler is
```
$ c++ --version
FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cb
...
💬 hebasto commented on pull request "[PoC] ci: Add FreeBSD GitHub Actions job":
(https://github.com/bitcoin/bitcoin/pull/30164#issuecomment-2130109577)
> > IMPORTANT. The `vmactions/*` needs to be added to the "Actions permissions" section of the repository settings.
>
> Not sure. What was the conclusion when GHA was added to the repo about enabling third party actions? IIRC it was unclear whether malicious or backdoored actions could compromise the repo, so the conclusion was to refrain from enabling them?
I think, this repository granted on Read permissions to the GH Actions workflows as their logs include:
```
GITHUB_TOKEN Permission
...
(https://github.com/bitcoin/bitcoin/pull/30164#issuecomment-2130109577)
> > IMPORTANT. The `vmactions/*` needs to be added to the "Actions permissions" section of the repository settings.
>
> Not sure. What was the conclusion when GHA was added to the repo about enabling third party actions? IIRC it was unclear whether malicious or backdoored actions could compromise the repo, so the conclusion was to refrain from enabling them?
I think, this repository granted on Read permissions to the GH Actions workflows as their logs include:
```
GITHUB_TOKEN Permission
...
💬 sipa commented on pull request "doc: Change GiB to GB in release-process.md":
(https://github.com/bitcoin/bitcoin/pull/30171#issuecomment-2130126582)
> Software usually displays large sizes in GB because that's what the operating system and storage manufacturers use.
I don't think that's universally true. I believe Apple generally uses GB (meaning 10<sup>9</sup>), Windows generally uses GB (meaning 2<sup>30</sup>), and open-source systems use a mix (sometimes using GiB to mean 2<sup>30</sup>).
(https://github.com/bitcoin/bitcoin/pull/30171#issuecomment-2130126582)
> Software usually displays large sizes in GB because that's what the operating system and storage manufacturers use.
I don't think that's universally true. I believe Apple generally uses GB (meaning 10<sup>9</sup>), Windows generally uses GB (meaning 2<sup>30</sup>), and open-source systems use a mix (sometimes using GiB to mean 2<sup>30</sup>).
🤔 showtime73 reviewed a pull request: "doc: Change GiB to GB in release-process.md"
(https://github.com/bitcoin/bitcoin/pull/30171#pullrequestreview-2077589265)
Hello World
(https://github.com/bitcoin/bitcoin/pull/30171#pullrequestreview-2077589265)
Hello World
💬 instagibbs commented on pull request "Low-level cluster linearization code":
(https://github.com/bitcoin/bitcoin/pull/30126#issuecomment-2130129883)
> Ancestor-set based presplitting inside the search is replaced with using the best ancestor set as one of the LIMO set choices.
Can this be elaborated a bit? I've taken a few minutes looking at the commits and it wasn't immediately clear how this all maps to existing public discussions and the comments:
```
// This is an implementation of the (single) LIMO algorithm:
// https://delvingbitcoin.org/t/limo-combining-the-best-parts-of-linearization-search-and-merging/825
...
(https://github.com/bitcoin/bitcoin/pull/30126#issuecomment-2130129883)
> Ancestor-set based presplitting inside the search is replaced with using the best ancestor set as one of the LIMO set choices.
Can this be elaborated a bit? I've taken a few minutes looking at the commits and it wasn't immediately clear how this all maps to existing public discussions and the comments:
```
// This is an implementation of the (single) LIMO algorithm:
// https://delvingbitcoin.org/t/limo-combining-the-best-parts-of-linearization-search-and-merging/825
...
💬 LarryRuane commented on pull request "improve MallocUsage() accuracy":
(https://github.com/bitcoin/bitcoin/pull/28531#issuecomment-2130140023)
CI passed, thanks @theStack. I just force-pushed swapping of the two commits, the test commit has to be first for each commit to pass CI.
(https://github.com/bitcoin/bitcoin/pull/28531#issuecomment-2130140023)
CI passed, thanks @theStack. I just force-pushed swapping of the two commits, the test commit has to be first for each commit to pass CI.
💬 instagibbs commented on pull request "Cluster size 2 package rbf":
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613878905)
removed references to v3, and added a note that non-standard relay args should be removed once they're made standard
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613878905)
removed references to v3, and added a note that non-standard relay args should be removed once they're made standard
💬 instagibbs commented on pull request "Cluster size 2 package rbf":
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613878961)
made an attempt at a grepp-able cautionary note
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613878961)
made an attempt at a grepp-able cautionary note
💬 instagibbs commented on pull request "Cluster size 2 package rbf":
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613879170)
right this is just a logging arg; probably should clean that up to just take `Wtxid` in future work. re-arranged and passed in child workspace now
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613879170)
right this is just a logging arg; probably should clean that up to just take `Wtxid` in future work. re-arranged and passed in child workspace now
💬 instagibbs commented on pull request "Cluster size 2 package rbf":
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613879250)
fixed
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1613879250)
fixed
💬 BenWestgate commented on pull request "doc: Change GiB to GB in release-process.md":
(https://github.com/bitcoin/bitcoin/pull/30171#issuecomment-2130157516)
> I don't think that's universally true. I believe Apple generally uses GB (meaning 109), Microsoft generally uses GB (meaning 230), and open-source systems use a mix (sometimes using GiB to mean 230).
Good to know. Should the value we display depend on platform then? At the very least I think we should be consistent within the repository or within a file. Currently we do math that adds and subtracts GiB from GB in the GUI welcome screen which will cause issues. https://github.com/bitcoin-cor
...
(https://github.com/bitcoin/bitcoin/pull/30171#issuecomment-2130157516)
> I don't think that's universally true. I believe Apple generally uses GB (meaning 109), Microsoft generally uses GB (meaning 230), and open-source systems use a mix (sometimes using GiB to mean 230).
Good to know. Should the value we display depend on platform then? At the very least I think we should be consistent within the repository or within a file. Currently we do math that adds and subtracts GiB from GB in the GUI welcome screen which will cause issues. https://github.com/bitcoin-cor
...
🤔 murchandamus reviewed a pull request: "Fix waste calculation in SelectionResult"
(https://github.com/bitcoin/bitcoin/pull/28366#pullrequestreview-2077274300)
Thanks @achow101, @s3rk, and @ismaelsadeeq, I hope I addressed all of your comments satisfactorily.
(https://github.com/bitcoin/bitcoin/pull/28366#pullrequestreview-2077274300)
Thanks @achow101, @s3rk, and @ismaelsadeeq, I hope I addressed all of your comments satisfactorily.
💬 murchandamus commented on pull request "Fix waste calculation in SelectionResult":
(https://github.com/bitcoin/bitcoin/pull/28366#discussion_r1613854692)
used `exact_target` as proposed
(https://github.com/bitcoin/bitcoin/pull/28366#discussion_r1613854692)
used `exact_target` as proposed