📝 fanquake locked a pull request: "doc: recommend brew install python@3.7 (minimum version)"
(https://github.com/bitcoin/bitcoin/pull/27130)
null

📝 fanquake locked a pull request: "change txid log format specifier from %i to %s"
(https://github.com/bitcoin/bitcoin/pull/27133)
fix format specifier issue for log message;

The parameter "txid.GetHex()" returns a std::string, but the corresponding format specifier is "%i", should be changed to "%s".

⚠️ Victorcorreiaaraujo opened an issue: "Gy"
(https://github.com/bitcoin/bitcoin/issues/27163)
Nicky Montana on Medium https://medium.com/@nick.5montana

⚠️ Victorcorreiaaraujo opened an issue: "Ggd"
(https://github.com/bitcoin/bitcoin/issues/27164)
https://gist.githubusercontent.com/hhhogannwo/b65df24c56c808f38cf856cff1dea91a/raw/607237607a621a98e869b5607f5e6d8232d6bceb/guix-sigs.md

✅ glozow closed an issue: "."
(https://github.com/bitcoin/bitcoin/issues/27163)

✅ glozow closed an issue: "."
(https://github.com/bitcoin/bitcoin/issues/27164)

✅ glozow closed an issue: "Allow several OP_RETURN in one tx and no limited size"
(https://github.com/bitcoin/bitcoin/issues/27043)

📝 sipa opened a pull request: "Improve miniscript_{stable,smart} fuzzer ability to avoid too large scripts"
(https://github.com/bitcoin/bitcoin/pull/27165)
This adds a number of improvements to the miniscript fuzzers that all amount to reject invalid or overly big miniscripts earlier:
* Base type propagation in the miniscript_stable fuzzers prevents constructing a large portion of miniscripts that would be illegal, with just a little bit of type logic in the fuzzer. The fuzzer input format is unchanged.
* Ops and script size tracking in GenNode means that too-large scripts (either due to script size limit or ops limit) will be detected on the fly
...

💬 sipa commented on issue "miniscript_stable fuzz timeout":
(https://github.com/bitcoin/bitcoin/issues/27147#issuecomment-1445211590)
See #27165.

⚠️ Victorcorreiaaraujo opened an issue: "Any report, issue or feature request related to the GUI should be reported at "
(https://github.com/bitcoin-core/gui/issues/713)
Any report, issue or feature request related to the GUI should be reported at
https://github.com/bitcoin-core/gui/issues/

✅ hebasto closed an issue: "Any report, issue or feature request related to the GUI should be reported at "
(https://github.com/bitcoin-core/gui/issues/713)

:lock: hebasto locked an issue: "."
(https://github.com/bitcoin-core/gui/issues/713)

💬 MarcoFalke commented on pull request "25574 followups (VerifyDB error handling)":
(https://github.com/bitcoin/bitcoin/pull/27157#issuecomment-1445319780)
It might be good to explain and motivate the behaviour change. Calling it "25574 followups" is less useful than, for example, mentioning if the exit code is changed, if a warning will be printed, or if this turns an operation into an error?

💬 hebasto commented on issue "build: multiprocess link issues on fedora aarch64":
(https://github.com/bitcoin/bitcoin/issues/26943#issuecomment-1445324025)
> The decoded symbol name is `kj::_::Debug::minSeverity` which is a symbol in the `libkj.a` library

If we expect that the static `libkj.a` library is used rather than the shared `libkj.so` one, maybe it makes sense to configure with `--disable-shared` for all platforms, not just for Android?

💬 Ayms commented on issue "Allow several OP_RETURN in one tx and no limited size":
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445336629)
Why do you close it "as not planned"? Of course a modification request is "not planned", or who decided that it is "not planned"

💬 petertodd commented on issue "Allow several OP_RETURN in one tx and no limited size":
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445349756)
The fact that Core devs feel like they can close this with no explanation at all suggests that protocols should use the backup mechanism of polluting the UTXO set. The dust limit is low enough that for a lot of use cases a few extra outputs isn't a big deal.

On February 26, 2023 12:29:49 PM GMT+01:00, Aymeric Vitte ***@***.***> wrote:
>Why do you close it "as not planned"? Of course a modification request is "not planned", or who decided that it is "not planned"
>
>--
>Reply to this email dire
...

👍 theStack approved a pull request: "prune: scan and unlink already pruned block files on startup"
(https://github.com/bitcoin/bitcoin/pull/26533)
Code-review ACK 3141eab9c669488a2e7fef5f60d356ac92294922

FWIW, was curious how calling `fs::remove` on thousands of non-existing files would affect the performance (on mainnet, there is currently >3400 .blk/.rev files). But as expected, it's not a big deal:
```
$ cat remove_test.cpp
#include <filesystem>
#include <string>
int main() {
for (int i = 0; i < 10000; ++i) {
std::string filename = "/home/thestack/" + std::to_string(i) + ".dat";

...

💬 1440000bytes commented on issue "Allow several OP_RETURN in one tx and no limited size":
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445378974)
> The fact that Core devs feel like they can close this with no explanation at all suggests that protocols should use the backup mechanism of polluting the UTXO set. The dust limit is low enough that for a lot of use cases a few extra outputs isn't a big deal.
> […](#)
> On February 26, 2023 12:29:49 PM GMT+01:00, Aymeric Vitte ***@***.***> wrote: Why do you close it "as not planned"? Of course a modification request is "not planned", or who decided that it is "not planned" -- Reply to this em
...

⚠️ glozow reopened an issue: "Allow several OP_RETURN in one tx and no limited size"
(https://github.com/bitcoin/bitcoin/issues/27043)
The rationale is explained in this thread [[bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021435.html)

And other threads around that are addressing about the same subject: bring NFTs or other systems on or off chain and easy storage to Bitcoin

As mentionned in the thread there are so many possibilities to store things in Bitcoin, including very deviant practices like storing in addresses (
...

💬 Ayms commented on issue "Allow several OP_RETURN in one tx and no limited size":
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445386715)
@petertodd If I understand correctly your comment, you mean that without this change (as I think too) people will invent stupid things like I am myself proposing here (ie storing in addresses, with uncompressed keys, worse method on earth, but not expensive as you say and as I wrote, let's say that we will survive it and don't care for the future) : https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workaround-to-the-80b-op_return-limitation, then indeed polluting the UTXO set with no
...