💬 maflcko commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1378613214)
This compiles, so I guess it is fine. Two notes:

* This forces bip152-v2-only in the serialize code. I guess it is fine, given https://github.com/bitcoin/bitcoin/pull/20799.

* question: If `TransactionCompression` was ever implemented it wouldn't support serialization without witness? So wouldn't it be cleaner to just implement the `TransactionCompression` formatter as one that calls `(Un)SerializeTransaction` with the witness params set?

💬 maflcko commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1378584333)
review note: I presume reviewers are supposed to set `--function-context` and verify each time that `SERIALIZE_TRANSACTION_NO_WITNESS` was never embedded into the `CDataStream` in each context.

💬 maflcko commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1378615106)
style nit: Forgot to add `{}` when touching this line?

💬 maflcko commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1378584497)
??? What is this?

💬 maflcko commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1378647959)
You'll have to remove `PROTOCOL_VERSION` now. Also, `GetSerializeSize` could drop the int param completely?

💬 maflcko commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1378648420)
any reason for the c-style cast? Why not remove it completely?

💬 maflcko commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1378628768)
Cautofile -> AutoFile?

💬 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.