💬 maflcko commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1378666698)
`ConsumeDeserializable` is never called with witness deserialization disabled. I wonder if it makes sense to offer a shorter version with the param set as default?

💬 maflcko commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1378633900)
Not sure if the comments adds value to someone reading the lines of code here?

⚠️ DuneCruzade opened an issue: "IOS SONOMA"
(https://github.com/bitcoin/bitcoin/issues/28767)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

The .dmg file for M1, from bitcoincore.org dowload page, is not working. Can´t install/run bitcoin core in my mac.


### Expected behaviour

would like to run bitcoin core on my mac

### Steps to reproduce

nothing happens.

the arm64 (.dmg) just dont run

### Relevant log output

none

### How did you obtain Bitcoin Core

Compiled from source

### What version of Bitcoin Core are yo
...

💬 ajtowns commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1378693720)
I changed to the newer streams in places where I noticed it was obviously sensible, but didn't try to be thorough about it, since being complete required extra changes like #28451. The fact that `SERIALIZE_TRANSACTION_NO_WITNESS` no longer exists means that any previous (explicit) embedding of it will have been touched by this changeset, fwiw.

💬 dergoegge commented on pull request "Improve peformance of CTransaction::HasWitness (28107 follow-up)":
(https://github.com/bitcoin/bitcoin/pull/28766#issuecomment-1788831718)
Can someone please re-run the "CI / macOS 13 native" job, failure seems unrelated.

👍 willcl-ark approved a pull request: "wallet: Cleanup accidental encryption keys in watchonly wallets"
(https://github.com/bitcoin/bitcoin/pull/28724#pullrequestreview-1707986305)
ACK aaa6b709d164052c8b2496cbedccf8ccf48c4aa2

I left a few comments, but they're mainly thoughts I had and questions for my own understanding.

Also checked the test manually with `--legacy-wallet` and `--descriptors` and lightly inspected the dumps to ensure the records were being removed:

<details>

<summary>log</summary>

```
$ test/functional/wallet_encryption.py
2023-11-01T11:51:31.078000Z TestFramework (INFO): PRNG seed is: 196471712041506435
2023-11-01T11:51:31.07900
...

💬 willcl-ark commented on pull request "wallet: Cleanup accidental encryption keys in watchonly wallets":
(https://github.com/bitcoin/bitcoin/pull/28724#discussion_r1378657380)
I notice that nothing in this block requires any locks (even though `cs_wallet` will be locked at this stage in this function).

For my own understanding, is this because the db operations, i.e. writing to the on-disk file, have their synchronisation handled by the db's transaction system?

I see for example in `LoadEncryptionKey` that we lock `cs_wallet` to load the keys _into_ the wallet, which makes intuitive sense. But it feels that conversely there should be something asserting the lock
...

💬 willcl-ark commented on pull request "wallet: Cleanup accidental encryption keys in watchonly wallets":
(https://github.com/bitcoin/bitcoin/pull/28724#discussion_r1378684726)
Perhaps a comment to that effect would be useful here as it's not clear directly from the code?

💬 willcl-ark commented on pull request "wallet: Cleanup accidental encryption keys in watchonly wallets":
(https://github.com/bitcoin/bitcoin/pull/28724#discussion_r1378673670)
I was wondering if if could be a good idea to log the removed keys at this point as a backup (safe-ish seeing as we are deleting), but I'm struggling to think of a scenario where a user with this type of wallet might somehow need these keys again...

💬 ajtowns commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1378706743)
I suspect it'd be nicer to have `PushMessage(pfrom, msgMaker.Make(BLOCKTXN, BIP_XXX_TX_COMPRESSION(resp)))` so that net_processing can turn compression on based on whether it's been negotiated or not, and drop `TransactionCompression` entirely? Seems out of scope for this PR either way.

💬 fanquake commented on pull request "Improve peformance of CTransaction::HasWitness (28107 follow-up)":
(https://github.com/bitcoin/bitcoin/pull/28766#issuecomment-1788834198)
> failure seems unrelated.

Are you sure?
```bash
Traceback (most recent call last):
File "/Users/runner/work/bitcoin/bitcoin/ci/scratch/build/bitcoin-x86_64-apple-darwin/test/functional/test_framework/test_framework.py", line 132, in main
self.run_test()
File "/Users/runner/work/bitcoin/bitcoin/ci/scratch/build/bitcoin-x86_64-apple-darwin/test/functional/rpc_createmultisig.py", line 65, in run_test
self.do_multisig()
File "/Users/runner/work/bitcoin/bitcoin/ci/scratch/b
...

💬 vasild commented on pull request "Do the SOCKS5 handshake reliably":
(https://github.com/bitcoin/bitcoin/pull/28649#discussion_r1378708089)
I prefer to keep all implementation in one place and to keep the interface separate from the implementation.

💬 dergoegge commented on pull request "Improve peformance of CTransaction::HasWitness (28107 follow-up)":
(https://github.com/bitcoin/bitcoin/pull/28766#issuecomment-1788837597)
> Are you sure?

Yes, it passes locally.

💬 fanquake commented on pull request "Improve peformance of CTransaction::HasWitness (28107 follow-up)":
(https://github.com/bitcoin/bitcoin/pull/28766#issuecomment-1788841475)
Want to document it as an intermittent failure?

🤔 stickies-v reviewed a pull request: "Improve peformance of CTransaction::HasWitness (28107 follow-up)"
(https://github.com/bitcoin/bitcoin/pull/28766#pullrequestreview-1708054652)
Approach ACK

I had similar thoughts while reviewing 28107 but figured the computation was still fast enough. Given that `ComputeWitnessHash` is only called once during initialization (and is private) and `HasWitness` is called frequently, this approach is strictly better.

💬 stickies-v commented on pull request "Improve peformance of CTransaction::HasWitness (28107 follow-up)":
(https://github.com/bitcoin/bitcoin/pull/28766#discussion_r1378700622)
nit: I'd at least use a range based loop
```suggestion
bool has_witness{false};
for (const auto input : vin) {
if (!input.scriptWitness.IsNull()) {
has_witness = true;
break;
}
}
```

but probably okay to refactor to use `algorithm`?

```suggestion
bool has_witness = std::any_of(vin.begin(), vin.end(), [](const auto& input) {
return !input.scriptWitness.IsNull();
});
```

💬 stickies-v commented on pull request "Improve peformance of CTransaction::HasWitness (28107 follow-up)":
(https://github.com/bitcoin/bitcoin/pull/28766#discussion_r1378705398)
Could simplify return statement too so the whole fn just becomes:


```cpp
Wtxid CTransaction::ComputeWitnessHash() const
{
bool has_witness = std::any_of(vin.begin(), vin.end(), [](const auto& input) {
return !input.scriptWitness.IsNull();
});

return Wtxid::FromUint256(has_witness ? (CHashWriter{0} << *this).GetHash() : hash.ToUint256());
}
```

💬 ajtowns commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1378718755)
Maybe? Being explicit seems not that bad though?

💬 maflcko commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1378716304)
nit: template implies `inline`

💬 maflcko commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1378717260)
nit: (same above), given that this function is only for internal use for this module, and only used twice, is it needed?