💬 Brotcrunsher commented on pull request "init: return error when block index is non-contiguous, fix feature_init.py file perturbation":
(https://github.com/bitcoin/bitcoin/pull/27823#discussion_r1217034392)
Wouldn't it be better to check for `!=` instead for `>`?

💬 mzumsande commented on pull request "init: return error when block index is non-contiguous, fix feature_init.py file perturbation":
(https://github.com/bitcoin/bitcoin/pull/27823#discussion_r1217039090)
I think that would be incorrect, because there will be multiple indexes for a given height in case of stale blocks / forks.

💬 Brotcrunsher commented on pull request "init: return error when block index is non-contiguous, fix feature_init.py file perturbation":
(https://github.com/bitcoin/bitcoin/pull/27823#discussion_r1217039358)
Actually it can't - it's sorted. But still the indices coudl be the same.

💬 Brotcrunsher commented on pull request "init: return error when block index is non-contiguous, fix feature_init.py file perturbation":
(https://github.com/bitcoin/bitcoin/pull/27823#issuecomment-1575685598)
Little disclaimer: It's my first Review for Bitcoin Core. So treat my input with care, I might have no clue what I am talking about.

What I don't like about this change is that previously the user at least had a chance of finding out what's wrong, without debugging the code. Now he won't have any info of what went wrong other than "Error loading block database", which can have multiple other reasons. Is there a way for us to communicate this better? Maybe a log? Or can we throw here? The sad
...

👍 theStack approved a pull request: "wallet: Add tracing for sqlite statements"
(https://github.com/bitcoin/bitcoin/pull/27801#pullrequestreview-1461441581)
ACK ff9d961bf38b24f8f931dcf66799cbc468e473df

💬 ariard commented on pull request "Remove -mempoolfullrbf option":
(https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1575919359)
> To be clear, 0conf users have to "upgrade" every single time mempool policies/conditions change for any non-trivial amount of hashing power. Pretty much any mempool policy change can be exploited to double-spend unconfirmed transactions. That's why the only entities with any hope of relying on them are large, centralized, transaction processors with significant engineering resources. The nVersion=3 proposal is not special in this regard.

Not all the mempool policies/condition changes are eq
...

💬 MikeBH9944 commented on pull request "Multiprocess bitcoin":
(https://github.com/bitcoin/bitcoin/pull/10102#issuecomment-1575959653)
jmy blocks

💬 MikeBH9944 commented on pull request "Multiprocess bitcoin":
(https://github.com/bitcoin/bitcoin/pull/10102#issuecomment-1575959693)
m

💬 vasild commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1576033040)
`92fb45b5ef...c9acf32606`: make the python linter happy and avoid a race in the test - `wait_for_connect()` could time out as if a connection never arrived even if it did. This happens if the peer is connects and disconnects before `wait_for_connect()` is called.

👍 TheCharlatan approved a pull request: "Add public Boost headers explicitly"
(https://github.com/bitcoin/bitcoin/pull/27783#pullrequestreview-1461879008)
ACK 2484cacb7a6367b24e924dba0825c843b1dfc1c3

💬 MarcoFalke commented on pull request "Renamed UniValue::__pushKV to UniValue::pushKVEnd.":
(https://github.com/bitcoin/bitcoin/pull/27822#issuecomment-1576362686)
lgtm ACK acad989e67a57709dbb882c97852c2067f9dc65e

💬 fanquake commented on pull request "Provide `-fcf-protection=none` in `test-security-check.py` explicitly":
(https://github.com/bitcoin/bitcoin/pull/27819#issuecomment-1576398291)
> But I don't see the point of the same restrictions for test-security-check.py.

If the only reason `test-security-check.py` exists is to sanity-check a script that only runs in Guix, why would it need to work in any other environment.

💬 pablomartin4btc commented on pull request "httpserver, rest: improving URI validation":
(https://github.com/bitcoin/bitcoin/pull/27253#issuecomment-1576401038)
Updates:
- I've found the issue with the`fuzz`test I'll push a fix with the commits in reverse order.

💬 hebasto commented on pull request "Renamed UniValue::__pushKV to UniValue::pushKVEnd.":
(https://github.com/bitcoin/bitcoin/pull/27822#issuecomment-1576402224)
Does it make sense to force such changes with the Clang's [`-Wreserved-identifier`](https://clang.llvm.org/docs/DiagnosticsReference.html#wreserved-identifier) diagnostic flag?

💬 pablomartin4btc commented on pull request "httpserver, rest: improving URI validation":
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1217755620)
Those are needed, I've checked the test code line by line. I'll do another check while I fix the current issue/ failure. Thanks!

💬 willcl-ark commented on pull request "contrib: verify torrents with verify-binary.py":
(https://github.com/bitcoin/bitcoin/pull/27762#discussion_r1217758935)
Thanks fixed in next push

💬 willcl-ark commented on pull request "contrib: verify torrents with verify-binary.py":
(https://github.com/bitcoin/bitcoin/pull/27762#discussion_r1217759061)
Thanks fixed in next push

💬 MarcoFalke commented on issue "Build fails on Fedora 36 - configure failed for src/secp256k1":
(https://github.com/bitcoin/bitcoin/issues/27808#issuecomment-1576412348)
Does it happen after a `make clean && make distclean` ?

💬 willcl-ark commented on pull request "contrib: verify torrents with verify-binary.py":
(https://github.com/bitcoin/bitcoin/pull/27762#issuecomment-1576414179)
> Do we want to use the .asc file from the torrent, or should we just get it from the Guix signature repo? The latter may have more signatures, as they keep coming in after release.

I agree that the guix sig repo will likely have more signatures, I only worry that for privacy-concious folks, for whom either bitcoincore.org is blocked or they wish to remain hidden, automatically pinging a (different) specific website might not be ideal behaviour... What do you think?

💬 fanquake commented on pull request "guix: Update `python-lief` package to 0.13.1":
(https://github.com/bitcoin/bitcoin/pull/27813#issuecomment-1576423104)
> The usage of LIEF 0.13.1 in the developer environment has been assumed since https://github.com/bitcoin/bitcoin/pull/27507.

The only requirement to have LIEF 0.13.1 installed, is if you want to run the Python linter, which is not a reason to bump pacakges in our release environment. Outside of that, I don't think LIEF is used for anything in developer environments.