💬 MarcoFalke commented on pull request "verify-commits: Bump trusted git root to after most recent laanwj merge":
(https://github.com/bitcoin/bitcoin/pull/27076#issuecomment-1426768304)
> I think we should only bump

Is there any reason for this? See also https://github.com/bitcoin/bitcoin/pull/27058#discussion_r1099900493
What would the alternative be? Listing hundreds or thousands of "revsig" commits in a file, to ensure it is impossible to review manually, only with special git commands, potentially making it trivial to sneak in malicious commits that are not actually revsig commits?

💬 Sjors commented on pull request "contrib: Improve verify-commits.py to work with maintainers leaving":
(https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1426770715)
I like the CSV approach in c090a7ff86257411761e22d3642d0e8e05859b73 better. See [inline discussion](https://github.com/bitcoin/bitcoin/pull/27058#discussion_r1099900493) and [here](https://github.com/bitcoin/bitcoin/pull/27076#issuecomment-1426761886). I don't like having to update the root trusted commit every time the maintainer list changes.

Imo we should only bump it if a former maintainer revokes their key or it expires, plus maybe every couple of years to preempt such issues. As @MarcoF
...

💬 Sjors commented on pull request "verify-commits: Bump trusted git root to after most recent laanwj merge":
(https://github.com/bitcoin/bitcoin/pull/27076#issuecomment-1426770956)
@MarcoFalke answered in https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1426770715. Depending on what we do there this PR can either be closed or merged.

💬 MarcoFalke commented on pull request "contrib: Improve verify-commits.py to work with maintainers leaving":
(https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1426774872)
> I don't like having to update the root trusted commit every time the maintainer list changes.

You don't have to. It is only a recommended trusted git root. Everyone using this script will have to pick their root themselves in their own copy of this script anyway. They are free to not touch their script after the root is bumped and continue using the previous script+data; they are free to pick the latest data from the `master` branch, once and if they agree with it; they are also free to pi
...

👋 hebasto's pull request is ready for review: "ci: A few fixes of `ccache` issues"
(https://github.com/bitcoin/bitcoin/pull/27084)

💬 hebasto commented on pull request "ci: A few fixes of `ccache` issues":
(https://github.com/bitcoin/bitcoin/pull/27084#issuecomment-1426800453)
The PR description has been updated with some statistics.

💬 darosior commented on pull request "Wallet: estimate the size of signed inputs using descriptors":
(https://github.com/bitcoin/bitcoin/pull/26567#discussion_r1103646477)
Hmm good point. Unfortunately this is a bit clumsy for the `LegacyScriptPubKeyMan`: since it's not a `FlatSigningProvider` it involves copying all its data in order to merge both providers. I've pushed the change in a separate commit to be squashed if it's not too unreasonable. What do you think?

⚠️ Christewart opened an issue: "Failing to fetch `cfheader` corresponding to block header in `headers` message"
(https://github.com/bitcoin/bitcoin/issues/27085)
<!-- Describe the issue -->

Occasionally when I receive a `headers` message on the p2p network, and attempt to fetch the `cfheader` that corresponds to a block header inside of a `headers`, i get this error message inside of my `debug.log`

>2023-02-07T16:47:15Z [net] Failed to find block filter hashes in index: filter_type=basic, start_height=150, stop_hash=3ca9030aeb6c2721cfbab0116b8d96e2d3c7e00738238010e0bc622566dc2aed


**Expected behavior**

I should be able to fetch a `cfheader`
...

💬 achow101 commented on pull request "contrib: Improve verify-commits.py to work with maintainers leaving":
(https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1426816110)
> But doesn't the CSV remove the need for revsig commits?

It could. The CSV could have a field that indicates the key is revoked, so we could then allow revsigs only for that key. Similar with expired keys.

💬 kristapsk commented on pull request "contrib: Improve verify-commits.py to work with maintainers leaving":
(https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1426821483)
Maybe it would make sense to use OpenTimestamps to verify timestamps (dates) of merge commits?

💬 furszy commented on issue "Failing to fetch `cfheader` corresponding to block header in `headers` message":
(https://github.com/bitcoin/bitcoin/issues/27085#issuecomment-1426836560)
Even when the peer sent the `headers` message, the block filter index could still be processing the block signals.
If possible on your tests, call `syncwithvalidationinterfacequeue` to empty the validation interface queue prior to request the `cfheader`s.

💬 Christewart commented on issue "Failing to fetch `cfheader` corresponding to block header in `headers` message":
(https://github.com/bitcoin/bitcoin/issues/27085#issuecomment-1426845565)
Thanks for pointing me in the right direction, this seems to be the equivalent in the bitcoin core python test harness https://github.com/bitcoin/bitcoin/pull/22311

✅ Christewart closed an issue: "Failing to fetch `cfheader` corresponding to block header in `headers` message"
(https://github.com/bitcoin/bitcoin/issues/27085)

📝 davidgumberg opened a pull request: "[WIP] p2p: Add random txn's from mempool to GETBLOCKTXN"
(https://github.com/bitcoin/bitcoin/pull/27086)
As compact block completion works currently, nodes reveal precisely the subset of transactions from published blocks that they already have in their mempool when they make a GETBLOCKTXN request for the transactions that they are missing. The greatest danger here is that nodes will never request their own transactions. Given a "sufficient number" of `GETBLOCKTXN`'s from a single peer, it will become possible to identify their wallet addresses with some degree of confidence.

Assuming that all
...

💬 brunoerg commented on pull request "Modernize rpcauth.py":
(https://github.com/bitcoin/bitcoin/pull/27081#discussion_r1103701701)
nit: `from secrets import token_hex, token_urlsafe`

💬 sipa commented on pull request "[WIP] p2p: Add random txn's from mempool to GETBLOCKTXN":
(https://github.com/bitcoin/bitcoin/pull/27086#issuecomment-1426937832)
It's an interesting observation that our responses to compact block announcements reveal something about our mempool, but I'm not sure it's worth the cost of addressing that:
* Blocks are rare, and very expensive to produce, meaning that per block only a few of our peers even get the chance to query us about it (and it's unaffordable to produce more close-to-tip blocks to trigger that).
* Increasing the size of compact block responses may actually add to propagation latency, especially when it
...

💬 hebasto commented on issue "Check usages of `#if defined(...)`":
(https://github.com/bitcoin/bitcoin/issues/16419#issuecomment-1426991462)
> Is this issue up for grab?

It is. See #16547.

💬 Sjors commented on pull request "contrib: Improve verify-commits.py to work with maintainers leaving":
(https://github.com/bitcoin/bitcoin/pull/27058#issuecomment-1427049883)
@kristapsk maybe not for this PR, however, that might be a good way to make it safe to use a revocation date. The rule would then be that a timestamp must exist with a median time past before that date.

💬 hebasto commented on pull request "refactor: Add util::Result failure values, multiple error and warning messages":
(https://github.com/bitcoin/bitcoin/pull/25665#issuecomment-1427053301)
Concept ACK.

💬 saadbitcoin commented on pull request "doc: Remove copyright years (headers only)":
(https://github.com/bitcoin/bitcoin/pull/26817#issuecomment-1427058675)
> سنوات حقوق التأليف والنشر لها العديد من القضايا:
>
> * قد يكونون مخطئين. على سبيل المثال ، يمكن أن يحدث هذا عندما يتم نقل الكود من ملف إلى آخر دون الاستيلاء على سنوات حقوق النشر. أو قد يحدث عندما يتم إدخال السنوات الخاطئة بواسطة برنامج نصي أو مطور.
> * هم زائدة عن الحاجة. `git`يتتبع بالفعل تاريخ المؤلف لكل سطر من التعليمات البرمجية في كل التزام.
> * ليست هناك حاجة لإنشاء "حقوق الطبع والنشر" ، راجع https://www.linuxfoundation.org/blog/copyright-notices-in-open-source-software-projects/ ، أ
...