💬 laanwj commented on pull request "Add support for RNDR/RNDRRS for AArch64 on Linux":
(https://github.com/bitcoin/bitcoin/pull/26839#discussion_r1240597346)
That means the chip, or at least this feature, is broken, and should be disabled at the kernel errata level. No need for us to handle that in user space.

🤔 pablomartin4btc reviewed a pull request: "http: update libevent workaround to correct version"
(https://github.com/bitcoin/bitcoin/pull/27949#pullrequestreview-1496428056)
Concept ACK.

I've checked the 2 fixes, checked the [release-2.1.9-beta's changelog](https://raw.githubusercontent.com/libevent/libevent/release-2.1.9-beta/ChangeLog), and after downloading the [release-2.1.9-beta](https://github.com/libevent/libevent/releases/tag/release-2.1.9-beta), checked that the changes are in there too.

💬 tansanDOTeth commented on issue "Stuck in Endless Pre-Syncing Headers Loop":
(https://github.com/bitcoin/bitcoin/issues/26391#issuecomment-1605385608)
Is this normal? I'm looking at the logs and it looks like it happens quite often.

```
023-06-24T10:32:33Z Pre-synchronizing blockheaders, height: 775060 (~97.47%)
2023-06-24T10:32:33Z Pre-synchronizing blockheaders, height: 777060 (~97.71%)
2023-06-24T10:32:33Z Pre-synchronizing blockheaders, height: 779060 (~97.95%)
2023-06-24T10:32:33Z Pre-synchronizing blockheaders, height: 781060 (~98.19%)
2023-06-24T10:32:34Z Pre-synchronizing blockheaders, height: 783060 (~98.43%)
2023-06-24T10:32
...

💬 aleks-mariusz commented on issue "Stuck in Endless Pre-Syncing Headers Loop":
(https://github.com/bitcoin/bitcoin/issues/26391#issuecomment-1605387912)
> > What are the recommendations on fixing this?
>
> If your hardware doesn't have any faults, you can do a `-reindex` to wipe the corrupt block file from the storage.

This helped, re-indexing, but this throws away the entire downloaded and starts over at 0% :-/ it took 3+ days to get back to current state sadly w/ my hardware/network connection

💬 tansanDOTeth commented on issue "Stuck in Endless Pre-Syncing Headers Loop":
(https://github.com/bitcoin/bitcoin/issues/26391#issuecomment-1605388228)
> > > What are the recommendations on fixing this?
> >
> >
> > If your hardware doesn't have any faults, you can do a `-reindex` to wipe the corrupt block file from the storage.
>
> This helped, re-indexing, but this throws away the entire progress haivng been made, and starts over at 0% :-/ it took 3+ days to get back to current state sadly w/ my hardware/network connection

Is there a way to do this from the GUI?

💬 hebasto commented on pull request "Remove the syscall sandbox":
(https://github.com/bitcoin/bitcoin/pull/27896#issuecomment-1605396572)
Concept ACK.

👍 theStack approved a pull request: "net: remove unused `CConnmanTest`"
(https://github.com/bitcoin/bitcoin/pull/27957#pullrequestreview-1496586609)
ACK 9f0d129565f1f752e771670f2df93e94f6c4d880

I was very surprised that it's even possible to specify a non-existing struct as a `friend`. Some background on this topic: https://stackoverflow.com/questions/42008500/why-is-a-friend-class-not-verified-for-existence

💬 ismaelsadeeq commented on pull request "bumpfee: Allow the user to choose which output is change":
(https://github.com/bitcoin/bitcoin/pull/26467#discussion_r1240757480)
Is this not redundant since already checked in spend.cpp? before calling `CreateRateBumpTransaction`?

💬 ismaelsadeeq commented on pull request "bumpfee: Allow the user to choose which output is change":
(https://github.com/bitcoin/bitcoin/pull/26467#issuecomment-1605463285)
tACK dff7235f9a6
Tested the `reduce_output` option on `regtest` with `bumpfee` RPC, the value of the output in the `reduced_output` was decreased to fee bump the transaction instead of adding another input.
tests fail on master and pass on dff7235f9a6.
Code looks good to me

💬 ismaelsadeeq commented on pull request "bumpfee: Allow the user to choose which output is change":
(https://github.com/bitcoin/bitcoin/pull/26467#discussion_r1240763267)
nit
```suggestion
* @param[in] outputs Vector of new outputs to replace the bumped transaction's outputs
```

💬 furszy commented on pull request "index: improve initialization and pruning violation check":
(https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1240773534)
Hmm ok, this should have been part of the commits ordering changes.

The change is not safe in 480f5aad, it becomes safe at the last commit (in b9fe9ab).

Basically, this last commit moves the pruning violation check from `Init()` to the end
of the 'loadblk' thread, which is where the reindex, block loading and chain activation
processes happen.

So we can run this verification step even when the reindex or reindex-chainstate flags
are enabled (which has being skipped so far).

Will
...

💬 furszy commented on pull request "index: improve initialization and pruning violation check":
(https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1240787722)
Done.
Reordered code so the test coverage for the bug fix is introduced with the bug fix.

💬 furszy commented on pull request "index: improve initialization and pruning violation check":
(https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1240787754)
Sure, done.

💬 furszy commented on pull request "index: improve initialization and pruning violation check":
(https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1240788990)
Ok done, renamed the thread to `initload`.

🤔 furszy reviewed a pull request: "index: improve initialization and pruning violation check"
(https://github.com/bitcoin/bitcoin/pull/27607#pullrequestreview-1496630212)
Updated per feedback, thanks ryanofsky.

Changes:

* Renamed `post_load_init` thread to `initload`.
* Changed `BaseIndex::Start()` to throw `std::logic_error` if the index is not initialized.
* Added coverage for the bugfix commit within the bugfix commit and not later (2e1bb3b).
* Expanded the last commit description explaining the pruning violation check movement from the main init thread to the 'loadinit' thread (per [comment](https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1
...

💬 luke-jr commented on pull request "build: make sure we can overwrite config.{guess,sub} before doing so":
(https://github.com/bitcoin/bitcoin/pull/27875#issuecomment-1605521570)
late nits:
*it may be a security issue to grant access to the group
*if autoreconf uses symlinks, chmod will fail too

Better would be to just delete the current files first.

💬 luke-jr commented on pull request "A more efficient descriptor parsing target":
(https://github.com/bitcoin/bitcoin/pull/27888#issuecomment-1605526732)
Suggest putting "Fuzz" in title, and labelling.

👍 luke-jr approved a pull request: "feerate: For GetFeePerK() return nSatoshisPerK instead of round trip through GetFee"
(https://github.com/bitcoin/bitcoin/pull/27914#pullrequestreview-1496658921)
utACK

💬 luke-jr commented on issue "wallets created on master get corrupted when processed with v25":
(https://github.com/bitcoin/bitcoin/issues/27915#issuecomment-1605556090)
Maybe we should consider it an error to load a wallet if the descriptors can't all be round-tripped? (and consider it a bugfix for 25.x, while also trying to avoid triggering it for a while)

💬 luke-jr commented on pull request "policy: make unstructured annex standard":
(https://github.com/bitcoin/bitcoin/pull/27926#issuecomment-1605556983)
Use case?