💬 mzumsande commented on pull request "p2p: make block download logic aware of limited peers threshold":
(https://github.com/bitcoin/bitcoin/pull/28120#discussion_r1491664859)
ok, makes sense!

👍 hernanmarino approved a pull request: "doc: Update translation process guide"
(https://github.com/bitcoin/bitcoin/pull/29414#pullrequestreview-1883922565)
ACK 3b0ec06d6228d965e9cf9121c5dd300da2a930ea
It might be interesting to add to this guide the details expressed in this comment https://github.com/bitcoin-core/gui/pull/793#issuecomment-1943421925

💬 DoctorBuzz1 commented on issue "Move from Static Dust Limit [330 / 546 sats] to Variable Dust Limit [= to TxFee]":
(https://github.com/bitcoin/bitcoin/issues/29423#issuecomment-1947534729)
> So this tx will be considered dust and won't get relayed if such solution is implemented: [bdc168f1d6c38c66c762ccb36655a118436347b074f4a1ff1c8cad4e7429ae0f](https://mempool.space/tx/bdc168f1d6c38c66c762ccb36655a118436347b074f4a1ff1c8cad4e7429ae0f)?

Soo.... if we take my 2nd proposal of

`if (3Tx < TxFee) {isDust = True;}`

And adjust it just a tad to:

`if (4Tx < TxFee) {isDust = True;}`

Then that Tx would be able to be relayed & mined. Any more examples?

💬 kevkevinpal commented on pull request "test/BIP324: disconnection scenarios during v2 handshake":
(https://github.com/bitcoin/bitcoin/pull/29431#discussion_r1491842216)
doesn't the `+1` make the `garbage_len` greater than `4095` which is what is being covered in `TestType.EXCESS_GARBAGE`

💬 kevkevinpal commented on pull request "test/BIP324: disconnection scenarios during v2 handshake":
(https://github.com/bitcoin/bitcoin/pull/29431#discussion_r1491843089)
never mind randrange doesn't include the value passed

💬 stratospher commented on pull request "test/BIP324: disconnection scenarios during v2 handshake":
(https://github.com/bitcoin/bitcoin/pull/29431#discussion_r1491901555)
yes!

💬 DoctorBuzz1 commented on issue "Move from Static Dust Limit [330 / 546 sats] to Variable Dust Limit [= to TxFee]":
(https://github.com/bitcoin/bitcoin/issues/29423#issuecomment-1947681819)
> So this tx will be considered dust and won't get relayed if such solution is implemented: [bdc168f1d6c38c66c762ccb36655a118436347b074f4a1ff1c8cad4e7429ae0f](https://mempool.space/tx/bdc168f1d6c38c66c762ccb36655a118436347b074f4a1ff1c8cad4e7429ae0f)?

Are you able to explain what's happening in this Tx? Why is it overpaying 3x what's necessary to get into the block when 25 sats/vByte definiely would've made it into the next block?

If the TxFee is 25,582 sats.... how is that distributed amo
...

💬 glozow commented on issue "Gathering Priorities of 28.0":
(https://github.com/bitcoin/bitcoin/issues/29439#issuecomment-1947800641)
Package Relay #27463

💬 maflcko commented on pull request "lint: Check for missing bitcoin-config.h includes":
(https://github.com/bitcoin/bitcoin/pull/29408#issuecomment-1947928214)
Ok, this (The signed, previous to last commit) is ready for review.

I'll drop the last commit (merge commit) once and if it is merged.

💬 maflcko commented on issue "Move from Static Dust Limit [330 / 546 sats] to Variable Dust Limit [= to TxFee]":
(https://github.com/bitcoin/bitcoin/issues/29423#issuecomment-1947951310)
> a more compatible solution might be to define it as a UTXO that cannot be economically spent at the fee level of the transaction creating it (or a multiplier of said fee)

That doesn't work either, because it is trivial to side-step. For example, one could create the transaction at a lower fee rate to create the dust, then raise the fee by creating a descendant transaction with a higher fee. (The result would be that the opposite of what this proposal is trying to achieve, is achieved). Anot
...

✅ maflcko closed an issue: "Move from Static Dust Limit [330 / 546 sats] to Variable Dust Limit [= to TxFee]"
(https://github.com/bitcoin/bitcoin/issues/29423)

💬 maflcko commented on issue "Move from Static Dust Limit [330 / 546 sats] to Variable Dust Limit [= to TxFee]":
(https://github.com/bitcoin/bitcoin/issues/29423#issuecomment-1947953302)
Not sure what the goal of this issue is. Anyone wanting to change the dust relay fee can already do so with the `-dustrelayfee` setting. In any case, if there is a technical sound proposal with proper motivation and a complete discussion of the effects on wallet software as well as P2P relay policy interactions, no one is holding anyone back from proposing those changes as a pull request, a BIP, or as a discussion with the broader ecosystem to gather feedback, for example https://groups.google.c
...

💬 BrandonOdiwuor commented on issue "gen-manpages output depends on build options, so needs to check them":
(https://github.com/bitcoin/bitcoin/issues/17506#issuecomment-1947968598)
@theStack @hebasto @laanwj is the goal of this to generate just the missing docs or to generate all docs

💬 maflcko commented on issue "gen-manpages output depends on build options, so needs to check them":
(https://github.com/bitcoin/bitcoin/issues/17506#issuecomment-1947980558)
The goal is to add a check to the script, as described in this issue.

🤔 vasild reviewed a pull request: "Improve new LogDebug/Trace/Info/Warning/Error Macros"
(https://github.com/bitcoin/bitcoin/pull/29256#pullrequestreview-1884614153)
> Make them all accept log categories, to make it possible to filter or highlight log messages from a particular component.

This seems like a step in the right direction. Currently we log messages unconditionally that don't have a category. But this is mixing two separate things - facility and severity. I have always found this confusing.

They got it right decades ago with [syslog(3)](https://www.man7.org/linux/man-pages/man3/syslog.3.html). Every log message has a facility and a severity.
...

💬 vasild commented on issue "Gathering Priorities of 28.0":
(https://github.com/bitcoin/bitcoin/issues/29439#issuecomment-1948001052)
Broadcast own transactions only via short-lived Tor or I2P connections https://github.com/bitcoin/bitcoin/pull/29415

💬 bigspider commented on pull request "Reenable OP_CAT":
(https://github.com/bitcoin/bitcoin/pull/29247#issuecomment-1948016168)
> **Rationale:** It explicitly disables open ended second order effects by removing the ability to assemble a SIGHASH or CTV template on the stack for more detailed introspection than intended. If such introspection behavior is desired in the future it can be explicitly enabled by specialized and more efficient opcodes.

Script is already expressive enough to (awkwardly, expensively) compute arbitrary SHA256 hashes on the stack, except that the result would be broken in smaller pieces of at mo
...

💬 TheCharlatan commented on pull request "kernel: Remove dependency on CScheduler":
(https://github.com/bitcoin/bitcoin/pull/28960#issuecomment-1948024853)
Updated 75931055b84d1f0e9f44d3d3efc28785fd23e66c -> 316c7c845036cbffa22b9e44f31dca8573ffb639 ([noGlobalSignals_17](https://github.com/TheCharlatan/bitcoin/tree/noGlobalSignals_17) -> [noGlobalSignals_18](https://github.com/TheCharlatan/bitcoin/tree/noGlobalSignals_18), [compare](https://github.com/TheCharlatan/bitcoin/compare/noGlobalSignals_17..noGlobalSignals_18))

* Addressed @furszy's [comment](https://github.com/bitcoin/bitcoin/pull/28960#discussion_r1491488517), correcting docstring.

🤔 naumenkogs requested changes to a pull request: "net: attempts to connect to all resolved addresses when connecting to a node"
(https://github.com/bitcoin/bitcoin/pull/28834#pullrequestreview-1884670140)
Mostly looks good, let me know what you think about the suggestions.

💬 naumenkogs commented on pull request "net: attempts to connect to all resolved addresses when connecting to a node":
(https://github.com/bitcoin/bitcoin/pull/28834#discussion_r1492195357)
nit: would be nice to say `XYZ (pszDest) is provided` instead of `pszDest is provided`