💬 russeree commented on issue "Raise maximum -dbcache setting":
(https://github.com/bitcoin/bitcoin/issues/28249#issuecomment-1680225154)
I am re running an -reindex=1 with tracepoints watching for flushes.

Here is my last log entry for cache size height 800673 size 14,045 MiB

```2023-08-11T12:56:23Z UpdateTip: new best=00000000000000000002b6e22bae3b1f28339b6275c02ec9cbb6f19ffd9c7e9c height=800673 version=0x3017a000 log2_work=94.326952 tx=871155372 date='2023-07-28T20:42:50Z' progress=0.995044 cache=14045.6MiB(115054304txo)```

💬 MarcoFalke commented on pull request "Update Bitcoin Core integration/staging tree documentation":
(https://github.com/bitcoin/bitcoin/pull/28277#issuecomment-1680227708)
I think it was closed because the oxford comma is a style question. Generally we leave the style to the original author and then leave it as-is until the line is touched again for other reasons. Everyone should be able to read and understand the text even without the oxford comma.

💬 MarcoFalke commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#discussion_r1295597557)
>

How is this related. This is the "macOS native", not "macOS-cross" task.

💬 hebasto commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#discussion_r1295599361)
> How is this related. This is the "macOS native", not "macOS-cross" task.

My bad. Sorry for the noise.

💬 fanquake commented on issue "ci: ccache does not work for macOS cross-compiling builds":
(https://github.com/bitcoin/bitcoin/issues/21552#issuecomment-1680237452)
Given it's not in the description, can someone summarize the current state of this issue?

* What doesn't work?
* What ccache options have been tried (and don't work)? Taking into account recent ccache releases.
* Have we opened an issue upstream to either report that ccache is broken (for us), or that we have a usecase which isn't satified by it's current feature/option set, to see if they are open to adding a new feature/option?
* If there is any (related) upstream discussions/issues, can
...

💬 RobinLinus commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1680238303)
Using P2PK costs more fees. Making the toxic waste more expensive is the objective of this PR.

However, it was stated here before that P2PK should be nonstandard too. Ideally, we would even do a softfork to cleanup all these exploitable quirks. Softforks are much harder though so it's a good approach to simply make P2PK/P2MS nonstandard for now.

💬 russeree commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1680265240)
> Using P2PK costs more fees. Making the toxic waste more expensive is the objective of this PR.

It's my belief that users committed to inflating the UTXO set via these mechanisms won't find the overhead of using P2PK problematic when trying to embed persistent, unprunable data into the timechain. P2MS was originally selected because it offered a cost-effective method to achieve this. If P2MS becomes inefficient or difficult to relay, the next logical choice would be P2PK. If users are will
...

💬 naumenkogs commented on pull request "p2p: Drop m_recently_announced_invs bloom filter":
(https://github.com/bitcoin/bitcoin/pull/27675#issuecomment-1680269540)
ACK fb02ba3c5f5bcd96b5e3622ef001b8e57ce63fc0

💬 MarcoFalke commented on pull request "ci: Run "macOS 11.0 [gui, no tests] [jammy]" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28265#discussion_r1295647557)
I guess for this repo, it should be sufficient to only have a `master` cache (written only by `master`) and all pull requests and other branches simply read-only from `master`. This should make the storage needs constant (limited) and easier to think about, without much downside.

💬 1ma commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1680299138)
> If P2MS becomes inefficient or difficult to relay, the next logical choice would be P2PK. This would lead to an even faster inflation of the UTXO set.

Then the next logical step is also making P2PK non-standard (preferably on the same release), as suggested by @Semisol in this thread.

💬 RobinLinus commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1680300119)
> won't find the overhead of using P2PK problematic

P2PK is more costly, which reduces the toxic waste spammers can inscribe per Dollar. However, as said before, P2PK should be nonstandard too.

👍 MarcoFalke approved a pull request: "Break up script/standard.{h/cpp}"
(https://github.com/bitcoin/bitcoin/pull/28244#pullrequestreview-1580239988)
ACK 91d924ede1b421df31c895f4f43359e453a09ca5 😇

<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: ACK 91d924ede1b421df31c895f4f4
...

💬 MarcoFalke commented on pull request "Break up script/standard.{h/cpp}":
(https://github.com/bitcoin/bitcoin/pull/28244#discussion_r1295681864)
7a172c76d2361fc3cdf6345590e26c79a7821672: nit: Any reason to put this in this scope, instead of in the only scope that uses it (one function)?

Also, could use `using` (C++11)?

💬 MarcoFalke commented on pull request "Break up script/standard.{h/cpp}":
(https://github.com/bitcoin/bitcoin/pull/28244#discussion_r1295665496)
unrelated: IIUC this creates a useless copy. Might be better to just retain the reference.

💬 MarcoFalke commented on pull request "Break up script/standard.{h/cpp}":
(https://github.com/bitcoin/bitcoin/pull/28244#discussion_r1295682450)
7a172c76d2361fc3cdf6345590e26c79a7821672: nit:

```
addresstype.cpp should add these lines:
#include <cassert>
#include "crypto/sha256.h" // for CSHA256
#include "span.h" // for Span

💬 MarcoFalke commented on pull request "Break up script/standard.{h/cpp}":
(https://github.com/bitcoin/bitcoin/pull/28244#discussion_r1295695839)
nit in 7a172c76d2361fc3cdf6345590e26c79a7821672: Could keep this in the `script` directory, next to `script/descriptor.cpp`?

💬 MarcoFalke commented on pull request "Break up script/standard.{h/cpp}":
(https://github.com/bitcoin/bitcoin/pull/28244#discussion_r1295692671)
7a172c76d2361fc3cdf6345590e26c79a7821672:nit: missing newline?

💬 MarcoFalke commented on pull request "Break up script/standard.{h/cpp}":
(https://github.com/bitcoin/bitcoin/pull/28244#discussion_r1295691564)
bacdb2e208531124e85ed2d4ea2a4b508fbb5088: nit:

```
script/solver.cpp should add these lines:
#include <cassert> // for assert
#include "prevector.h" // for operator-, prevector

💬 MarcoFalke commented on pull request "test: check backup from `migratewallet` can be successfully restored":
(https://github.com/bitcoin/bitcoin/pull/28257#issuecomment-1680357309)
lgtm ACK 769f5b15f207ce6d1067672ea5e195541c97de6b

💬 petertodd commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1680366922)
@achow101 @ariard See [[bitcoin-dev] Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021890.html) for a re-confirmation of my OTS calendar findings, including a tool that anyone can easily use to also test full-RBF adoption for themselves.

@Daniel600
> The methodology of 37% assessment above is not thorough - a simple test of representative trx count with a time gap follow
...