💬 fanquake commented on issue "ci: failure in `wallet_basic.py --descriptors`":
(https://github.com/bitcoin/bitcoin/issues/29110#issuecomment-1895578477)
https://cirrus-ci.com/task/6509037848625152?logs=ci#L2502

💬 Retropex commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1895579012)
> Please rebase.

Rebased.

💬 moonsettler commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1895601881)
> Concept ACK, what will it take to get this merged? Stamps are absolutely ravaging the UTXO set.

what do we mean by ravaging? afaik the biggest unnecessary bloater of the UTXO set is the stacks protocol.

💬 maflcko commented on pull request "Support self hosted Github workers on forks":
(https://github.com/bitcoin/bitcoin/pull/29259#issuecomment-1895608079)
> splurge on a Cirrus account, and since Github free minutes are limited

A Cirrus account is free for public open source projects, as well as persistent workers connected to it. GitHub "free" minutes should also be unlimited for public open source, no?

> Related: I wrote a [gist](https://gist.github.com/Sjors/cd55370fa67aa095df90c433ee9bd135) for how to run CI on Ubuntu desktop with one runner per window.

Nice, but generally I don't think there is a need to run *all* CI tasks locally, b
...

💬 maflcko commented on pull request "Support self hosted Github workers on forks":
(https://github.com/bitcoin/bitcoin/pull/29259#discussion_r1455306117)
unrelated: Generally I'd find it better if we get rid of the commit range completely. For example, when running the whitespace linter, it seems easier to just lint all code at `HEAD`, instead of trying to guess which code was modified and only lint that.

💬 maflcko commented on pull request "Support self hosted Github workers on forks":
(https://github.com/bitcoin/bitcoin/pull/29259#discussion_r1455306954)
May be good to explain this change?

💬 maflcko commented on pull request "test: Add test case for spending bare multisig":
(https://github.com/bitcoin/bitcoin/pull/29120#issuecomment-1895628355)
Could also update the documentation of the setting to clarify that it refers to the relay of transactions which create bare outputs, and not to the relay of transactions spending them?

👍 maflcko approved a pull request: "contrib: Update clang-format-diff"
(https://github.com/bitcoin/bitcoin/pull/29251#pullrequestreview-1827105090)
lgtm ACK 52149b7a2c2b48ed4a4c0900c74cda4bb52a1ea5 🌱

<details><summary>Show signature</summary>

Signature:

```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: lgtm ACK 52149b7a2c2b48e
...

💬 kristapsk commented on pull request "log: Don't use scientific notation in "Dumped mempool" message":
(https://github.com/bitcoin/bitcoin/pull/29254#issuecomment-1895653539)
> I don't think nanosecond precision helps here. Might as well limit to `%.2fs`?

Agree, such precision is not needed, but didn't seem too important, message itself is relatively small anyway, so few extra characters doesn't hurt.

I would prefer millisecond precision, but plain `%.3f` will output 0.000 for 0.0009, don't think that's the right thing to do, should ceil or round before output then.

>
> Same here?
>
> ```
> src/policy/fees.cpp: LogPrint(BCLog::ESTIMATEFEE, "Recorded
...

🤔 furszy reviewed a pull request: "net: introduce block tracker to retry to download blocks after failure"
(https://github.com/bitcoin/bitcoin/pull/27837#pullrequestreview-1827136018)
Focus is on #28170, which is quite close.
Will rebase it as soon as it is merged.

💬 tromp commented on issue "Witness scripts being abused to bypass datacarriersize limit (CVE-2023-50428)":
(https://github.com/bitcoin/bitcoin/issues/29187#issuecomment-1895678731)
No matter what new restrictions are imposed, it's safe to assume that the economic reality of people wanting to inscribe data on the blockchain will persist and use whatever means is available and cheapest. There will always be means available such as spreading the data over multiple outputs or multiple txs, encoding the data as arbitrary taproot scripts, or encoding the data as fake public keys or key hashes. Some of these encodings will be detectable while others will not.
Raising the cost of
...

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1455418545)
Even better, I'll add a test that they're the same

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1455423851)
These are shorthand labels from https://delvingbitcoin.org/t/post-clustermempool-package-rbf-per-chunk-processing/190 which helped me think through preciesely how it maps onto the concepts laid out.

I'd like to keep track of these ideas somehow, maybe by defining the labels?

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1455426826)
can you be more explicit in suggestion? The errors are being returned?

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1455433932)
this is testing that subtraction works correctly, not that an individual chunk can have negative size

📝 stickies-v opened a pull request: "refactor: remove CTxMemPool::queryHashes()"
(https://github.com/bitcoin/bitcoin/pull/29260)
`CTxMemPool::queryHashes()` is only used in `MempoolToJSON()`, where it can just as easily be replaced with the more general `CTxMemPool::entryAll()`. No behaviour change, just cleans up the code.

🤔 furszy reviewed a pull request: "p2p: adaptive connections services flags"
(https://github.com/bitcoin/bitcoin/pull/28170#pullrequestreview-1827261571)
> If I understand it correctly, the logic deciding whether to try and accept outbound connections, using `HasAllDesirableServiceFlags()`, relies on `IsInitialBlockDownload()` / `DEFAULT_MAX_TIP_AGE` (24h) on master, but is changed to rely on `NODE_NETWORK_LIMITED_MIN_BLOCKS` (288 blocks, ~48h) in this PR.
>
> I think this means that the safety buffer of 144 blocks proposed in [BIP159](https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki) would have been removed. I'm not sure about th
...

💬 ismaelsadeeq commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1455527026)
I meant what is being returned by `err_string` and `CompareFeerateDiagram` was not used. why were you unable to compute mining score, same for `CompareFeerateDiagram` why is the fee rate insufficient.

💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1455534078)
also, `Subtrack` isn't a word...

💬 ismaelsadeeq commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1455539143)

Yeah, maybe to be consistent define the labels and do the same in the `OLD` `chunk` computation loop above.
Though the explicit comments in the `OLD` `chunk` computation loop is more easier to parse for me :).