💬 brunoerg commented on pull request "refactor, kernel: Decouple ArgsManager from blockstorage":
(https://github.com/bitcoin/bitcoin/pull/27125#discussion_r1117926027)
nit: Since `blockman_opts` is empty here, I think you can pass it directly instead of creating `blockman_opts` for it.
```cpp
ChainstateManager chainman{chainman_opts, {}};
```
(https://github.com/bitcoin/bitcoin/pull/27125#discussion_r1117926027)
nit: Since `blockman_opts` is empty here, I think you can pass it directly instead of creating `blockman_opts` for it.
```cpp
ChainstateManager chainman{chainman_opts, {}};
```
💬 ryanofsky commented on pull request "Deduplicate bitcoind and bitcoin-qt init code":
(https://github.com/bitcoin/bitcoin/pull/27150#issuecomment-1445127686)
Updated e248926c73ce6f707343501fb42b31090fed202b -> 25f9cbf7191ee80a640da5f5386aef9658f1168b ([`pr/oneconfig.2`](https://github.com/ryanofsky/bitcoin/commits/pr/oneconfig.2) -> [`pr/oneconfig.3`](https://github.com/ryanofsky/bitcoin/commits/pr/oneconfig.3), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/oneconfig.2..pr/oneconfig.3)) to fix lint spelling error https://cirrus-ci.com/task/5488540285403136
(https://github.com/bitcoin/bitcoin/pull/27150#issuecomment-1445127686)
Updated e248926c73ce6f707343501fb42b31090fed202b -> 25f9cbf7191ee80a640da5f5386aef9658f1168b ([`pr/oneconfig.2`](https://github.com/ryanofsky/bitcoin/commits/pr/oneconfig.2) -> [`pr/oneconfig.3`](https://github.com/ryanofsky/bitcoin/commits/pr/oneconfig.3), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/oneconfig.2..pr/oneconfig.3)) to fix lint spelling error https://cirrus-ci.com/task/5488540285403136
📝 fanquake locked a pull request: "2023.02.21 ci prep"
(https://github.com/bitcoin/bitcoin/pull/27136)
null
(https://github.com/bitcoin/bitcoin/pull/27136)
null
📝 fanquake locked a pull request: "doc: recommend brew install python@3.7 (minimum version)"
(https://github.com/bitcoin/bitcoin/pull/27130)
null
(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".
(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
(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
(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)
(https://github.com/bitcoin/bitcoin/issues/27163)
✅ glozow closed an issue: "."
(https://github.com/bitcoin/bitcoin/issues/27164)
(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)
(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
...
(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.
(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/
(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)
(https://github.com/bitcoin-core/gui/issues/713)
:lock: hebasto locked an issue: "."
(https://github.com/bitcoin-core/gui/issues/713)
(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?
(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?
(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"
(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
...
(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";
...
(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";
...