💬 brunoerg commented on pull request "wallet, rpc: add BIP44 `account` in `createwallet`":
(https://github.com/bitcoin/bitcoin/pull/29129#issuecomment-1869859555)
> Feels like this could be confused with real/beancounter accounts like we used to support years ago. Maybe hd_account or something?

I agree, had same thought. Just changed in latest push.

💬 brunoerg commented on pull request "wallet, rpc: add BIP44 `account` in `createwallet`":
(https://github.com/bitcoin/bitcoin/pull/29129#issuecomment-1869860600)
> I think this might be a better candidate for a createwalletdescriptor (https://github.com/bitcoin/bitcoin/pull/29130) equivalent for external signers rather than continuing to jam more arguments into createwallet.

You mean have a specific RPC for external signers or extending `createwalletdescriptor`?

🤔 ryanofsky reviewed a pull request: "doc: Add multiprocess design doc"
(https://github.com/bitcoin/bitcoin/pull/28978#pullrequestreview-1796742782)
Updated c80bd16c826d564086006cff67b7b9ade9b9f38c -> 91dc48c14825a9075a57c1eefda202b83b6346ba ([`pr/ipcdoc.10`](https://github.com/ryanofsky/bitcoin/commits/pr/ipcdoc.10) -> [`pr/ipcdoc.11`](https://github.com/ryanofsky/bitcoin/commits/pr/ipcdoc.11), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipcdoc.10..pr/ipcdoc.11)) fixing table tag and reference heading.

I think this PR gets another ACK it could be merged to add the new documentation, and improvements could be implemented in
...

💬 ryanofsky commented on pull request "doc: Add multiprocess design doc":
(https://github.com/bitcoin/bitcoin/pull/28978#discussion_r1436732897)
> I think you meant to close/end the table here. Otherwise this looks a bit weird rendered on GitHub.

Good catch should be fixed now

💬 maaku commented on pull request "Use hardened runtime on macOS release builds.":
(https://github.com/bitcoin/bitcoin/pull/29127#issuecomment-1869955897)
There is literally no way for macOS to tell the difference between a signed-but-not-notarized app, and a signed-and-notorized-but-not-stapled app. They are bit-for-bit identical. The way macOS tells if it is notarized, if the notarization is not stapled, is that it phones home and asks.

Apparently @jonasschnelli ran some experiment in which he used Wireshark to test under what circumstances the gatekeeper phones home. However his description of the experiment he ran was on his own website, an
...

👍 TheCharlatan approved a pull request: "doc: Add multiprocess design doc"
(https://github.com/bitcoin/bitcoin/pull/28978#pullrequestreview-1796867156)
ACK 91dc48c14825a9075a57c1eefda202b83b6346ba

💬 1440000bytes commented on pull request "Change Luke Dashjr seed to dashjr-list-of-p2p-nodes-maybe-malware.us":
(https://github.com/bitcoin/bitcoin/pull/29145#discussion_r1436839388)
I am not sure why you got a domain with 'malware' in its name from namecheap for using as DNS seed in bitcoin core.

Related question (although out of scope for this PR): If there are so many issues with DNS seeds, why not disable `dnsseed` and `fixedseeds`? Instead 9 developers running DNS seeds can provide a node address which can be used for `seednode` to get node addresses using GETADDR. Or make bootstrapping work like tor nodes for all nodes.

💬 Sjors commented on pull request "rpc: add path to gethdkey":
(https://github.com/bitcoin/bitcoin/pull/22341#issuecomment-1870069651)
@ryanofsky building on #29130 introduces a new argument to specify which master key you intend to use.

💬 Sjors commented on pull request "refactor: share and use `GenerateRandomKey` helper":
(https://github.com/bitcoin/bitcoin/pull/28455#issuecomment-1870078430)
re-ACK fa1d49542e4b69a5d8b1177ffe4207f051a468bb

💬 maflcko commented on pull request "wallet: add meaningful error message and fix test":
(https://github.com/bitcoin/bitcoin/pull/29143#issuecomment-1870086126)
Do you have steps to reproduce the test failure (usually a race can be reproduced by adding a sleep in the right place in the C++ code)?

Also, an assertion crash fix, is not a "test" fix. I presume this can happen in production, no?

💬 0xB10C commented on pull request "init: handle empty settings file gracefully":
(https://github.com/bitcoin/bitcoin/pull/29144#issuecomment-1870230561)
see previous discussion in #23096

💬 brunoerg commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#issuecomment-1870257103)
> Tested it with bitcoin-qt and I'm wondering if later as a follow-up we could add a feature as a "nice to have" to identify the "whitelisted" peers (and it permissions passed) in the Peers tab on the Node window (we [show](https://bitcoinexplorer.org/rpc-browser?method=getpeerinfo) already the permissions@ on RPC getpeerinfo but not sure about other details on -whitelist or -whitebind and if we want to provide that info via RPC). There's already a "related" GUI https://github.com/bitcoin-core/g
...

💬 brunoerg commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1437017791)
I don't think so because it is not changing the default behaviour of `-whitebind`.

💬 brunoerg commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1437019900)
> (default: incoming only - e.g. noban,in,out@1.2.3.4)

I think it might misconfuse. It seems the example (e.g) refers to the default behaviour.

💬 brunoerg commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1437020771)
I don't think so, because we're not changing the default behaviour of `-whitebind`. The additional flags are specified only in `-whitelist` documentation.

💬 petertodd commented on pull request "Change Luke Dashjr seed to dashjr-list-of-p2p-nodes-maybe-malware.us":
(https://github.com/bitcoin/bitcoin/pull/29145#discussion_r1437042749)
There are advantages and disadvantages to both DNS seeds and fixed seeds. Having both is good.

Discussing this doesn't need to happen here on this straightforward pull-req.

🤔 furszy reviewed a pull request: "init: handle empty settings file gracefully"
(https://github.com/bitcoin/bitcoin/pull/29144#pullrequestreview-1797199209)
> see previous discussion in #23096, #22591, and [#21340 (comment)](https://github.com/bitcoin/bitcoin/issues/21340#issuecomment-880147010)

Hmm, okay, agree. Thanks.
It would probably be useful to introduce support for comments. This way, we can write something at the beginning of the file, ensuring that users and other software developers don't clean this file manually, thinking that it will be regenerated automatically. Do you know if something like this has been proposed before? @0xB10C.
...

💬 GregTonoski commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1870318175)
Why not simply depracating OP_IF?

⚠️ GregTonoski opened an issue: "Blockspace price shouldn't be higher for a simple transaction (price discrimination against simple txs)"
(https://github.com/bitcoin/bitcoin/issues/29146)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Blockspace price for data of a simple transaction is higher than the one for data of other ("complex") transactions, e.g.
3=616 weight / 205 bytes [aabbcce67f2aa71932f789cac5468d39e3d2224d8bebb7ca2c3bf8c41d567cdd](https://mempool.space/tx/aabbcce67f2aa71932f789cac5468d39e3d2224d8bebb7ca2c3bf8c41d567cdd)
vs
1.49=1140 weight / 767 bytes [1c35521798dde4d1621e9aa5a3bacac03100fca40b6fb99be5
...

✅ maflcko closed an issue: "[Bug]: Blockspace price shouldn't be higher for a simple transaction (price discrimination against simple txs)"
(https://github.com/bitcoin/bitcoin/issues/29146)