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

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

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

🤔 sipa reviewed a pull request: "refactor: share and use `GenerateRandomKey` helper"
(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

👍 kristapsk approved a pull request: "refactor: share and use `GenerateRandomKey` helper"
(https://github.com/bitcoin/bitcoin/pull/28455#pullrequestreview-1797365533)
cr utACK fa1d49542e4b69a5d8b1177ffe4207f051a468bb

🤔 stratospher reviewed a pull request: "refactor: share and use `GenerateRandomKey` helper"
(https://github.com/bitcoin/bitcoin/pull/28455#pullrequestreview-1797370883)
ACK fa1d495.

💬 kristapsk commented on pull request "Modify command line help to show support for BIP21 URIs":
(https://github.com/bitcoin-core/gui/pull/752#discussion_r1437157234)
Square brackets mean that URI option is optional. Either use "[URI]" or "Optional URI" below, not "Optional [URI]".
```suggestion
"Optional URI is a bitcoin address in BIP21 URI format.\n";
```

⚠️ kristapsk opened an issue: ""Open bitcoin URI" dialog could give more feedback on what's wrong with BIP21 URI"
(https://github.com/bitcoin-core/gui/issues/784)
### Please describe the feature you'd like to see added.

Currently, when trying to open URI, if it's invalid, clicking "OK" will just colour it red, instead of giving any feedback, what's exactly wrong with URI.


In my test I added unknown required paramter `req-test=1`. Feedback on that would be useful for user, for example, [BIP77 Payjoin v2 draft](https://github.com/bitcoin/bips/pull/1483)
...

💬 asggWa commented on issue "./bitcoin.conf file should not cause confusion with ./datadir/bitcoin.conf":
(https://github.com/bitcoin/bitcoin/issues/29139#issuecomment-1870516002)
$HOME/snap

💬 kristapsk commented on pull request "Update about logo icon (colour) to denote the chain type of the QT instance in About/ Help Message Window/ Dialog":
(https://github.com/bitcoin-core/gui/pull/762#discussion_r1437190084)
nit
```suggestion
const QSize requiredSize(1024, 1024);
```

💬 ybaidiuk commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1870530971)
Ok filter is bad idea because of censoring and disable OP_RETRUN is not an Option,
but we still have free market violation (fee)
People do not pay full price to put data in blockchain, they do abuse of fee-free size of OP_RETRUN.

In this case, will be doing nothing is a good solution.
But i think the best option will be to reduce size of OP_RETURN to 40 bytes like it was before.
It will make fee-abuse more expensive and create stimulation to move data into side chains.