💬 maflcko commented on pull request "RFC: Remove boost usage from kernel api / headers":
(https://github.com/bitcoin/bitcoin/pull/28335#discussion_r1395234732)
use `using` for new code? Also could remove the duplicate `CTxMemPoolEntryRef` decl in this pull (see my diff from the last pull)

💬 maflcko commented on pull request "refactor: Replace sets of txiter with CTxMemPoolEntryRefs":
(https://github.com/bitcoin/bitcoin/pull/28886#issuecomment-1813897056)
```
test 2023-11-15T23:32:10.957000Z TestFramework (ERROR): Assertion failed
Traceback (most recent call last):
File "/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/test/functional/test_framework/test_framework.py", line 132, in main
self.run_test()
File "/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/test/fu
...

⚠️ shufps opened an issue: "Verfication of provided pruned database"
(https://github.com/bitcoin/bitcoin/issues/28887)
### Please describe the feature you'd like to see added.

If I understood it right, the risk of using a pruned database from someone is that the UTXOs could be manipulated.

It would easily be possible to create a UTXO checksum that is compared with other nodes to find out if it is valid or not - instead of downloading the entire chain.



### Is your feature related to a problem, if so please describe it.

Downloading the entire chain takes a long time.

Problem is getting bigger and big
...

💬 maflcko commented on issue "Verfication of provided pruned database":
(https://github.com/bitcoin/bitcoin/issues/28887#issuecomment-1813979721)
Are you aware of assumeutxo?

📝 TheCharlatan converted_to_draft a pull request: "refactor: Replace sets of txiter with CTxMemPoolEntryRefs"
(https://github.com/bitcoin/bitcoin/pull/28886)
Currently the mempool returns and consumes sets of multiindex iterators in its public API. A likely motivation for this over working with references to the actual values is that the multi index interface works with these iterators and not with pointers or references to the actual values.

However, using the iterator type in the `setEntries` set provides little benefit in practice as applied currently. Its purpose, ownership, and safety semantics often remain ambiguous, and it is hardly used fo
...

💬 Retropex commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1813986420)
Congratulations, what some feared finally [happened](https://x.com/mononautical/status/1724943620888006802?s=20) without us doing anything.

@Glozow luke added the tests weeks ago, it is more than time to review this PR, you are in charge of the mempool and it is in a disastrous state with no less than 200,000 spam transactions.

This trend also seems to be accelerating with waves of spam getting closer and closer.

I may repeat myself but these spam transactions make the real usefulness o
...

💬 shufps commented on issue "Verfication of provided pruned database":
(https://github.com/bitcoin/bitcoin/issues/28887#issuecomment-1813994660)
> Are you aware of assumeutxo?

Didn't know it. Thx a lot!

Bootstrapping from an UTXO snapshot is even better than just validating the UTXOs and actually it's been common practice in several crypto currencies for a long time.

💬 maflcko commented on issue "Verfication of provided pruned database":
(https://github.com/bitcoin/bitcoin/issues/28887#issuecomment-1813998365)
Ok, closing for now. Let us know if you have any other questions.

Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base. General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat.

✅ maflcko closed an issue: "Verfication of provided pruned database"
(https://github.com/bitcoin/bitcoin/issues/28887)

🤔 S3RK reviewed a pull request: "wallet: Have the wallet store the key for automatically generated descriptors"
(https://github.com/bitcoin/bitcoin/pull/26728#pullrequestreview-1726760385)
I finished going through all commits one-by-one. Need a bit more time to check comprehensively how HD flag is set at creation/migration/upgrade and redo my manual tests.

💬 S3RK commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1390757392)
in 18dc28f14ee1de561625913d286d68031ab9b3dd

nit: it could've been just `std:map<keyid, key>` since `desc_id` is not used

💬 S3RK commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1395327696)
in e3c292b298e5e6f2ec319fb93ba67fd64a0f4ac1

if `key_hex not in k` then `ckey_hex not in k` is always true by definition
Therefore `key_hex not in k and ckey_hex not in k` seems redundant to me.

💬 S3RK commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1390758254)
in 18dc28f14ee1de561625913d286d68031ab9b3dd

nit: it could've been just `std::map<keyid, ckey>` since `desc_id` and `pubkey` are not used

💬 S3RK commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1392138071)
@achow101 IIUC you addressed this as well

💬 S3RK commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1395310367)
in 2657c1295cb156d6021844edf18b1a4dc5ce7136

nit: can also check that HD key is the same as return by the old version (e.g. by checking fingerprint with `hdmasterfingerprint`)

💬 S3RK commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1390768618)
in 52697ecc3fd46fdf3c02eba0d474949a9d05d885

nit: can test that `gethdkey(False)` succeeds on encrypted and locked wallet

💬 S3RK commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1390770187)
in 52697ecc3fd46fdf3c02eba0d474949a9d05d885

nit: maybe add a comment, that you're checking key rotation and non-active descriptors should have pre-rotation key

💬 S3RK commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1395330786)
in e3c292b298e5e6f2ec319fb93ba67fd64a0f4ac1

Relying that all encrypted keys contain `ckey` seems fragile. Can we maybe list all the encrypted key records?

📝 miz1choobi opened a pull request: "Update .editorconfig"
(https://github.com/bitcoin/bitcoin/pull/28888)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

📝 airdropbaaz opened a pull request: "Update .cirrus.yml"
(https://github.com/bitcoin/bitcoin/pull/28889)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...