💬 ismaelsadeeq commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1432807598)
Nit: I find `tx_iter` more readable than `package_iter`, since its a transaction iterator not package iterator
```suggestion
for (auto tx_iter = package.rbegin(); tx_iter != package.rend(); ++tx_iter) {

```

💬 ismaelsadeeq commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1432824698)
We can just skip if the ancestor has the transaction in it's descendant set?
```suggestion
if (ancestors_descendant_set.count((*tx_iter)->GetHash()) == 0 ) {
ancestors_descendant_set.insert(my_descendant_set.cbegin(), my_descendant_set.cend());
```

💬 ismaelsadeeq commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1432811937)
Nit: IMO its more readable to define an intermediate txid variable here also just like its done in the for loop above
```suggestion
const Txid& my_txid{(*package_iter)->GetHash()};
if ((*package_iter)->nVersion == 3) {
```

💬 ismaelsadeeq commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1434138603)
why increment `num_prechecks_passed` here ?

💬 ismaelsadeeq commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1434137263)
After restarting here, we are restarting at the beginning of the test again with extra args
Dev notes says
> [Avoid stop-starting the nodes multiple times during the test if possible. A stop-start takes several seconds, so doing it several times blows up the runtime of the test.](https://github.com/bitcoin/bitcoin/blob/master/test/functional/README.md#style-guidelines)

The wrapper can accept the extra args as argument and restart at the beginning only ?
<details>

```python
def cleanup(
...

💬 ismaelsadeeq commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1434122383)
`CheckMempoolV3Invariants` docstring says we would verify
>any non-v3 tx must only have non-v3 ancestors

We are only getting parents and checking the first parent?

💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1434150244)
I disagree, I think we should exit as early as possible when something is too big and avoid needing to do expensive things like load a bunch of UTXOs from disk. The next line says "Important: this function is insufficient to enforce" etc.

💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1434152018)
This function is documented as "Should not be called for non-v3 packages."

💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1434153256)
There's only 1 parent allowed, so this code takes a shortcut of only looking at the first one. Maybe it's better to edit the function params so callers can only pass 1 entry in.

💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1434154836)
Ah you're right, fixing

👍 alfonsoromanz approved a pull request: "wallet: Allow user to navigate options while encrypting at creation"
(https://github.com/bitcoin-core/gui/pull/722#pullrequestreview-1793165080)
Tested ACK https://github.com/bitcoin-core/gui/pull/722/commits/78660e72001a2561c7ad3026367a69f65414dbd9

<img width=50% height=50% alt="2" src="https://github.com/bitcoin-core/gui/assets/19962151/2c980809-10c1-43a2-bd59-bfe2bf42e285">
<img width=50% height=50% alt="3" src="https://github.com/bitcoin-core/gui/assets/19962151/202aeab0-734e-471c-b796-a5e819bc43ed">
<img width=50% height=50% alt="4" src="https://github.com/bitcoin-core/gui/assets/19962151/f7fafdf0-569d-4d96-83aa-94e0843c1a2e">
...

🤔 stratospher reviewed a pull request: "refactor: share and use `GenerateRandomKey` helper"
(https://github.com/bitcoin/bitcoin/pull/28455#pullrequestreview-1793127590)
Concept ACK. I think this is a useful refactor to have since it's more modular to have `GenerateRandomKey` in `key.cpp` rather than net code.

> I found these by doing grep -nri "MakeNewKey" ./src --binary-files=without-match
do we plan on making this modification to these files aswell?

@kevkevinpal, it makes sense to do this refactor when we're instantiating a CKey object and also filling the value together in the same line. we can't do this in arrays for example, where the instantiation
...

💬 stratospher commented on pull request "refactor: share and use `GenerateRandomKey` helper":
(https://github.com/bitcoin/bitcoin/pull/28455#discussion_r1434172881)
81187d0: we'd need to `#include <key.h>` since we're still using `GenerateRandomKey()` in `src/net.cpp`

💬 farahats9 commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1866531134)
Just wanted to add my 2 cents here as a layman using and holding bitcoin. If the transaction fee rates remain this high for someone using bitcoin to transfer money from wallet A to wallet B then I don't see a future for bitcoin.

The original goal of bitcoin is to make it a currency and a valued asset, if you sacrifice doing this in order to have secondary features then you will fail at both.

If this PR will fix the fee rates back to normal I am on board.

👍 theuni approved a pull request: "build: switch to using LLVM 17.x for macOS builds"
(https://github.com/bitcoin/bitcoin/pull/28880#pullrequestreview-1793294921)
ACK b335710782c2545e6eeed67b5e1763c07eab26b0.

Amazing detective work on the qt determinism fixes 🤯 !

I haven't tested or scrutinized to determine if that's the minimal patching we need. This seems low-impact enough it doesn't really matter if it's a bit heavy-handed.

💬 achow101 commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1434279569)
Good point, done.

💬 SomberNight commented on issue "macOS App Notarization":
(https://github.com/bitcoin/bitcoin/issues/15774#issuecomment-1866611776)
Does the OS not phone home if the application is not notarized?
If so, how can it distinguish notarized+not_stapled vs not_notarized applications?

💬 ryanofsky commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#issuecomment-1866636473)
@Sjors and @S3RK, can you help me out by being specific about the flows you have in mind? Like in terms of what RPC calls users will make to do a particular operation? I'm trying to fill in the gaps myself, but in the cases I can think of, it seems like adding the concept of a sticky master key doesn't actually make things simpler, just more opaque and confusing.

I understand that if you were designing a new wallet model and API, you would both prefer an approach that required all active desc
...

💬 achow101 commented on pull request "wallet: fix key parsing check for miniscript expressions":
(https://github.com/bitcoin/bitcoin/pull/29027#issuecomment-1866645491)
ACK e1281f1bbd884f15d40053c9bc24794d0ce9a58a

🚀 achow101 merged a pull request: "wallet: fix key parsing check for miniscript expressions"
(https://github.com/bitcoin/bitcoin/pull/29027)