👍 TheCharlatan approved a pull request: "doc: Add multiprocess design doc"
(https://github.com/bitcoin/bitcoin/pull/28978#pullrequestreview-1796867156)
ACK 91dc48c14825a9075a57c1eefda202b83b6346ba
(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.
(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.
(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
(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?
(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
(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
...
(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`.
(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.
(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.
(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.
(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.
...
(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?
(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
...
(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)
(https://github.com/bitcoin/bitcoin/issues/29146)
💬 maflcko commented on issue "[Bug]: Blockspace price shouldn't be higher for a simple transaction (price discrimination against simple txs)":
(https://github.com/bitcoin/bitcoin/issues/29146#issuecomment-1870433246)
Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base.
General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat, or one of the Bitcoin subreddits, or any other place that you feel is well suited.
Network-wide consensus and/or P2P changes first need to be discussed with the greater community, for example the `bitcoin-dev` maili
...
(https://github.com/bitcoin/bitcoin/issues/29146#issuecomment-1870433246)
Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base.
General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat, or one of the Bitcoin subreddits, or any other place that you feel is well suited.
Network-wide consensus and/or P2P changes first need to be discussed with the greater community, for example the `bitcoin-dev` maili
...
💬 maflcko commented on pull request "rpc: Remove deprecated -rpcserialversion":
(https://github.com/bitcoin/bitcoin/pull/28890#issuecomment-1870437050)
The deprecation was covered in https://bitcoinops.org/en/newsletters/2023/09/20/ and 26.0 was released a few weeks ago. Unless anyone heard someone complain, this seems good to move forward now?
(https://github.com/bitcoin/bitcoin/pull/28890#issuecomment-1870437050)
The deprecation was covered in https://bitcoinops.org/en/newsletters/2023/09/20/ and 26.0 was released a few weeks ago. Unless anyone heard someone complain, this seems good to move forward now?
🤔 sipa reviewed a pull request: "refactor: share and use `GenerateRandomKey` helper"
(https://github.com/bitcoin/bitcoin/pull/28455#pullrequestreview-1797358660)
utACK fa1d49542e4b69a5d8b1177ffe4207f051a468bb
(https://github.com/bitcoin/bitcoin/pull/28455#pullrequestreview-1797358660)
utACK fa1d49542e4b69a5d8b1177ffe4207f051a468bb
💬 kristapsk commented on pull request "rpc: Remove deprecated -rpcserialversion":
(https://github.com/bitcoin/bitcoin/pull/28890#issuecomment-1870467659)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/28890#issuecomment-1870467659)
Concept ACK
👍 kristapsk approved a pull request: "refactor: share and use `GenerateRandomKey` helper"
(https://github.com/bitcoin/bitcoin/pull/28455#pullrequestreview-1797365533)
cr utACK fa1d49542e4b69a5d8b1177ffe4207f051a468bb
(https://github.com/bitcoin/bitcoin/pull/28455#pullrequestreview-1797365533)
cr utACK fa1d49542e4b69a5d8b1177ffe4207f051a468bb