✅ hebasto closed an issue: "`capnp` fails when cross-compiling"
(https://github.com/bitcoin/bitcoin/issues/28993)

💬 ryanofsky commented on pull request "script, assumeutxo: Enhance validations in utxo_snapshot.sh":
(https://github.com/bitcoin/bitcoin/pull/28852#issuecomment-1839567625)
Note: this actually had 3 acks. DrahtBot didn't count https://github.com/bitcoin/bitcoin/pull/28852#pullrequestreview-1741060818 due to capitalization

💬 ryanofsky commented on issue "`capnp` fails when cross-compiling":
(https://github.com/bitcoin/bitcoin/issues/28993#issuecomment-1839570160)
That makes more sense. Thanks for the bug report in any case!

💬 furszy commented on pull request "rpc: encryptwallet help, mention HD seed rotation and backup requirement":
(https://github.com/bitcoin/bitcoin/pull/28980#discussion_r1414574791)
> "Therefore, it is crucial to make a fresh backup of the newly generated wallet file."

The goal of the "replace" wording is to avoid situations where users restore the wallet from the previous backup, thinking it is the latest one, and blames core for not detecting the balance.

💬 jonatack commented on pull request "rpc: encryptwallet help, mention HD seed rotation and backup requirement":
(https://github.com/bitcoin/bitcoin/pull/28980#discussion_r1414581640)
> and blames core for not detecting the balance

I think I would avoid recommending that users delete their wallet files, as potential loss of funds is a worse case.

💬 furszy commented on pull request "rpc: encryptwallet help, mention HD seed rotation and backup requirement":
(https://github.com/bitcoin/bitcoin/pull/28980#discussion_r1414582511)
> using the `backupwallet` RPC.

I think the current text is slightly better because it alerts users without scaring them.
But, if there is a higher preference for it, could change it.

💬 furszy commented on pull request "rpc: encryptwallet help, mention HD seed rotation and backup requirement":
(https://github.com/bitcoin/bitcoin/pull/28980#discussion_r1414585672)
Sure. Done as suggested

💬 furszy commented on pull request "rpc: encryptwallet help, mention HD seed rotation and backup requirement":
(https://github.com/bitcoin/bitcoin/pull/28980#issuecomment-1839609896)
Updated per feedback. Thanks everyone.

🤔 ryanofsky reviewed a pull request: "doc: Add multiprocess design doc"
(https://github.com/bitcoin/bitcoin/pull/28978#pullrequestreview-1763577959)
Updated f566245147003648099f961306be82ea32ea47ae -> 837c53d14f24924cdcb2cfd8b18915882dc3b620 ([`pr/ipcdoc.7`](https://github.com/ryanofsky/bitcoin/commits/pr/ipcdoc.7) -> [`pr/ipcdoc.8`](https://github.com/ryanofsky/bitcoin/commits/pr/ipcdoc.8), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipcdoc.7..pr/ipcdoc.8)) adding suggested future enhancement and making a few other tweaks

💬 ryanofsky commented on pull request "doc: Add multiprocess design doc":
(https://github.com/bitcoin/bitcoin/pull/28978#discussion_r1414593514)
re: https://github.com/bitcoin/bitcoin/pull/28978#discussion_r1413316233

> * Generating server / client code in different langages (e.g C++ -> Rust or Rust -> C++) from a common set of `capnp` files and with compatible interfaces.

Yes, this significant and worth mentioning. Added some information about this and a link the work you mentioned.

💬 mzumsande commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1414612161)
This could lead to confusing log messages when removing 0-fee (or deprioritized) transactions: Such a tx could be refused due to "size limit" even if the mempool was almost empty.

🤔 mzumsande reviewed a pull request: "v3 transaction policy for anti-pinning"
(https://github.com/bitcoin/bitcoin/pull/28948#pullrequestreview-1763610776)
> Keeping 0-fee parents hanging around in mempool would also allow new entries into the mempool that will never be mined.

Would that be possible with v3, and that's the reason why it's part of this PR? I can see the scenario where the bumping child spends another transaction's input and could get removed when that other tx gets replaced, leaving the 0-fee tx, but wouldn't that scenario be impossible with the v3 limit to one ancestor?

As a side effect, I think this will allow users to remov
...

💬 ishaanam commented on pull request "wallet, rpc: add anti-fee-sniping to `send` and `sendall`":
(https://github.com/bitcoin/bitcoin/pull/28944#discussion_r1414651395)
Done

💬 ishaanam commented on pull request "wallet, rpc: add anti-fee-sniping to `send` and `sendall`":
(https://github.com/bitcoin/bitcoin/pull/28944#discussion_r1414651744)
Done

💬 ishaanam commented on pull request "wallet, rpc: add anti-fee-sniping to `send` and `sendall`":
(https://github.com/bitcoin/bitcoin/pull/28944#discussion_r1414652209)
Done

💬 luke-jr commented on pull request "Fix SSE4.1-related issues":
(https://github.com/bitcoin/bitcoin/pull/28893#issuecomment-1839830013)
Weak Concept NACK: We should probably still build the SSE4.1 code if the compiler supports it. The flag should only affect the rest of the codebase, so that the software will run on a system without SSE4.1 (but still use the optimised crypto on systems that have it).

💬 luke-jr commented on issue "build: Configuring with `-mno-sse4.1` does not fail the sse4.1 instrinsics check":
(https://github.com/bitcoin/bitcoin/issues/28864#issuecomment-1839831023)
This is fixed by #13789 which was inexplicably closed for no reason

💬 luke-jr commented on pull request "wallet: birth time update during tx scanning":
(https://github.com/bitcoin/bitcoin/pull/28920#discussion_r1414735112)
Shouldn't this be `NO_KEY_TIME` explicitly?

💬 luke-jr commented on pull request "wallet: birth time update during tx scanning":
(https://github.com/bitcoin/bitcoin/pull/28920#discussion_r1414735331)
Seems like `NO_KEY_TIME` ought to be `0` so it triggers a full scan

💬 luke-jr commented on pull request "script/sign: avoid duplicated signature verification after signing (+introduce signing benchmarks)":
(https://github.com/bitcoin/bitcoin/pull/28923#issuecomment-1839848382)
Does this reduce our safety against memory corruption or similar?