💬 achow101 commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1433281929)
`Read` requires an unserializable object as a parameter, and since this record has 2 objects, using `Read()` is a non-trivial change.

💬 achow101 commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1433282244)
Both are now a variant in a new struct, so should no longer be a problem.

💬 achow101 commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1433282276)
Done

💬 achow101 commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1433282437)
Moved this to the commit where it actually matters, so should hopefully make more sense.

💬 achow101 commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1433282519)
Done

💬 achow101 commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1433282680)
I've added an `Assume` here. There isn't really a valid failure scenario here other than write failure.

💬 achow101 commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1433282737)
Done

💬 achow101 commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1433283055)
These can fail because the key may or may not be encrypted. I've added a few comments.

💬 achow101 commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1433283360)
I've changed it to `Assume`. Also changed the flag setting to only occur if there were no other problems.

💬 achow101 commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1433283984)
Added a comment. The purpose is to be consistent so that the user is not confused. Otherwise an import could change the result of `gethdkey` unexpectedly. With the future `sethdseed` change, `gethdkey`'s result being different will at least be explicit, whereas an import may or may not change the detection of the hd key, depending on what else is/has been imported.

💬 achow101 commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1433284084)
Done as suggested.

💬 achow101 commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1433284159)
Removed

💬 achow101 commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1433284534)
I prefer these checks to be in the function itself rather than the caller for these upgrades as we may want to call these from elsewhere in the future.

⚠️ FUSION9999 opened an issue: "Transfer from closed coinbase acc."
(https://github.com/bitcoin/bitcoin/issues/29126)
My coinbase acc was closed for unknown reason, called and dowloaded bitcoin wallet transfered funds but was 13hrs to sync. Now its only 15% in 24hrs. WHF I have no idea what to do need help.

💬 stickies-v commented on pull request "Nuke adjusted time (attempt 2)":
(https://github.com/bitcoin/bitcoin/pull/28956#discussion_r1433289091)
This does seem to change warning behaviour, in that:
1. it isn't logged anymore
2. there's no more pop-up message for bitcoin-qt

Is that intentional?

💬 achow101 commented on pull request "sqlite: Disallow writing from multiple `SQLiteBatch`s":
(https://github.com/bitcoin/bitcoin/pull/29112#discussion_r1433301783)
Fixed. Also pulled the test with a few changes.

💬 achow101 commented on pull request "sqlite: Disallow writing from multiple `SQLiteBatch`s":
(https://github.com/bitcoin/bitcoin/pull/29112#discussion_r1433301862)
Fixed

💬 achow101 commented on pull request "sqlite: Disallow writing from multiple `SQLiteBatch`s":
(https://github.com/bitcoin/bitcoin/pull/29112#discussion_r1433301957)
Fixed

📝 maaku opened a pull request: "Use hardened runtime on macOS release builds."
(https://github.com/bitcoin/bitcoin/pull/29127)
The Apple notary service requires submitted app bundles to be configured to use the hardened runtime libraries. This is configured at signing time, and supported by the signapple tool Bitcoin Core uses for reproduceable signed binaries. We simply need to pass "--hardened-runtime" when the signature is created. Once attached to the bundle, the resulting codesigned binary can be successfully submitted to the Apple binary notarization service by any Apple Developer.

This partially resolves #1
...

💬 achow101 commented on pull request "fuzz: coinselection, improve `min_viable_change`/`change_output_size`":
(https://github.com/bitcoin/bitcoin/pull/28372#issuecomment-1865318624)
ACK cd810075eddd8b1a7139559b475b56126f70a93d